Lösung 1:
Ich habe mir gerade den Oom-Log-Dump angesehen und bezweifle die Genauigkeit dieser Grafik. Beachten Sie die erste Zeile „Node 0 DMA32“. Dort steht free:3376kB , min:3448kB , und low:4308kB . Immer wenn der freie Wert unter den niedrigen Wert fällt, soll kswapd anfangen, Dinge auszutauschen, bis dieser Wert wieder über den hohen Wert steigt. Immer wenn free unter min fällt, friert das System im Grunde ein, bis der Kernel es wieder über den min-Wert bringt. Diese Meldung zeigt auch an, dass Swap vollständig verwendet wurde, wo Free swap = 0kB steht .
Also im Grunde wurde kswapd ausgelöst, aber swap war voll, also konnte es nichts tun, und der Wert von pages_free war immer noch unter dem Wert von pages_min, also war die einzige Option, Dinge zu töten, bis er pages_free wieder hochfahren konnte.
Ihr Arbeitsspeicher ist definitiv erschöpft.
http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html hat eine wirklich gute Erklärung, wie das funktioniert. Siehe Abschnitt „Implementierung“ unten.
Lösung 2:
Entfernen Sie das drop_caches-Skript. Außerdem sollten Sie die relevanten Teile Ihres dmesg posten und /var/log/messages Ausgabe mit den OOM-Meldungen.
Um dieses Verhalten zu stoppen, würde ich jedoch empfehlen, diesen sysctl auszuprobieren abstimmbar. Dies ist ein RHEL/CentOS 6-System und läuft eindeutig mit eingeschränkten Ressourcen. Ist es eine virtuelle Maschine?
Versuchen Sie, /proc/sys/vm/nr_hugepages zu ändern und sehen, ob die Probleme weiterhin bestehen. Dies könnte ein Problem mit der Speicherfragmentierung sein, aber prüfen Sie, ob diese Einstellung einen Unterschied macht. Um die Änderung dauerhaft zu machen, fügen Sie vm.nr_hugepages = value hinzu zu Ihrem /etc/sysctl.conf und führen Sie sysctl -p aus um die Konfigurationsdatei neu zu lesen...
Siehe auch:Interpretieren von kryptischen Kernel-„Seitenzuordnungsfehler“-Meldungen
Lösung 3:
In der Grafik sind keine Daten vom Start bis zum Ende des OOM-Killers verfügbar. Ich glaube an den Zeitrahmen, in dem der Graph unterbrochen wird, dass der Speicherverbrauch tatsächlich ansteigt und kein Speicher mehr verfügbar ist. Andernfalls würde der OOM-Killer nicht verwendet werden. Wenn Sie sich das Diagramm des freien Speichers ansehen, nachdem der OOM-Killer gestoppt wurde, können Sie sehen, dass es von einem höheren Wert als zuvor abfällt. Zumindest hat es seine Aufgabe richtig erfüllt und Speicher freigegeben.
Beachten Sie, dass Ihr Auslagerungsspeicher bis zum Neustart fast vollständig genutzt wird. Das ist fast nie gut und ein sicheres Zeichen dafür, dass nur noch wenig freier Speicherplatz vorhanden ist.
Der Grund, warum für diesen bestimmten Zeitraum keine Daten verfügbar sind, liegt darin, dass das System mit anderen Dingen zu beschäftigt ist. "Lustige" Werte in Ihrer Prozessliste können nur ein Ergebnis sein, keine Ursache. Das ist nicht ungewöhnlich.
Überprüfen Sie /var/log/kern.log und /var/log/messages, welche Informationen finden Sie dort?
Wenn die Protokollierung ebenfalls gestoppt wurde, versuchen Sie andere Dinge, kopieren Sie die Prozessliste etwa jede Sekunde in eine Datei, ebenso wie die Systemleistungsinformationen. Führen Sie es mit hoher Priorität aus, damit es (hoffentlich) auch bei Lastspitzen seine Arbeit erledigen kann. Wenn Sie jedoch keinen Preempt-Kernel haben (manchmal als "Server"-Kernel bezeichnet), könnten Sie in dieser Hinsicht Pech haben.
Ich denke, Sie werden feststellen, dass die Prozesse, die zu dem Zeitpunkt, zu dem Ihre Probleme beginnen, die meisten CPU-% verbrauchen (werden), die Ursache sind (sind). Ich habe noch nie gesehen, dass sich rsyslogd oder mysql so verhalten. Wahrscheinlichere Übeltäter sind Java-Apps und GUI-gesteuerte Apps wie ein Browser.