Questo sembra meno un problema di pnpm o Ember e più che l’host stia semplicemente esaurendo la memoria.
Il dettaglio chiave è il SIGKILL. Di solito significa che il sistema operativo è intervenuto e ha terminato il processo (spesso tramite l’OOM killer), non che ember build -prod sia fallito da solo.
Su host piccoli, le build di produzione di Ember possono facilmente raggiungere picchi di un paio di GB di RAM. Anche con lo swap abilitato, una volta che lo swap è quasi esaurito, il kernel può comunque decidere di terminare un processo node affamato di memoria.
Alcune cose che indicano questa direzione:
- Lo swap è già pesantemente utilizzato quando si verifica il fallimento.
- Il fallimento è molto più probabile quando un altro container è in esecuzione contemporaneamente.
- Se interrompo l’altro container prima di eseguire l’avvio (bootstrap), la stessa identica build ha successo.
Quindi lo swap aiuta un po’, ma per lo più ritarda solo il problema. L’arresto di altri container riduce la pressione sulla memoria quel tanto che basta affinché la build finisca.
Cosa ha aiutato / potrebbe aiutare:
- Evitare di eseguire più avvii (bootstrap) o build di asset in parallelo.
- Arrestare altri container durante
ember build -prod. - Limitare l’utilizzo della memoria di Node (ad esempio
NODE_OPTIONS=--max_old_space_size=1024) per ridurre l’utilizzo di picco. - Se possibile, aumentare la RAM dell’host (4GB+) rende questo molto più affidabile.
Spero che questo aiuti a spiegare perché sembra un po’ casuale e perché l’arresto di un altro container lo fa funzionare.