OOM Killer funktioniert nicht?

Soweit ich weiß, sollte der Kernel Prozesse abbrechen, wenn das System fast keinen freien Speicher mehr hat, um Speicher wiederzugewinnen. Aber in meinem System passiert das überhaupt nicht.

Angenommen, ein einfaches Skript weist nur viel mehr Speicher zu als im System verfügbar ist (z. B. ein Array mit Millionen von Zeichenfolgen). Wenn ich ein Skript wie dieses (als normaler Benutzer) ausführe, wird nur der gesamte Speicher abgerufen, bis das System vollständig einfriert (nur SysRQ REISUB funktioniert).

Der seltsame Teil hier ist, dass, wenn der Computer einfriert, die Festplatten-LED aufleuchtet und so bleibt, bis der Computer neu gestartet wird, entweder wenn ich eine Swap-Partition installiert habe oder nicht!

Meine Fragen sind also:

1. Ist dieses Verhalten normal? Es ist seltsam, dass eine Anwendung, die als normaler Benutzer ausgeführt wird, das System auf diese Weise zum Absturz bringen kann ...
2. Gibt es eine Möglichkeit, Ubuntu dazu zu bringen, diese Anwendungen automatisch zu beenden, wenn sie zu viel (oder den meisten) Speicher haben?

Zusätzliche Information

• Ubuntu 12.04.3
• Kernel 3.5.0-44

• RAM: ~ 3,7 GB von 4 GB (gemeinsam mit der Grafikkarte). *

  $ tail -n+1 /proc/sys/vm/overcommit_*
  ==> /proc/sys/vm/overcommit_memory <==
  0
  
  ==> /proc/sys/vm/overcommit_ratio <==
  50
  
  $ cat /proc/swaps
  Filename                Type        Size    Used    Priority
  /dev/dm-1                               partition   4194300 344696  -1
  

Aus der offiziellen /proc/sys/vm/*Dokumentation :

oom_kill_allocating_task

Dies aktiviert oder deaktiviert das Beenden der OOM-auslösenden Task in Situationen, in denen nicht genügend Arbeitsspeicher vorhanden ist.

Wenn dieser Wert auf Null gesetzt ist, durchsucht der OOM-Killer die gesamte Jobliste und wählt eine Aufgabe basierend auf den zu tötenden Heuristiken aus. Dies wählt normalerweise einen Rogue Memory-Hogging-Task aus, der beim Beenden eine große Menge an Speicher freigibt.

Wenn dies auf einen Wert ungleich Null festgelegt ist, bricht der OOM-Killer einfach die Task ab, die den Zustand "Nicht genügend Speicher" ausgelöst hat. Dies vermeidet den teuren Joblisten-Scan.

Wenn panic_on_oom ausgewählt ist, hat es Vorrang vor dem Wert, der in oom_kill_allocating_task verwendet wird.

Der Standardwert ist 0.

Um zusammenzufassen bei der Einstellung oom_kill_allocating_taskzu 1, anstatt das System zu scannen für Prozesse zu töten suchen, die eine teuere und langsame Aufgabe ist, wird der Kernel tötet nur den Prozess, der das System verursachten Speicher raus.

Nach meinen eigenen Erfahrungen hat der Kernel beim Auslösen eines OOM nicht mehr genügend "Stärke", um einen solchen Scan durchzuführen, was das System völlig unbrauchbar macht.

Es wäre auch offensichtlicher, nur die Aufgabe zu beenden, die das Problem verursacht hat, sodass ich nicht verstehe, warum dies 0standardmäßig festgelegt ist.

Zum Testen können Sie einfach in die richtige Pseudodatei schreiben, die /proc/sys/vm/beim nächsten Neustart wieder rückgängig gemacht wird:

echo 1 | sudo tee /proc/sys/vm/oom_kill_allocating_task

Für eine dauerhafte Korrektur schreiben Sie Folgendes in /etc/sysctl.confoder in eine neue Datei /etc/sysctl.d/mit einer .confErweiterung ( /etc/sysctl.d/local.confzum Beispiel):

vm.oom_kill_allocating_task = 1

Update: Der Fehler ist behoben.

Teresas Antwort reicht aus, um das Problem zu umgehen, und ist gut.

Zusätzlich habe ich einen Fehlerbericht eingereicht , da dies definitiv ein fehlerhaftes Verhalten ist.

Sie können earlyoom ausprobieren , einen OOM-Killer, der im Benutzerbereich arbeitet und versucht, den größten Prozess in einer OOM-Situation zu beenden.

Zunächst empfehle ich das Update auf 13.10 (Neuinstallation, Daten sichern).

Wenn Sie nicht aktualisieren möchten, ändern Sie die Datei vm.swappiness auf 10. Wenn Sie Probleme mit Ihrem RAM haben, installieren Sie zRAM.