La build sta recuperando/utilizzando asset precompilati? O hai disabilitato questa funzione? (o hai modificato il core in modo che gli asset precompilati non possano essere utilizzati)
Hai molta swap ma una grande parte è già in uso. Dato che una configurazione a due contenitori ha meno tempi di inattività , forse è vero che l’attuale invocazione del server è ancora in esecuzione e ha accumulato un uso elevato di memoria, forse a causa di una perdita (leak).
Forse un riavvio aiuterebbe, prima dell’aggiornamento. Forse misura l’uso della swap prima e dopo il riavvio.
Ho una specie di perdita/espansione di memoria su uno dei miei server. Su suggerimento sensato di @RGJ, ho programmato un riavvio ogni 7 giorni il lunedì mattina presto (Europa occidentale) tramite cron.
Questo sembra un OOM kill: ho circa 2 GiB di RAM e nelle ricostruzioni a due container la vecchia app + la nuova build si sovrappongono spingendo la memoria oltre il limite. Lo swap è già utilizzato per circa 3 GiB prima dell’avvio, quindi lo spike della build di Ember riceve un SIGKILL. Interrompere il container in esecuzione (o eseguire una ricostruzione a container singolo) evita la sovrapposizione e ha successo. Il passo successivo è confermare tramite dmesg e quindi riavviare prima delle ricostruzioni / indagare cosa sta aumentando lo swap nel tempo / aggiungere RAM (lo swap da solo non sembra salvarlo una volta che è già pesantemente utilizzato).
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.
Sembra che piĂą swap aiuterebbe. Non farebbe male. Invece di guardare lo swap totale e dire che sembra molto, guarda lo swap libero e assicurati di avere il margine per una ricostruzione.
Sembra una buona idea! Riavvi il server o solo il container?
Comunque, mi è successo di nuovo su un altro server da 2gb+3GB. Poi ho riavviato web_only e ho riprovato e ha funzionato perfettamente. Penso che aggiungerò al mio strumento la possibilità di riavviare web_only, forse se la memoria è al di sotto di una certa soglia.
Abbiamo riscontrato un caso in cui il riavvio di Linux ha aiutato. So che normalmente non è così che ci piace considerare Linux, ma c’è ancora la possibilità di frammentazione e c’è la possibilità di perdite di memoria.
