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.