Warum stürzt Debian mit OOM ab?

613
Christian Wolf

Ich habe vor kurzem meinen Server von Debian Squeeze i386 auf Wheezy AMD64 aktualisiert, indem ich ihn neu installierte und neu konfigurierte. Außerdem wollte ich virtuelle Gäste starten können, also habe ich auch XEN installiert.

Ich bekam dann das Problem, dass der OOM-Killer von Zeit zu Zeit mehrere Prozesse auf meinem Dom0 zerstörte. Ich habe dann einige Dienste (wie apache2, mysql, postgresql, ...) neu gestartet und deaktiviert. Nun scheint es, dass keine Prozesse mehr zerstört werden (unsicher, da dies nicht regelmäßig geschieht, sondern stochastisch). ABER: Wenn ich die Maschine stark belastet (Zugriff auf verschlüsseltes Dateisystem), ist der OOM-Killer aktiviert.

Leider ist das System nach dem Auftreten des Problems nicht mehr verwendbar. Ich kann also nicht per ssh nachforschen. Auch eine körperliche Untersuchung über die Konsole hängt meistens.

Ich habe einen atopDaemon, der jede Minute läuft, damit ich die Speicher- und Swapbelegung vor dem Absturz sehen kann: Der Arbeitsspeicher ist insgesamt 1 GB (880 MB) (staisch zugewiesen für Dom0, kein Aufblähen). 440 MB sind Cache. Einige MB sind Puffer und ca. 20 MB sind frei. Der Swap ist insgesamt 25 GB und völlig kostenlos.

Was ich nicht verstehe: Warum tötet der Kernel nicht den Cache, wenn mehr RAM benötigt wird. Es handelt sich um einen Cache-Speicher, alles, was passieren könnte, ist ein Leistungsproblem, aber das System bleibt stabil. Auf diese Weise stürzt das System ab. Warum werden nicht benötigte Speicherbereiche auch von anderen Programmen verwendet? Es sollte genügend Platz vorhanden sein, um das zu tun, was Sie wollen.

Ich habe irgendwann auf der Konsole eine Nachricht gesehen, dass eine Task (jbod / raid5 oder ähnliches) für mehr als 120 Sekunden blockiert wurde (?). Ich bin nicht sicher, ob dies die Ursache oder die Auswirkung des OOM-Problems ist.

Nun sind meine Fragen:

  • Könnte es ein XEN-Problem sein?
  • Könnte es ein Hardwareproblem sein? RAM oder HD?
  • Was kann ich tun, um zukünftige Abstürze zu vermeiden?

Edit: Ich habe gerade versucht, den Fehler zu reproduzieren. Es ist zwar abgestürzt, aber diesmal (ich weiß nicht genau, ob in anderen Situationen andere Fehler aufgetreten sind), war das Programm, das hing, xenwatch. Also kein Programm, das auf die HD zugreift.

1
JBOD und RAID5 beziehen sich beide auf den Speicher. Ist es möglicherweise möglich, dass der Speicher ausläuft (entweder Controller oder Festplatten), das System dies erkennt und den Swap somit nicht verwendet, obwohl er verfügbar sein sollte? Zeitüberschreitung beim Speichern ist * nie * ein gutes Zeichen. a CVn vor 11 Jahren 2
Insgesamt gibt es 4 GB und ich möchte die Möglichkeit zu aktualisieren. Christian Wolf vor 11 Jahren 0
@ MichaelKjörling Ich habe 3 Soft-RAID-Geräte: root, ein PVS (beide auf 3 Festplatten) und ein Backup auf 2 Festplatten. Der Swap ist NICHT unter LVM, sondern eine physische Partition auf den 3 Hauptfestplatten. Ich hatte ein Problem mit einer der beiden Sicherungsdisketten. Also habe ich vermutet, dass dies die Probleme verursacht hat. Gibt es eine Möglichkeit zu sagen, dass der Speicher gestorben ist? Christian Wolf vor 11 Jahren 0
Überprüfen Sie die SMART-Informationen für Ihre Laufwerke `sudo smartctl -a / dev / sdX` terdon vor 11 Jahren 0
@terdon Auf der Suche nach was? Irgendwelche Fehler? Es gibt aber Festplatten, die nicht Teil eines RAIDs sind. Nur die Sicherung. (siehe Bearbeiten in der Hauptfrage) Christian Wolf vor 11 Jahren 0
Dies ist nur ein Weg, um zu sehen, ob eine der Festplatten, die Ihren Swap bedienen, stirbt, was dazu führen könnte, dass der Swap nicht mehr verwendet wird. terdon vor 11 Jahren 0
@terdon Alle Festplatten mit Swap-Partitionen melden keine Fehler in der Vergangenheit. Christian Wolf vor 11 Jahren 0

0 Antworten auf die Frage

Verwandte Probleme