Nanawel a écrit 285 commentaires

Ouais je crois que c'est ce qui fait toute la différence ici. Il faudrait (aurait fallu) que j'augmente la taille des chunks en passant du RAID1 à RAID5.

A priori c'est possible de le faire a posteriori, mais encore faut-il que le reshape se termine d'abord…

(et j'imagine que cette action va aussi prendre des plombes pour les mêmes raisons)

Très juste, j'avais oublié de mettre la sortie de mdadm --detail /dev/md0, j'ai corrigé ça.

Normalement ça permet de dire que j'utilise déjà un internal bitmap. C'est bien le but de ta première commande ?

Pour les commandes suivantes voici l'état actuel :

# cat /proc/sys/dev/raid/speed_limit_max
200000

# cat /sys/block/sd[a-d]/queue/read_ahead_kb
128
128
128
128

# cat /sys/block/sd[a-d]/queue/nr_requests
64
64
64
64

# for dev in $(echo /dev/sd[a-d]); do echo -n "$dev: "; blockdev --getra $dev; done
/dev/sda: 256
/dev/sdb: 256
/dev/sdc: 256
/dev/sdd: 256

# blockdev --getra /dev/md0
65536

# cat /sys/block/md0/md/stripe_cache_size
8192

# cat /sys/block/md0/md/stripe_cache_active
12041

Bon clairement y'a des choses à ajuster. Je m'en vais tenter ça de suite. Merci !

Autres sources trouvées à ce sujet en passant, avec des valeurs égales ou similaires :
- https://wtf.roflcopter.fr/links/pogo/?nICtQw
- http://wiki.alessandro.delgallo.net/wiki/index.php/RAID

Quand j'ai vu ces perfs j'ai cherché une explication dans les logs, et notamment des erreurs SATA (par expérience…). Mais là rien du tout, les logs systèmes sont cleans, rien à redire.

Si le problème était lié au débit es interfaces, je pense que les tests hdparm l'auraient révélé.

Quelle est la taille des chunks sur ta grappe ?

J'y ai pensé aussi, mais quand je regarde le load je vois surtout beaucoup d'iowait et pas beaucoup de temps kernel ou user (80% d'iowait contre 10% max de kernel+user). À mon sens ça devrait pourtant se traduire par une occupation forte de ces états.

La sortie de mon dmesg :

[    4.470732] raid6: sse2x1   gen()  2107 MB/s
[    4.538717] raid6: sse2x1   xor()  2003 MB/s
[    4.606728] raid6: sse2x2   gen()  3375 MB/s
[    4.674719] raid6: sse2x2   xor()  3409 MB/s
[    4.742733] raid6: sse2x4   gen()  4054 MB/s
[    4.810714] raid6: sse2x4   xor()  2175 MB/s
[    4.810717] raid6: using algorithm sse2x4 gen() 4054 MB/s
[    4.810718] raid6: .... xor() 2175 MB/s, rmw enabled
[    4.810720] raid6: using intx1 recovery algorithm

Pas top certes, mais pas trop dégueu non plus je pense, non ?

Oh OK merci :)

En effet ça semble logique. Mais où vois-tu cette valeur de ~75 IOPS dans les sorties des commandes ? Je suis curieux je n'y vois que des valeurs en ko/s.

Je ne sais pas comment faire pour augmenter la quantité de données lues à chaque "tour", je pensais que la commande blockdev --setra servait à ça, mais apparemment mdadm ne semble pas trop y voir de différence.

Si j'avais une solution qui impliquait d'augmenter sensiblement la RAM occupée pour ce travail (en travaillant sur de plus gros lots de données) ça ne me dérangerait pas, j'ai encore presque 3 Go libres, mais je ne trouve rien qui permette ça.

Et je plussoie également pour borg, avec tous les avantages décrits par les précédentes réponses.

Je suis également tombé sur un service de sauvegarde que j'ai failli prendre¹ et qui allie simplicité et faible coût : https://www.rsync.net/products/borg.html
En gros, il s'agit simplement d'un serveur de stockage utilisable avec rsync… et borg évidemment. Ça revient à $12.50 par mois pour 500 Go de stockage, ce qui me semble pas mal.

---

¹ Finalement j'en suis resté pour l'instant à de l'auto-hébergement à ce niveau, mais je n'exclue pas d'y souscrire à terme.

En effet, ça confirme mes doutes sur la faisabilité.

Je ne sais pas si tu as testé car tu ne le mentionnes pas, mais as-tu essayé la virtualisation ?
Pour une application 3D je n'aurais pas trop d'espoir malheureusement, mais il semble y avoir un peu de doc qui traîne et qui semble faire penser que c'est possible : https://all3dp.com/2/fusion-360-for-linux-how-to-install-it/

Idem quand je clique sur un lien extérieur à Twitter. Par contre une fois la page d'erreur affichée, forcer le rafraîchissement (Ctrl+Shift+R) permet d'accéder à la page voulu, alors qu'un simple rafraîchissement ne fait rien de plus.

Le besoin de l'import CSV était dans l'optique où aucune interface sur un logiciel existant, de par le besoin de base (à savoir "indexer des recettes" et non "rédiger des recettes") ne permettrait d'avoir l'efficacité souhaitée, et qu'une saisie dans un tableur serait plus rapide et plus confortable.

Avec Reciphpes, ce besoin est désormais anecdotique puisque l'interface de saisie en masse est prévue précisément pour répondre à ce besoin, avec tout le nécessaire pour être le plus efficace possible (navigation au clavier, auto-complétion, etc.).

Dans tous les cas, mes compétences et mes préférences me font souvent largement préférer l'utilisation d'une application web à un logiciel lourd, ne serait-ce que par la portabilité (multi-OS et multi-device) et la facilité de collaboration. J'ai serveur maison qui sert à ça donc il est très facile d'y déployer de nouveaux applicatifs (surtout quand ils sont dockerisés).

Currently the application cannot be accessed from a URL using a custom path

bizarre quand même

Oui j'ai été surpris aussi mais c'est une limitation de Symfony si on veut que l'application soit bien portable facilement. Sinon les URL générées pour les assets (CSS/JS) et les liens internes sont foireuses.

Je ne dis pas qu'il n'y a pas de solution, mais seulement que les solutions qui existent et que j'ai lues sont toutes des bidouillages qui ne me satisfaisaient pas.

Merci, merci et merci.

Je suis pas allé cherché loin, mais si ça plaît alors tant mieux :D

Alors je n'ai pas nettoyé mon historique Git donc tu pourras y retrouver les premières pistes que j'avais suivies (et qui ne pas passées par ES mais par MongoDB) mais d'une manière générale j'en suis arrivé à la conclusion que les données que je cherchais à modéliser sont relationnelles. Donc utiliser autre chose qu'un SGBD pour ça était simplement un anti-pattern.

Cela m'a quand même permis d'explorer un peu les possibilités offertes par Doctrine avec MongoDB, et très franchement, c'est vraiment à réserver à des utilisations qui s'y prêtent car les limitations arrivent vite.

Je conserve par contre la possibilité d'utiliser un jour ES ou MongoDB comme moteurs de recherche (à plat donc), qui sont beaucoup plus efficaces que les SGBD évidemment. Là pour le moment ma recherche est un bête LIKE…

Oui il faut que j'ajoute un screenshot d'ailleurs.

Cette fonctionnalité est issue de mes premières séances de saisie. La saisie unitaire était chronophage et frustrante, avec beaucoup de valeurs qui ne variaient pas d'une recette à l'autre (quand on indexe un livre page par page notamment). Après discussion avec ma co-auteur, on a considéré que c'était un bon compromis.

Pour l'accès par mobile, oui je me suis appliqué à m'assurer que toute l'interface est bien responsive (merci Boostrap). Il peut rester certaines zones à améliorer mais l'ensemble devrait être totalement utilisable depuis mobile, puisque c'était un besoin à la base.

Ah si tu ne connais aucun des deux cela va m'être difficile de te répondre :)

Disons que ce sont 2 frameworks très différents, avec chacun leurs concepts à appréhender ce qui conduit souvent à se demander "mais pourquoi ce que j'ai fait ne fonctionne pas ?" parce qu'on réfléchit involontairement au problème par le "mauvais" prisme.

Symfony a la force de la doc. Très complète, mais toujours un peu abstraite, c'est une doc.
Magento a la force des dizaines de modules standards qui sont autant d'exemples qu'il est possible d'analyser en détail et dont il est possible de s'inspirer (voire de copier).

Après, la debugbar de Symfony est un petit bijou, et elle m'a sorti d'affaires plus d'une fois. Mais j'ai quand même passé beaucoup de temps dans le debugger et sur StackOverflow.

Oh merci, j'ai totalement zappé de mettre des nimages pour accompagner.

Pour te répondre concernant Gourmet, j'ai testé et hésité pas mal je t'avoue. Mais au final les points qui m'ont fait abandonner sont :

• Trop complet/complexe pour l'usage. Gourmet permet vraiment d'aller dans des détails très précis, mais quand on ne les utilise pas cela rend le tout lourd à utiliser.
• Pas de support pour l'import CSV, alors que c'est le format qu'il était prévu d'utiliser pour saisir les recettes à indexer.
• Logiciel lourd. Assez critique quand la consultation va être faite dans 95% des cas sur mobile (eh oui, le mobile dans la cuisine, voire même à l'extérieur de la maison).
• Non-collaboratif. C'est quand même pratique de pouvoir se répartir les bouquins à indexer et pouvoir le faire en parallèle :)

Ah oui, le chemin résolu quand on est sur Docker Hub ne fonctionne pas, je regarderai.

En attendant tu peux passer par Github directement : https://github.com/nanawel/reciphpes/tree/master/docs/screenshots

Je viens d'en faire un journal : https://linuxfr.org/users/nanawel/journaux/reciphpes-gestion-et-indexation-de-recettes-sous-symfony

J'ai un Ellipse ECO 500 non pilotable et un Ellipse ECO 650 USB.

Le modèle USB fonctionne bien sous Debian/Ubuntu avec NUT ce qui permet d'éteindre la machine proprement si la coupure dure. Pour info qui vaut ce qu'elle vaut, 5 ans plus tard il tient encore 30mn environ avec une box SFR et un serveur HP Proliant MicroServer N40L reconverti en NAS.

Le premier fonctionne bien aussi, il faut juste que la coupure dure pas trop ! (mais heureusement, là où il est, les coupures sont rares)

Haha oui maintenant que tu le dis j'ai d'ailleurs dû étudier cet exemple en cours.

Mais non, on va pas faire du Prolog ;)

Gourmet est pas mal en effet ! On perd le côté générique que je cherchais initialement, mais au moins il est bien adapté au besoin.
Il possède notamment le champ "Source" qui permet justement de préciser où se trouve la recette si on ne met pas les instructions, ce qui permet de la retrouver.

Je suis tenté !

Notamment pour gérer le cas des données complexes (emplacements, ingrédients, etc.) et pour pouvoir gérer les filtres de types :
- "recettes avec X et Y sans Z"
- "recettes avec X mais sans Y"
- "recettes végétariennes dans l'emplacement E"

Mais peut-être que je n'ai pas une vision suffisamment large de ce qu'il est possible de faire sans SGBD, je suis un peu trop dedans au quotidien pour être objectif ;)

Oui je vois, effectivement c'est peut-être une méthode plus efficace. Faut que je me documente un peu plus sur ES à ce sujet.

Exactement, merci de la précision :)