Debug di memoria insufficiente con / var / log / messaggi

Il seguente rapporto viene inserito nel mio registro dei messaggi:

kernel: Out of memory: Kill process 9163 (mysqld) score 511 or sacrifice child
kernel: Killed process 9163, UID 27, (mysqld) total-vm:2457368kB, anon-rss:816780kB, file-rss:4kB

Non importa se questo problema è per httpd, mysqldo postfixma sono curioso come posso continuare il debug del problema.

Come posso ottenere maggiori informazioni sul perché il PID 9163 viene ucciso e non sono sicuro che Linux mantenga la cronologia dei PID terminati da qualche parte.

Se ciò si verifica nel file di registro dei messaggi, come risolvere questo problema passo dopo passo?

# free -m

             total       used       free     shared    buffers     cached
Mem:          1655        934        721          0         10         52
-/+ buffers/cache:        871        784
Swap:          109          6        103`

Il kernel avrà registrato un sacco di cose prima che ciò accadesse, ma la maggior parte probabilmente non ci sarà /var/log/messages, a seconda di come (r)syslogdè configurato. Provare:

grep oom /var/log/*
grep total_vm /var/log/*

Il primo dovrebbe presentarsi più volte e il secondo in uno o due posti. Questo è il file che vuoi guardare.

Trova la riga "Memoria esaurita" originale in uno dei file che contiene anche total_vm. Trenta secondi a un minuto (potrebbe essere di più, potrebbe essere di meno) prima di quella riga troverai qualcosa del tipo:

kernel: foobar invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

Dovresti anche trovare una tabella tra quella riga e la riga "Memoria insufficiente" con intestazioni come questa:

[ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name

Questo potrebbe non dirti molto più di quello che già sai, ma i campi sono:

• pid L'ID processo.
• uid ID utente.
• tgid ID gruppo discussione.
• total_vm Utilizzo della memoria virtuale (in pagine da 4 kB)
• rss Uso della memoria residente (in pagine da 4 kB)
• nr_ptes Voci della tabella delle pagine
• swapents Scambia voci
• oom_score_adj Di solito 0; un numero inferiore indica che il processo avrà meno probabilità di morire quando viene invocato il killer OOM.

Puoi principalmente ignorare nr_ptese swapentsanche se credo che questi siano fattori nel determinare chi viene ucciso. Questo non è necessariamente il processo che utilizza più memoria, ma molto probabilmente lo è. Per ulteriori informazioni sulla procedura di selezione, vedere qui . Fondamentalmente, il processo che finisce con il punteggio più alto oom viene ucciso - questo è il "punteggio" riportato sulla riga "Memoria insufficiente"; purtroppo gli altri punteggi non sono riportati ma quella tabella fornisce alcuni indizi in termini di fattori.

Ancora una volta, questo probabilmente non farà altro che illuminare l'ovvio: il sistema ha esaurito la memoria ed è mysqldstato scelto di morire perché ucciderlo avrebbe liberato la maggior parte delle risorse . Questo non significa necessariamente che mysqldsta facendo qualcosa di sbagliato. Puoi guardare la tabella per vedere se qualcos'altro è andato fuori posto in quel momento, ma potrebbe non esserci alcun chiaro colpevole: il sistema può esaurire la memoria semplicemente perché hai giudicato male o hai configurato male i processi in esecuzione.

La chiave di ciò è nel messaggio stesso: memoria insufficiente . Quando il kernel Linux è affamato di memoria virtuale (RAM fisica più swap) inizierà a uccidere i processi ed è esattamente quello che è successo qui. Sembra che mysqldstesse usando oltre 2 GB di memoria virtuale.

Quanta RAM e swap ha il sistema? Prenderei in considerazione l'aggiunta di ulteriore RAM o, se ciò non fosse possibile, l'aggiunta di ulteriore scambio. Come soluzione rapida per impedire almeno la chiusura dei processi è possibile aggiungere un file di scambio.

Aggiornamento: guardando la quantità di RAM che hai, puoi immediatamente vedere il problema. Hai ~ 1.6GB di RAM e 100 MB di swap, ma MySQL sta usando molta più RAM di quella. Questo spiega perché stai vedendo che i processi sono terminati.