Il semble que 2+2 ne suffise plus… Je gère une instance Discourse assez modeste (pas de plugins importants/sophistiqués, etc.) qui, depuis aujourd’hui, échoue au démarrage car Ember consomme toute la RAM qu’elle trouve, ainsi que tout le swap, et rend la machine inutilisable. L’ajout de 2 Go de swap supplémentaires a permis au démarrage de se terminer, avec une utilisation maximale du swap d’environ 2,5 Go.
Oups, c’est sur la liste de @david à examiner.
5 « J'aime »
@david a enquêté, nous confirmons qu’en l’état, 2 Go suffisent pour les reconstructions de docker, mais pas assez pour que le web upgrader fonctionne.
Une idée que j’ai lancée est d’arrêter tous les processus ruby pendant le web upgrader afin d’économiser 300 à 500 Mo supplémentaires, ce qui laisserait suffisamment pour la précompilation des assets.
À long terme, nous devrons probablement adopter une approche pour les auto-hébergeurs, qui consiste à expédier des conteneurs amorcés, ce qui ouvre la boîte de Pandore car comment un web upgrader pourrait-il y parvenir ? Nous ne voulons pas monter les sockets docker…
C’est vraiment un dilemme.
2 « J'aime »
Eh bien, ce n’était pas le cas pour moi.
Est-ce une comparaison entre une installation pure de base et des situations réelles ?
En effet, ce n’est pas parfaitement cohérent. Même avec tout le reste arrêté, cela peut toujours échouer.
Malheureusement, nous menons une bataille perdue d’avance contre les outils de build JS modernes ici. Tout est conçu pour fonctionner sur 8 Go+ de RAM sur les machines de développeurs modernes, pas sur des VPS de 1 Go 
Nous avons quelques solutions en tête. Par exemple : fournir des assets pré-compilés qui peuvent être téléchargés automatiquement. Le grand défi que nous avons concerne les plugins, car ils varient sur le site de chacun, et actuellement, ils sont étroitement intégrés au cœur du build.
Mais pour l’instant, une reconstruction complète en ligne de commande devrait avoir un taux de réussite plus élevé qu’une mise à jour de l’interface utilisateur web.
8 « J'aime »
Comme Jagster, 2 Go de RAM + 2 Go de swap ne suffisent pas, en fait, pour ma reconstruction Docker pilotée par CLI. En vérifiant plus loin, les seuls plugins sur cette installation sont docker_manager et discourse-prometheus – aucun des deux ne devrait, je m’attends, imposer une charge inattendue sur ember.
Si les spécifications minimales doivent changer, ce serait nul, mais ce serait beaucoup mieux que la situation actuelle, où les machines s’arrêtent de manière inattendue à chaque mise à niveau.
7 « J'aime »
Si tel est le cas, je pense qu’il serait tout de même préférable d’augmenter un peu les spécifications recommandées. Personnellement, cela ne me dérange pas vraiment d’ajouter 2 (ou même 4) Go de swap supplémentaires si cela rend les reconstructions plus fiables - du moins tant que les opérations quotidiennes se déroulent toujours bien avec 2-4 Go de RAM (pour les communautés petites à moyennes).
2 « J'aime »
En effet, l’installation initiale a échoué dans mon installation récente sur une instance 4c 4g. Ed a suggéré de créer un fichier swap. J’ai trouvé le sujet pour créer un swap et j’ai créé un swap de 4 Go. Maintenant, tout fonctionne comme prévu lors de la mise à jour/mise à niveau via le web ou la CLI.
À mon avis, nous devons peut-être simplement accepter que Discourse nécessite plus de RAM qu’auparavant.
3 « J'aime »
Le zram n’aurait-il pas de sens ?
Nous venons de déployer ce commit qui devrait, espérons-le, améliorer la situation. Merci de nous faire savoir comment cela se passe ! (cela sera intégré aux tests réussis dans les ~30 prochaines minutes)
En testant avec un conteneur docker à mémoire limitée localement, je peux maintenant obtenir une compilation réussie avec -m 1600m. Avant ce changement, le minimum que je pouvais atteindre était -m 3000m.
12 « J'aime »
J’ai effectué une reconstruction de test (installation fraîche), qui s’est déroulée sans problème. Cette machine dispose maintenant de 4 Go de RAM (Hetzner CAX11) et d’un fichier d’échange de la même taille, donc elle est certainement moins contrainte que la configuration 2+2 Go mentionnée ci-dessus. Cependant, l’utilisation du swap a été minime pendant toute la compilation et l’utilisation maximale de RAM que j’ai observée était d’environ 3,1 Go. Et la plupart du temps, elle est restée autour de 2 Go, donc cela ne semble pas trop mal (le temps de compilation est resté plus ou moins inchangé, c’est-à-dire environ 8 minutes).
4 « J'aime »
J’aimerais beaucoup réaliser quelques expériences contrôlées, avec des installations et des reconstructions propres, sur une variété de configurations, et en particulier j’aimerais voir la différence (s’il y en a) de fonctionnement avec le vm overcommit, mais je crains de manquer de temps.
(Sans overcommit, un gros processus qui effectue un fork aura une augmentation instantanée de son empreinte mémoire qui pourrait être fatale, et cela ne ressortira pas sur un moniteur interrogé. Même avec l’overcommit, l’augmentation de la mémoire pourrait être suffisamment rapide pour ne pas apparaître lors d’un sondage, que ce soit htop, vmstat ou autre chose.)
Je ne pense pas avoir jamais vu quelqu’un indiquer s’il fonctionne ou non avec l’overcommit, bien qu’à mon avis, ce soit un aspect important de la configuration de l’hôte.
1 « J'aime »
Je parie que la plupart des gens ne le font pas.
Je le configure automatiquement sur mes installations. J’obtiens toujours cet avertissement à ce sujet, cependant.
Le surallocation est sans objet ici, car le problème n’est pas que les processus soient tués prématurément par OOM, il s’agit simplement d’essayer de mettre dix livres de mémoire allouée dans un sac de cinq livres.
Il n’est pratiquement pas possible d’exécuter une reconstruction de Discourse avec overcommit_memory=2, car ember (entre autres, sans aucun doute) pré-alloue des masses de mémoire virtuelle (si ma mémoire est bonne, environ 80 Go, c’est ce que j’ai vu), donc cela échouera toujours à tout réglage raisonnable de overcommit_ratio. Définir overcommit_memory=1 n’aidera pas non plus, car, encore une fois, le problème n’est pas un VMM trop zélé qui tue des processus, mais une gestion de la mémoire hideusement médiocre de la part du compilateur ember.
1 « J'aime »
Je ne suis pas sûr de partager entièrement votre analyse ! Si je comprends bien, le overcommit permet aux processus d’allouer de la mémoire qu’ils n’utilisent pas. Il ne s’agit pas seulement du comportement de l’OOM-killer. Mais comme je l’ai dit, j’aimerais réaliser quelques expériences contrôlées, c’est une meilleure façon de voir ce qui fait une différence et ce qui n’en fait pas.
J’ai 4 Go de RAM et beaucoup de plugins (pas de fichier d’échange dont je sois au courant). Combien de plugins avez-vous et pensez-vous que 4 Go de RAM seul suffisent ?
Partiellement correct, mais même ainsi, c’est sans importance, car le problème abordé dans ce sujet concerne les processus qui allouent de la mémoire qu’ils touchent, et qui en touchent plus que le système n’en a de disponible, ce qui provoque des pannes visibles par le client.
Pouvez-vous confirmer qu’après les changements de @david, les besoins en mémoire ont diminué ? Nous devrions être dans un état raisonnable maintenant.
Le prochain grand bond sera la pré-compilation et les actifs pré-compilés distribués, c’est un changement assez important pour y parvenir mais cela effacera un gros lot de travail d’Internet une fois terminé.
2 « J'aime »
Avec tout le respect que je vous dois, je ne suis pas sûr de cela. J’ai vu des fichiers journaux montrant des échecs de fork. Nous disons dans ce fil que ce sont les « exigences de mémoire », mais cela inclut, à mon avis, les tactiques du noyau pour la mémoire virtuelle. Clairement, une ou plusieurs expériences montreront si j’ai raison ou non à propos de la surallocation.
C’était une construction fraîche sans aucun plugin. Je peux essayer une autre avec quelques plugins activés et peut-être désactiver temporairement swap pour confirmer que la construction passe (cela prendra probablement quelques jours jusqu’à ce que j’aie le temps, cependant).
2 « J'aime »