Perché la tua app va in crash sotto carico: processo terminato da Linux per memoria esaurita

La tua applicazione risponde in modo ottimale quando viene utilizzata da un solo utente, ma in presenza di un picco improvviso di traffico l'intero servizio si arresta istantaneamente, come se venisse disconnesso dalla rete elettrica.

In breve: L'interruzione forzata di un processo per memoria esaurita su sistemi Linux indica che il server ha saturato la RAM fisica disponibile, spingendo il sistema operativo ad attivare i propri meccanismi di protezione dell'integrità dell'infrastruttura. Nei log di sistema l'evento viene registrato con la stringa Out of memory: Killed process. Per risolvere l'anomalia è necessario ottimizzare l'impronta di memoria dell'applicazione, ampliare la dotazione di RAM, definire opportuni limiti di consumo delle risorse ed evitare la concorrenza tra troppi processi sulla medesima macchina.

Perché Linux arresta un processo quando la memoria finisce?

La RAM può essere assimilata alla superficie di lavoro di un piano di cottura: l'applicazione, il database engine, i worker in background, il web server e il sistema operativo richiedono tutti una porzione di spazio operativo. Quando lo spazio si esaurisce, l'infrastruttura deve riallocare le risorse per evitare il blocco totale del sistema.

Sui sistemi operativi Linux è presente un meccanismo di emergenza denominato OOM Killer (Out Of Memory Killer). Quando la disponibilità di RAM scende al di sotto della soglia di sicurezza e il sistema non è in grado di allocare ulteriore memoria, l'OOM Killer individua e termina un processo per liberare immediatamente risorse per il kernel.

Per questo motivo un'applicazione può terminare la propria esecuzione all'improvviso: l'interruzione non è necessariamente determinata da un'eccezione non gestita nel codice sorgente, ma può derivare da un intervento diretto del sistema operativo per preservare la stabilità complessiva del server.

Nel log di sistema (/var/log/syslog o journalctl), l'evento viene tracciato tipicamente con una sintassi del tipo:

Out of memory: Killed process 12345 (node) total-vm...

Nel terminale o nei log dei runtime applicativi l'evento può manifestarsi come Killed oppure, negli ambienti di containerizzazione, con la dicitura OOMKilled. Sebbene la terminologia vari, la causa radice risiede sempre nell'eccessiva pressione sulla memoria fisica.

Perché il problema si manifesta sotto carico e non in ambiente di test?

L'aumento dei volumi di traffico modifica drasticamente il profilo di consumo delle risorse dell'applicazione.

Una singola richiesta di rete comporta un impatto minimo; tuttavia, decine di connessioni concorrenti moltiplicano istantaneamente l'occupazione di memoria per la gestione delle I/O, i buffer del database, le elaborazioni dei dati, la visualizzazione dei template e le operazioni in background.

In aggiunta, determinate architetture applicative non rilasciano immediatamente le risorse al termine del ciclo di richiesta/risposta. Se da un lato questo comportamento può essere fisiologico per la gestione delle risorse in cache, dall'altro può segnalare la presenza di un memory leak (perdita di memoria), in cui il runtime omette di liberare la memoria non più utilizzata, portando al progressivo esaurimento della RAM sotto carico continuativo.

Le cause primarie includono:

• Un numero eccessivo di worker o processi applicativi attivi contemporaneamente;
• Un database engine con parametri di allocazione della RAM non ottimizzati;
• L'elaborazione e l'upload di file di grandi dimensioni in memoria;
• L'esecuzione contestuale di task batch/job in background durante i picchi di traffico HTTP;
• Assenza di limiti di memoria definiti per i container Docker;
• La presenza di più progetti ad alto consumo sul medesimo server;
• Difetti nella gestione della memoria nel codice sorgente dell'applicazione (memory leak).

Se la saturazione della RAM è preceduta da un rallentamento generale dell'infrastruttura, il problema fa parte di un'anomalia più ampia di allocazione delle risorse. Per distinguere le diverse tipologie di blocco (CPU, RAM, I/O disco e banda), fa' riferimento alla guida su perché il mio VPS è lento.

Come verificare l'intervento dell'OOM Killer

L'evidenza primaria dell'intervento dell'OOM Killer è data dalla presenza esplicita della stringa Out of memory: Killed process all'interno dei log del kernel Linux. Tale messaggio conferma che la terminazione del processo è stata eseguita dal sistema operativo e non dal runtime applicativo.

Altri indicatori includono:

