Soluzione 1:
Ho appena guardato il dump del registro di oom e metto in dubbio l'accuratezza di quel grafico. Notare la prima riga "Nodo 0 DMA32". Dice free:3376kB , min:3448kB e low:4308kB . Ogni volta che il valore gratuito scende al di sotto del valore basso, kswapd dovrebbe iniziare a scambiare cose fino a quando quel valore non torna al di sopra del valore alto. Ogni volta che il valore libero scende al di sotto del minimo, il sistema sostanzialmente si blocca fino a quando il kernel non lo riporta al di sopra del valore minimo. Quel messaggio indica anche che swap è stato completamente utilizzato dove dice Free swap = 0kB .
Quindi fondamentalmente kswapd si è attivato, ma lo scambio era pieno, quindi non poteva fare nulla e il valore pages_free era ancora al di sotto del valore pages_min, quindi l'unica opzione era iniziare a uccidere le cose fino a quando non poteva ottenere il backup di pages_free.
Hai decisamente esaurito la memoria.
http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html ha un'ottima spiegazione di come funziona. Consulta la sezione "Implementazione" in fondo.
Soluzione 2:
Sbarazzati dello script drop_caches. Inoltre, dovresti pubblicare le parti rilevanti del tuo dmesg e /var/log/messages output che mostra i messaggi OOM.
Per fermare questo comportamento, però, ti consiglio di provare questo sysctl sintonizzabile. Questo è un sistema RHEL/CentOS 6 ed è chiaramente in esecuzione su risorse limitate. È una macchina virtuale?
Prova a modificare /proc/sys/vm/nr_hugepages e vedere se i problemi persistono. Questo potrebbe essere un problema di frammentazione della memoria, ma verifica se questa impostazione fa la differenza. Per rendere permanente la modifica, aggiungi vm.nr_hugepages = value al tuo /etc/sysctl.conf ed esegui sysctl -p per rileggere il file di configurazione...
Vedi anche:Interpretazione dei messaggi criptici di "errore di allocazione della pagina" del kernel
Soluzione 3:
Non ci sono dati disponibili sul grafico da quando inizia il killer OOM fino a quando non finisce. Credo che nell'intervallo di tempo in cui il grafico viene interrotto, in effetti il consumo di memoria aumenta e non c'è più memoria disponibile. Altrimenti l'OOM killer non verrebbe utilizzato. Se guardi il grafico della memoria libera dopo che il killer OOM si è fermato, puoi vedere che scende da un valore più alto rispetto a prima. Almeno ha svolto correttamente il suo lavoro, liberando memoria.
Nota che il tuo spazio di swap è quasi completamente utilizzato fino al riavvio. Non è quasi mai una buona cosa e un segno sicuro che è rimasta poca memoria libera.
Il motivo per cui non sono disponibili dati per quel particolare periodo di tempo è perché il sistema è troppo occupato con altre cose. I valori "divertenti" nell'elenco dei processi potrebbero essere solo un risultato, non una causa. Non è inaudito.
Controlla /var/log/kern.log e /var/log/messages, quali informazioni puoi trovare lì?
Se anche la registrazione si è interrotta, prova altre cose, scarica l'elenco dei processi in un file ogni secondo circa, lo stesso con le informazioni sulle prestazioni del sistema. Eseguilo con alta priorità in modo che possa ancora svolgere il suo lavoro (si spera) quando il carico aumenta. Anche se non hai un kernel preempt (a volte indicato come kernel "server") potresti essere sfortunato a riguardo.
Penso che scoprirai che il / i processo / i che sta (stanno) utilizzando la maggior parte della CPU% nel momento in cui iniziano i tuoi problemi è (sono) la causa. Non ho mai visto rsyslogd né mysql comportarsi in quel modo. È più probabile che i colpevoli siano le app java e le app gui come un browser.