158 29/03/2026 07/04/2026 6 min

Perché questo controllo è importante

Quando un server Linux sembra “lento”, va in blocco o comincia a rispondere a scatti, la RAM è uno dei primi indicatori da verificare. Non sempre “memoria alta” significa problema: Linux usa la RAM anche per cache e buffer, e questo è normale. Il punto critico è distinguere tra uso fisiologico e consumo anomalo che porta a swap massiccio, OOM killer o servizi instabili.

In pratica, se il sistema sta consumando troppa RAM davvero, di solito compaiono segnali come processi uccisi dal kernel, siti in timeout, database che rallentano, PHP-FPM saturato o swapping continuo. La diagnosi corretta evita riavvii inutili e aiuta a intervenire sul processo giusto, non sul sintomo.

Diagnosi probabile

Le cause più comuni sono queste:

  1. Un processo applicativo è cresciuto oltre il normale, ad esempio PHP-FPM, MySQL/MariaDB, Java, Node.js o un worker di coda.
  2. La memoria libera sembra bassa ma il server usa soprattutto cache: in questo caso il problema non è la RAM, bensì la pressione sulla memoria o un picco temporaneo.
  3. Lo swap è in forte utilizzo e il sistema va lento perché sta spostando pagine di memoria su disco.
  4. Il kernel ha attivato l’OOM killer e ha terminato un processo per salvare il sistema.
  5. Un leak di memoria applicativo o un numero eccessivo di child process stanno saturando la macchina.

In molti casi la prima ipotesi da verificare è semplice: un singolo servizio sta assorbendo più RAM del previsto. Se invece il carico è distribuito su più processi, bisogna guardare concorrenza, limiti del pool e configurazioni del servizio.

Verifiche immediate

Prima di modificare qualcosa, controlla questi elementi con attenzione. Sono rapidi e danno subito un quadro utile.

  1. Verifica il riepilogo memoria con free -h: il dato importante non è solo “used”, ma anche available e swap in uso. Se available è basso e swap cresce, c’è pressione reale sulla RAM.
  2. Controlla i processi che consumano più memoria con top oppure htop: ordina per memoria e identifica il processo dominante. Esito atteso: il colpevole appare subito in cima alla lista.
  3. Se sospetti il kernel, cerca eventi OOM con dmesg -T | grep -i -E 'oom|killed process|out of memory'. Esito atteso: eventuali righe indicano quale processo è stato terminato e quando.
  4. Osserva lo swap con swapon --show e con vmstat 1 5: se la colonna si/so continua a salire, il sistema sta swappando attivamente e questo spiega il rallentamento.
  5. Se il server ospita database o web server, controlla il servizio specifico: ad esempio systemctl status mariadb, systemctl status mysql o systemctl status php-fpm. Esito atteso: capire se il problema nasce da uno di questi servizi e non dal sistema in generale.

Se hai accesso a un pannello hosting, verifica anche i grafici di risorse: RAM, swap, CPU e I/O disco. Una RAM alta con I/O disco alto e swap attivo è un segnale molto più grave di una RAM alta ma stabile, senza swap.

Soluzione consigliata passo-passo

La soluzione più sicura è procedere per priorità: prima capire chi consuma, poi ridurre il picco, infine correggere la causa strutturale. Evita riavvii “alla cieca” se il server è in produzione, perché potresti solo nascondere il problema per qualche minuto.

  1. Identifica il processo responsabile. Usa top o htop e annota nome processo, PID e percentuale di memoria. Se il responsabile è un servizio web, verifica quanti worker sono attivi; se è il database, controlla query lente e buffer troppo aggressivi.
  2. Riduci il picco in modo reversibile. Se il processo è fuori controllo, prova prima a riavviare solo il servizio coinvolto, non l’intero server. Per esempio, se è PHP-FPM: systemctl restart php-fpm oppure la variante della tua versione, come php8.2-fpm. Se è MariaDB/MySQL, riavvialo solo dopo aver verificato che l’impatto sul sito sia accettabile.
  3. Verifica se c’è un leak o una configurazione troppo permissiva. Nei pool PHP-FPM controlla parametri come numero di child, memoria per processo e timeout. Se hai molti processi PHP contemporanei, abbassa la concorrenza o abilita una cache opcode e una cache applicativa. Per il database, controlla buffer e connessioni simultanee: un innodb_buffer_pool_size troppo alto può soffocare il resto del sistema.
  4. Intervieni sulla swap solo come supporto, non come soluzione. Se lo swap è assente, puoi crearne uno solo se il server ha abbastanza disco libero e se la pressione RAM è reale. È una misura di emergenza per evitare crash, ma non sostituisce il tuning della memoria. Dopo l’attivazione, verifica con swapon --show e monitora se il sistema smette di andare in sofferenza.
  5. Riduci i consumi dei processi noti. Per applicazioni web, limita worker e cache inutili; per database, riduci buffer e query pesanti; per servizi Java o Node, imposta limiti di heap o memoria. Se il server ospita più siti, verifica se uno solo genera il picco e isola il problema sul virtual host o sul container corrispondente.
  6. Controlla i log dell’applicazione. Se il consumo è anomalo, spesso ci sono errori ripetuti che causano loop, retry continui o accumulo di processi. Cerca nei log di Apache, Nginx, PHP, database e applicazione. Esito atteso: individuare errori ripetuti o richieste che si moltiplicano.

Se vuoi un approccio prudente, la sequenza migliore è: misura, identifica, limita, verifica. In questo ordine eviti di cambiare parametri a caso e riduci il rischio di fermare servizi sani.

Esempio pratico di triage rapido

Questa mini-sequenza è utile quando il server è già sotto pressione:

free -h
htop
dmesg -T | grep -i -E 'oom|killed process|out of memory'
swapon --show

Se htop mostra un solo processo in cima, hai già una pista forte. Se invece la RAM è quasi tutta occupata ma la colonna available resta accettabile e non c’è swap attiva, potresti essere davanti a uso normale della cache.

Controlli finali / rollback

  1. Dopo ogni modifica, controlla che la memoria sia tornata in un range sostenibile con free -h e che lo swap non continui a crescere. Esito atteso: available stabile e attività di swap in calo o assente.
  2. Verifica che il servizio coinvolto risponda correttamente con systemctl status e, se è un servizio web, con una richiesta HTTP o con il pannello del sito. Esito atteso: nessun crash, nessun timeout e nessun nuovo errore nei log.
  3. Se il problema si ripresenta dopo il riavvio del servizio, valuta rollback dei parametri appena cambiati e torna alla configurazione precedente. Prima di modificare file come pool PHP, config MariaDB o unit systemd, fai sempre un backup del file originale.
  4. Se compare di nuovo un evento OOM, considera il rollback del cambiamento più recente e pianifica un aumento RAM, una separazione dei servizi o una revisione dei limiti di concorrenza.

Una buona regola è questa: se la correzione migliora subito la situazione ma il problema torna nelle ore o nei giorni successivi, non è risolto davvero. In quel caso servono metriche storiche su RAM, swap, load average, I/O e log applicativi per capire se il server è sottodimensionato o se c’è un processo che cresce senza controllo.

Checklist rapida

  • Controlla free -h e guarda soprattutto available e swap.
  • Ordina i processi per memoria con top o htop.
  • Cerca eventi OOM con dmesg -T.
  • Verifica il servizio responsabile con systemctl status.
  • Conferma che il problema non ritorni dopo il fix.

Se il server è in produzione e i dati non sono ancora sufficienti, la priorità resta la diagnosi del processo responsabile e del servizio impattato, perché è il passaggio che evita di agire alla cieca.