• L'improvvisa scomparsa del processo senza la registrazione di un'eccezione nei log dell'applicazione.
• Il server rimane raggiungibile via SSH o ICMP, ma il servizio web risulta non disponibile.
• I container Docker si riavviano restituendo lo stato di uscita OOMKilled.
• L'applicazione riprende il normale funzionamento a seguito di un riavvio manuale, per poi arrestarsi nuovamente in corrispondenza del successivo picco di traffico.

È fondamentale distinguere la mancata evasione di una richiesta applicativa (es. errore HTTP 500) dalla scomparsa del processo applicativo dalla tabella dei processi di sistema.

Per una diagnosi precisa occorre correlare tre elementi temporali:

1. L'orario esatto in cui gli utenti hanno segnalato l'indisponibilità del servizio.
2. L'istante in cui il processo applicativo ha cessato l'esecuzione.
3. La registrazione nei log del kernel dell'evento OOM o di un picco di memoria.

Come prevenire l'arresto dell'applicazione per memoria esaurita

Per stabilizzare l'architettura occorre innanzitutto limitare la quantità di operazioni concorrenti ad alto consumo di memoria. La riduzione del numero dei worker applicativi, l'elaborazione dei job in background a lotti (batch) e la gestione in streaming dei file caricati consentono di contenere i picchi di consumo.

In secondo luogo, è necessario analizzare la coesistenza dei servizi sul server. Database, Redis, sistemi di ricerca e applicazioni web attingono tutti alla medesima memoria RAM. La convivenza di più progetti è praticabile, ma senza limiti di risorse definiti un servizio ad alto traffico può saturare la RAM a scapito degli altri processi. Questo scenario è approfondito nella nostra guida su come ospitare più siti web su un unico server.

Se l'impronta di memoria dell'applicazione supera le risorse fisiche erogabili dalla macchina, si rende necessario un adeguamento dell'infrastruttura (scaling verticale). Per definire il dimensionamento corretto dell'hardware senza sovra-dimensionare le risorse, consulta la guida al dimensionamento del VPS.

In caso di utilizzo di ambienti containerizzati, è essenziale impostare opportunamente le direttive di limitazione delle risorse (memory limits). Per comprendere la gestione delle risorse di rete e memoria con Docker, leggi la nostra guida su [Docker su un server per principianti](/blog/docker-su-vps-per-principianti-cos-e-e quando no](/blog/docker-su-vps-per-principianti-cos-e-quando-ti-serve-e-quando-no).

FAQ

**Cosa indica esattamente il messaggio Out of memory: Killed process?** Indica che il sistema operativo Linux ha esaurito la RAM fisica e lo spazio di swap disponibili, spingendo l'OOM Killer a terminare un processo per preservare il funzionamento complessivo del server.

Un intervento dell'OOM Killer è sempre attribuibile a difetti del codice sorgente? Non necessariamente. L'evento può essere causato da picchi di traffico imprevisti, concorrenza eccessiva tra servizi sulla stessa macchina, configurazioni errate dei limiti di memoria o RAM sottodimensionata rispetto al carico effettivo.

Perché l'OOM Killer arresta l'applicazione principale anziché altri servizi di sistema? L'OOM Killer calcola un punteggio dinamico (oom_score) basato sulla percentuale di RAM consumata. I processi ad alto consumo di memoria rappresentano i bersagli primari per liberare immediatamente le risorse necessarie al sistema.

L'aumento della RAM fisica risolve definitivamente il problema? Non sempre. Se l'anomalia è determinata da un memory leak o da processi in background privi di vincoli sulle risorse, l'incremento di memoria rallenta solo il raggiungimento della soglia critica, senza eliminare la causa radice del fallimento.

La soluzione intermedia

Server Manager consente di mantenere visibilità sull'allocazione e sull'impegno delle risorse dell'infrastruttura. Anziché analizzare ex-post la distribuzione di RAM tra applicazioni web, worker, cache e database engine, la dashboard offre un quadro chiaro dell'occupazione delle risorse.

Questo approccio ottimizza la gestione delle problematiche trattate: prevenzione di conflitti tra servizi, monitoraggio del consumo di memoria dei container e identificazione delle condizioni che precedono l'evento Out of memory: Killed process. La leggibilità delle risorse consente di intervenire prima che le limitazioni hardware causino l'interruzione dei servizi ed erogazione.

Il controllo delle specifiche necessarie all'applicazione rimane in capo all'amministratore di sistema, ma l'analisi strutturata dell'infrastruttura permette di prendere decisioni di scalabilità basate sul consumo reale di CPU, RAM e I/O.

La gestione della risorsa di memoria si considera corretta quando l'applicazione risponde entro gli SLA previsti anche durante i picchi di traffico, il margine di RAM libera sul server rimane sopra le soglie di sicurezza e non vengono registrati interventi dell'OOM Killer nei log di sistema.