La compilation récupère-t-elle/utilise-t-elle des ressources pré-construites ? Ou avez-vous désactivé cela ? (ou patché le cœur de manière à ce que les ressources pré-construites ne puissent pas être utilisées)
Vous avez beaucoup d’espace d’échange (swap) mais une grande partie est déjà utilisée. Comme une configuration à deux conteneurs entraîne moins de temps d’arrêt, il est peut-être vrai que l’invocation actuelle du serveur est toujours en cours d’exécution et a accumulé une utilisation importante de la mémoire, peut-être à cause d’une fuite.
Peut-être qu’un redémarrage aiderait, avant la mise à jour. Peut-être mesurer l’utilisation de l’espace d’échange avant et après le redémarrage.
J’ai une sorte de fuite/expansion de mémoire sur l’un de mes serveurs. Sur la suggestion judicieuse de @RGJ, j’ai programmé un redémarrage par cron tous les 7 jours tôt le lundi matin (Heure d’Europe occidentale)
(Nous pensons connaître le plugin qui pose problème, mais je n’ai pas investi le temps nécessaire pour comprendre pourquoi il y a une fuite/expansion de mémoire)
Ceci ressemble à un arrêt dû à un manque de mémoire (OOM kill) : Je suis à environ 2 Gio de RAM et lors des reconstructions en deux conteneurs, l’ancienne application et la nouvelle construction se chevauchent, ce qui fait dépasser la mémoire. La mémoire d’échange (swap) est déjà utilisée à environ 3 Gio avant l’amorçage, donc le pic de construction d’Ember reçoit un SIGKILL. L’arrêt du conteneur en cours d’exécution (ou l’exécution d’une reconstruction en un seul conteneur) évite le chevauchement et réussit. La prochaine étape consiste à confirmer via dmesg puis soit à redémarrer avant les reconstructions / enquêter sur ce qui augmente la mémoire d’échange avec le temps / ajouter de la RAM (la mémoire d’échange seule ne semble pas suffire une fois qu’elle est déjà fortement utilisée).
Ceci ressemble moins à un problème de pnpm ou d’Ember, et davantage à un manque de mémoire de l’hôte lui-même.
Le détail clé est le SIGKILL. Cela signifie généralement que le système d’exploitation est intervenu et a tué le processus (souvent via le tueur OOM), et non que ember build -prod a échoué de lui-même.
Sur les petits hôtes, les builds de production Ember peuvent facilement atteindre quelques Go de RAM. Même avec l’échange activé, une fois que l’échange est majoritairement utilisé, le noyau peut toujours décider de tuer un processus node gourmand en mémoire.
Quelques éléments qui vont dans ce sens :
L’échange est déjà fortement utilisé lorsque l’échec se produit.
L’échec est beaucoup plus probable lorsqu’un autre conteneur fonctionne en même temps.
Si j’arrête l’autre conteneur avant d’exécuter l’amorçage (bootstrap), la même build réussit.
Donc, l’échange aide un peu, mais il ne fait surtout que retarder le problème. L’arrêt des autres conteneurs réduit suffisamment la pression sur la mémoire pour que la build se termine.
Ce qui a aidé / pourrait aider :
Éviter d’exécuter plusieurs amorçages ou builds d’assets en parallèle.
Arrêter les autres conteneurs pendant ember build -prod.
Limiter l’utilisation de la mémoire de Node (par exemple, NODE_OPTIONS=--max_old_space_size=1024) pour réduire l’utilisation maximale.
Si possible, augmenter la RAM de l’hôte (4 Go et plus) rend cela beaucoup plus fiable.
J’espère que cela aide à expliquer pourquoi cela semble un peu aléatoire et pourquoi l’arrêt d’un autre conteneur le fait fonctionner.
Il semble que plus de swap aiderait. Cela ne ferait pas de mal. Au lieu de regarder le swap total et de dire que cela semble beaucoup, regardez le swap libre et assurez-vous d’avoir la marge nécessaire pour une reconstruction.
Ça semble être une bonne idée ! Redémarrez-vous le serveur ou juste le conteneur ?
Quoi qu’il en soit, cela m’est arrivé à nouveau sur un autre serveur de 2 Go + 3 Go. Ensuite, j’ai redémarré web_only et j’ai essayé à nouveau et cela a fonctionné parfaitement. Je pense que je vais ajouter à mes outils la possibilité de redémarrer web_only, peut-être si la mémoire est en dessous d’une certaine définition de “basse”.
Nous avons constaté un cas où le redémarrage de Linux a aidé. Je sais que ce n’est pas la façon dont nous aimons généralement considérer Linux, mais il existe toujours une possibilité de fragmentation et une possibilité de fuites de mémoire.
