Vai al contenuto 
Spiego il Punteggio OOM e OOM Score Adjust come strumenti di controllo concreti nell’ambito dell’hosting: consentono di stabilire quali processi il Linux OOM Killer interrompe in caso di carenza di memoria e quali invece protegge. In questo modo mantengo il controllo quando RAM sta per esaurirsi e assicurati che i servizi essenziali rimangano attivi online.
Punti centrali
Per orientarsi rapidamente, riassumo brevemente i concetti principali.
- Priorità In caso di risorse limitate: l’OOM Score valuta quale processo debba essere terminato per primo.
- Controllo fine con oom_score_adj: da -1000 (proteggere) a +1000 (sacrificare).
- Dinamica anziché un valore fisso: il valore varia in base al carico e alla configurazione.
- Pratica di accoglienza: Proteggere i servizi critici, mentre è preferibile terminare i worker non critici.
- Cause Risolvere: verificare i limiti, i cgroup e la pianificazione della RAM.
Come funziona l'OOM-Killer di Linux
In caso di elevato pressione di accumulo il kernel di Linux decide quali processi terminare per mantenere il sistema reattivo. Osservo come il Kernel assegna a ogni processo una sorta di „ Badness“ che dipende fortemente dall’attuale consumo di memoria. Se non è disponibile una quantità sufficiente di RAM o di spazio di swap, l’OOM-Killer interviene e termina il processo con il punteggio più alto. Questo meccanismo impedisce il blocco del sistema, ma non sostituisce una corretta pianificazione della capacità a livello di host e di servizio. Esamino le decisioni riportate nel log OOM e capisco se un servizio si è reso evidente a causa di un elevato consumo di memoria o di una configurazione errata.
Comprendere l’OOM Score: dinamica e scala
Controllo il Punteggio OOM di un processo in /proc/PID/oom_score e verifico così quanto sia attualmente a rischio. La scala va praticamente da 0 a 1000: più ci si avvicina a 1000, maggiore è la probabilità che il processo venga eliminato dal killer. Questo valore rappresenta un'istantanea, poiché i picchi di carico, i limiti dei cgroup e le dimensioni della cache cambiano continuamente. Per questo motivo non valuto mai il punteggio isolatamente, ma nel contesto della memoria di lavoro, dello swap, dell’overcommit e dei processi paralleli. Chi osserva regolarmente il punteggio riconosce schemi tipici e può prevedere i colli di bottiglia prima che mettano fuori gioco i servizi.
Utilizzare in modo mirato l’OOM Score Adjust
Con oom_score_adj Sposto attivamente il punteggio di un processo da -1000 a +1000. Impostando -1000, proteggo completamente il processo, mentre valori positivi elevati lo rendono intenzionalmente sacrificabile. Scelgo con parsimonia, poiché un numero eccessivo di processi protetti limita il margine di manovra dell’OOM-Killer. I candidati tipici per valori bassi sono SSH, il monitoraggio, i front-end dei reverse proxy e i controller di database sensibili. I processi in background, i reporter o i worker di breve durata ricevono invece un valore più alto, in modo che l’interfaccia utente continui a rispondere anche in caso di risorse limitate.
Stabilire le priorità nell'hosting
Negli ambienti di produzione definisco chiari Priorità tra frontend, API, database ed elaborazione batch. Per prima cosa definisco quali servizi devono rimanere attivi dal punto di vista dell’utente e imposto per essi una regolazione OOM adeguata. In systemd, a tal fine, imposto OOMScoreAdjust= nel file della service unit e documento lo scopo di ciascun valore. Chi gestisce comunque i servizi tramite systemd può snellire i processi; un punto di partenza a tal fine è offerto da systemd nell'hosting. In questo modo prevengo i guasti, invece di lasciarli al caso, e garantisco che l'esperienza utente online funzioni in modo affidabile.
Cgroups, container e limiti
Non dimenticherò mai la cgroups, poiché i container e i servizi operano in ambienti di risorse distinti. Un processo con un punteggio OOM moderato può comunque terminare se il suo cgroup ha un limite di memoria ristretto e lo supera momentaneamente. Per questo motivo verifico i limiti in cgroup v2 e gestisco i limiti rigidi e flessibili in base ai profili di carico. Chi gestisce soluzioni multi-tenancy o di hosting condiviso trae vantaggio da quote e sistemi di contabilità impostati correttamente; ulteriori approfondimenti sono disponibili cgroup v2 nell'hosting. Se l'interazione è corretta, la regolazione dell'OOM e i limiti agiscono come una coppia ben calibrata di viti di regolazione.
Diagnosi e monitoraggio in caso di eventi OOM
Quando succede qualcosa, ho bisogno di indicazioni chiare Segnali e la ripetibilità nell'analisi. Esamino dmesg, journald e /var/log/kern.log, salvo le righe relative all'OOM e rilevo il PID del processo interessato insieme a oom_score e oom_score_adj. Per i controlli di routine utilizzo script che elencano i principali consumatori di memoria e attivano soglie di avviso. Chi desidera approfondire l’argomento troverà un approccio strutturato nel Analisi di OOM-Killer. Nelle configurazioni permanenti integro nel monitoraggio metriche quali RSS, cache, swap-in/out e limiti dei container, in modo da poter individuare tempestivamente le tendenze.
Scheda riassuntiva in formato tabellare per gli amministratori
Utilizzo la seguente panoramica come sintesi Guida, quando stabilisco le priorità dei ruoli e documento gli adeguamenti. La colonna „Motivazione“ indica perché a un servizio viene assegnata la protezione o la disponibilità al sacrificio. Adatto i numeri al progetto, ma l’orientamento generale aiuta a prendere decisioni rapide. Chi utilizza la tabella come punto di partenza ottiene maggiore chiarezza nelle analisi post-mortem e nelle richieste di modifica. L’importante è mantenere sempre un margine di sicurezza nel sistema complessivo, in modo che sia raramente necessario ricorrere a tagli drastici.
| Componente | Destinazione tipica | Esempio oom_score_adj | Motivo |
|---|---|---|---|
| SSH-Daemon | Tiratori | da -500 a -900 | Garantire l'accesso per gli interventi, anche in caso di ingorghi. |
| Proxy inverso (nginx/HAProxy) | Tiratori | da -300 a -700 | Gestire il traffico in entrata, restituire pagine di errore. |
| DB-Controller/Istanza primaria | Tiratori | da -200 a -600 | Mantenere le connessioni, garantire l'accesso ai dati. |
| PHP-FPM/Worker dell'applicazione | Da neutrale a disposto al sacrificio | Da 0 a +300 | È possibile utilizzare molti worker in parallelo. |
| Processi in batch/Backup/Report | Pronto a sacrificarsi | da +300 a +800 | Trasferibile senza alcun impatto per l'utente. |
| Indicizzatore/Consumatore della coda | Pronto a sacrificarsi | da +200 a +600 | È possibile mettere in pausa brevemente; si può recuperare in un secondo momento. |
Limitare correttamente i worker di WordPress e PHP
Quando uso WordPress, faccio attenzione a Lavoratore-Numero, memory_limit e operazioni pesanti come l'elaborazione delle immagini o le importazioni. Configuro PHP-FPM in modo che il numero di processi attivi sia adeguato alla RAM e non provochi un sovraccarico. Per quanto riguarda il database, sommo le dimensioni dei buffer e della cache e lascio un margine di sicurezza, in modo che i picchi di carico non blocchino tutto. Tengo sotto controllo OpCache, la cache degli oggetti e l’ottimizzatore di immagini, poiché possono far aumentare rapidamente il consumo di memoria. In questo modo mi assicuro che brevi picchi di carico non compromettano immediatamente i processi front-end più importanti.
Pratica: politiche e guide operative
Tengo il mio Politiche Conciso e attuabile, affinché il team non esiti in caso di emergenza. Ciò comprende: definire i candidati alla protezione, indicare i ruoli delle vittime, assegnare a systemd-units il parametro OOMScoreAdjust= e documentare i valori nel repository. Verifico l’efficacia utilizzando strumenti e carichi di prova, finché l’ordine delle unità sacrificabili non corrisponde agli obiettivi. Successivamente redigo un playbook che descrive i log, gli allarmi e le misure iniziali. In questo modo la reazione rimane coerente, anche quando subentrano nuovi colleghi.
# Esempio di frammento per un'unità systemd
[Service]
OOMScoreAdjust=-400
# Ricaricamento e riavvio:
# systemctl daemon-reload && systemctl restart nginx
# Verifica in corso:
cat /proc/$(pidof nginx)/oom_score
cat /proc/$(pidof nginx)/oom_score_adj
# Aumentare/ridurre temporaneamente (root):
echo 300 | sudo tee /proc//oom_score_adj
Errori frequenti e contromisure
Molti problemi sorgono perché Limiti Non sono compatibili: troppi worker PHP, cache del database troppo grandi e nessun margine per i picchi di carico. A quel punto l’OOM-Killer interviene regolarmente, anche se basterebbero poche regolazioni. Per prima cosa correggo il numero di worker, ne valuto l’effetto e aumento la RAM solo se il fabbisogno risulta evidente. Anche impostare molti processi su -1000 è dannoso, poiché il kernel ha bisogno di libertà d’azione. Assegno le priorità con buon senso, in modo che il sistema possa reagire in modo ordinato in caso di emergenza.
Overcommit, swap e livelli di memoria
Presento la mia Strategia di overcommit viene impostato consapevolmente, poiché determina la velocità con cui un sistema entra nella zona OOM. Con vm.overcommit_memory=0 (euristica) spesso ottengo un funzionamento stabile, poiché il kernel valuta il limite di overcommit in base all’utilizzo e alla cronologia. La situazione diventa più rigorosa con vm.overcommit_memory=2 più vm.overcommit_ratio, che definisce l’occupazione virtuale massima consentita. Chi imposta vm.overcommit_memory=1 in modo generico rischia che le prenotazioni di memoria vadano a buon fine ma falliscano poi miseramente in fase di allocazione – un terreno fertile per gli eventi OOM sotto carico.
Calibro Scambio in modo tale da fornire un buffer senza però diventare un fattore che aumenta la latenza. Un valore moderato di vm.swappiness mantiene libera la memoria principale per i percorsi più intensi, mentre le pagine utilizzate raramente vengono spostate. Posso utilizzare zswap o zram come riserva elastica quando l’I/O è lento: ciò riduce il rischio di OOM, ma comporta un consumo di CPU. Anche i livelli di memoria sono importanti: vm.min_free_kbytes deve essere sufficientemente alto affinché il kernel possa recuperare memoria in tempo. Chi imposta valori troppo bassi costringe il sistema a un recupero frenetico e provoca problemi di percorso che sfociano in OOM.
# Esempio: overcommit conservativo e swapping moderato
sysctl -w vm.overcommit_memory=2
sysctl -w vm.overcommit_ratio=90
sysctl -w vm.swappiness=30
# Per i test, inserire le impostazioni in modo permanente in /etc/sysctl.d/
Opzioni di systemd oltre a OOMScoreAdjust
Oltre a OOMScoreAdjust, utilizzo systemd per Barriere di contenimento da impostare direttamente sul servizio. Con MemoryMax= impongo un limite rigido (cgroup memory.max), MemoryHigh= limita delicatamente l’utilizzo in caso di carico elevato e MemorySwapMax= limita lo swap. MemoryLow= e MemoryMin=, in caso di pressione, danno priorità alle porzioni di cache di un servizio, in modo che i processi importanti non si raffreddino troppo rapidamente. Insieme a OOMPolicy=, controllo cosa fa systemd in caso di OOM a livello di unità (ad es. arrestare solo il servizio o terminare tutte le dipendenze). In Slices raggruppo i ruoli – front-end web, batch, DB – e ne deduco regole uniformi, in modo che singoli casi anomali non destabilizzino l’insieme.
Faccio notare che la protezione non è mai assoluta: anche i processi con -1000 possono essere costretti a cedere in situazioni senza via d'uscita. Per questo motivo applico valori generosi, ma realistici Minima (MemoryLow/Min) solo per pochissimi servizi fondamentali e verifico che la somma di tutte le assegnazioni rimanga al di sotto della memoria fisicamente disponibile. In questo modo evito che misure di protezione, per quanto ben intenzionate, rendano cieco l’OOM-Killer.
Kubernetes e l'orchestrazione dei container
In ambienti di orchestrazione come Kubernetes, la logica OOM opera su più livelli. Io utilizzo Richieste e Limiti in modo che i pod rientrino nella classe di QoS desiderata: Guaranteed offre la massima protezione, Burstable funge da ammortizzatore, mentre BestEffort è la più vulnerabile. Il kubelet assegna automaticamente i valori OOMScoreAdjust risultanti; pertanto, pianifico in base alle specifiche delle risorse anziché a valori di ottimizzazione manuali nei container. Se un container raggiunge il proprio memory.limit, viene terminato all’interno del proprio cgroup anche se l’host dispone ancora di memoria libera; non si tratta di un classico OOM dell’host, bensì di un’autodifesa mirata del limite.
Prendo in considerazione quote di memoria nativa al di fuori delle configurazioni dell'heap (ad esempio per JVM/nodo), in modo che i container non vadano in crash inaspettatamente al raggiungimento del limite. Inoltre, calcolo un margine di sicurezza per i pod in previsione dei picchi e pianifico l'overcommit dei nodi solo con moderazione, affinché gli eviction siano rari. Se cgroup v2 è attivo, utilizzo memory.oom.group in modo mirato, in modo che, in caso di emergenza, un intero gruppo di processi venga terminato in modo ordinato, invece di lasciare singoli worker in un pod zombie. Ciò mantiene il sistema pulito e rende il ripristino prevedibile.
Approfondimento diagnostico: SMaps, PSI e test riproducibili
Per analisi approfondite ricorro a /proc-Informazioni e metriche di carico. /proc/PID/status mostra VmRSS, VmSwap e i thread; /proc/PID/smaps_rollup riassume le percentuali relative ad Anon, File e Shmem, senza farmi perdere nei dettagli. In questo modo capisco se la Page Cache è ingannevole o se le pagine anonime (dati di lavoro effettivi) stanno aumentando. Con /proc/pressure/memory misuro PSI-Segnali, ovvero per quanto tempo il sistema subisce un reclaim attivo o degli stalli. Impostiamo degli allarmi su questi valori molto prima che si verifichi un OOM – l’ideale per attivare automaticamente delle contromisure (throttling, scalabilità, riduzione dei worker).
# Istantanee rilevanti
journalctl -k -g "Out of memory|oom-killer"
cat /proc/pressure/memory
grep -E "VmRSS|VmSwap|Threads" /proc//status
cat /proc//smaps_rollup
# Riprodurre l'OOM (ambiente di test!)
stress-ng --vm 2 --vm-bytes 80% --timeout 30s
Casi particolari: JVM, Node.js e PHP nei container
JVM-I servizi richiedono attenzione, poiché oltre all'heap vanno considerati anche il metaspazio, gli stack dei thread, i buffer diretti e il comportamento nativo dell'allocatore. Gestisco i contenitori in modo ottimizzato utilizzando MaxRAMPercentage e imposta un heap che lasci margine per queste componenti. In caso di elevato parallelismo, limito i pool di thread, poiché molti stack di piccole dimensioni si sommano in modo significativo. Per Nodo.js adatto il valore di –max-old-space-size al limite del container per evitare interruzioni forzate. E in caso di PHP-FPM Calcolo pm.max_children in base alla RAM, al consumo medio per richiesta e al memory_limit, aggiungendo una riserva per le cache e il server web. In questo modo evito che si verifichino "valanghe" silenziose, che diventano visibili solo nei momenti di picco.
Conservo il Strategia di allocazione Da tenere d’occhio: glibc con molte arene può frammentare la memoria e farne aumentare il consumo in carichi di lavoro con molti thread. Per determinati servizi, jemalloc o tcmalloc garantiscono picchi più costanti; sto effettuando test mirati, documentando l’effetto e implementando la soluzione in modo controllato. Inoltre, limito le directory tmpfs all’interno del container, in modo che gli upload o i file temporanei non consumino la RAM in modo inosservato.
Tmpfs, Huge Pages e cache delle pagine
tmpfs È un aspetto che spesso viene trascurato: senza un limite di dimensione, cresce fino a occupare una parte della RAM e all’improvviso manca spazio altrove. Io monto i tmpfs specificando consapevolmente il parametro size=, soprattutto nei percorsi di compilazione o di upload. Pagine enormi trasparenti (THP) La frammentazione e la latenza influiscono sulle prestazioni; per i servizi in cui la latenza è un fattore critico, utilizzo spesso „madvise“, in modo che solo le allocazioni idonee ne traggano vantaggio. KSM è in grado di deduplicare i dati e risparmiare spazio di memoria, ma comporta un carico sulla CPU: è utile sugli host di sviluppo, mentre nei percorsi critici per le prestazioni ne valuto l’efficacia e l’overhead.
Il sito Cache delle pagine Non si tratta di memoria „sprecata“; accelera le operazioni di I/O. Se la libero in modo troppo aggressivo o utilizzo le cache di drop come misura permanente, trasferisco i costi sotto forma di picchi di latenza. È preferibile definire obiettivi di memoria per ogni ruolo e imporre un rapporto equo tramite i meccanismi cgroup (memory.high / memory.max). In questo modo, gli hotset dei servizi importanti rimangono nella RAM e le situazioni di OOM diventano più rare.
Riassunto per la vita di tutti i giorni
Io uso il Punteggio OOM come indicatore di rischio e, tramite oom_score_adj, regolo la corretta sequenza delle risorse da sacrificare. Proteggo i servizi che hanno un impatto sugli utenti, rendo sacrificabili i processi non essenziali e documento ogni valore in modo tracciabile. Pianifico i limiti dei cgroup, il numero di worker e le dimensioni della cache come un unico insieme, in modo che i picchi non provochino un effetto a catena. I log, il monitoraggio e un breve playbook mi consentono di individuare rapidamente gli eventi OOM e di risolverli in modo mirato. Grazie a questa disciplina, l’host rimane affidabile ed evito brutte sorprese durante le notti di produzione.
