it-swarm.com.de

Verhindern Sie, dass Ubuntu einfriert, auch wenn der Systemspeicher niedrig ist

Manchmal arbeite ich mit riesigen Datenmengen, die ich zur Verarbeitung im Speicher behalten möchte. Manchmal berechne ich die Menge an Speicher, die mein Programm produzieren wird, falsch, oder ein Debugger multipliziert die Speichernutzung mit einem Faktor, der meinen verfügbaren Speicher überschreitet.

Wann immer ich einen speicherhungrigen Prozess starte, ist dies das, was ich von einem vernünftigen Betriebssystem erwarte: Versuchen Sie, den gesamten freien Speicher zu verbrauchen, und bitten Sie dann einige andere nicht wesentliche Prozesse, den nicht benötigten Speicher aufzugeben schreibe um zu tauschen.

Hier ist, was Ubuntu für mich tut: Essen Sie den gesamten freien Speicher, und bitten Sie das Betriebssystem, alle wichtigen Dienste (Gnome-Sitzung, Terminal, Tastatur) auszutauschen. Frieren Sie dann ein und warten Sie, bis ich den Netzstecker gezogen habe.

Zwei Fragen:

  1. Wie kann ein Betriebssystem annehmen, dass etwas so wichtig sein könnte, dass es in Ordnung ist, keine Benutzereingaben mehr abzuhören?
  2. Wie kann ich Ubuntu anweisen, niemals wichtige Dienste auszutauschen und immer auf Benutzereingaben zu reagieren, selbst wenn ein dummer Prozess versucht, mehr Ressourcen zu verbrauchen, als das System bereitstellt?.
20
Klamann

Ich habe immer noch keine Lösung für das Problem, aber ich kann zwei Problemumgehungen anbieten, die für andere von Interesse sein könnten:

1) frühes Zimmer

Dies ist ein Dienst, der die Speichernutzung überwacht und den Prozess beendet, der den meisten Speicher verbraucht, wenn ein bestimmter Schwellenwert erreicht wird (siehe auch dieses und Diese Frage zum OOM-Killer im Linux-Kernel)

Ich habe es mit einem Demo-Prozess getestet, der unbegrenzt Speicher in kleinen Blöcken anfordert. Hier ist mein erster Eindruck: Wenn ich den Rogue-Prozess starte, wird mein gesamter RAM schnell aufgebraucht. Sobald der Austausch beginnt, reagiert das System nicht mehr. Einige Sekunden später ist das System wieder online. Das Protokoll von earlyoom zeigt, dass es den Speicherfressprozess beendet hat, nachdem sowohl die Speicher- als auch die Auslagerungsauslastung 90% erreicht hatte.

Es gibt immer noch die lästige Verzögerung, wenn das Austauschen beginnt, und nachdem der Prozess beendet wurde, verbleiben einige Teile anderer Prozesse normalerweise im Austausch, bis sie angefordert werden, aber es ist ein Anfang.

2) einfach Swap deaktivieren

Ich weiß, dass dies ein kontroverses Thema ist , aber für den Zweck von Desktop-Systemen und insbesondere Entwicklungsmaschinen, bei denen es gelegentlich vorkommen kann, dass ein Prozess versucht, dies zu tun Es macht Sinn, all dein Gedächtnis aufzuzehren: Ohne Tausch funktioniert der OOM-Killer nur wie beabsichtigt. Wenn Ihnen der Speicher ausgeht, findet er den besten Prozess zum Beenden und entfernt ihn. Keine Verzögerung, keine Verzögerung.

Sie können den Swap für die aktuelle Sitzung mit Sudo swapoff -a deaktivieren oder die Änderung dauerhaft machen .


Die richtige Lösung für das Problem wäre natürlich, dass das System reagiert, wenn der Hauptspeicher erschöpft ist und es beginnt, den Speicher auszutauschen, als gäbe es kein Morgen, aber das scheint nicht in Kürze zu geschehen.

4
Klamann

Ich habe ein ähnliches Problem gelöst. Ich weiß nicht, ob meine Erfahrung zu Ihnen passt ...

Kürzlich habe ich eine Anleitung veröffentlicht, wie man Linux auf Loopback-LVM-Geräten installiert, die von USB booten (also ohne grub auf der internen Festplatte installieren zu müssen und es als Original zu belassen). Hier ist die Anleitung: https://github.com/DareDevil73/linux-on-loopback-usb .

Dann fiel ich in das Einfrierproblem bei hoher Speicherauslastung und stellte eine abnormale Auslastung des Auslagerungsspeichers fest (alle RAM wurden ausgelastet und die Auslagerungsauslastung lag nahe Null). Offensichtlich war die LVM-Swap-Partition aktiviert und funktionierte ordnungsgemäß, aber ich wusste nicht, warum der Kernel sie nicht erwartungsgemäß verwendete.

Ich habe eine alternative Lösung ausprobiert. Ich habe eine Swap-Loopback-Datei (nicht LVM) erstellt und das Einfrieren ist weg. Jetzt wird die Auslagerungsdatei wie gewohnt verwendet und das Betriebssystem friert niemals ein!

Bitte schauen Sie unter https://github.com/DareDevil73/linux-on-loopback-usb#known-issues nach, um genauere Informationen zu erhalten.

0

Ubuntu 16.04 wird mit der Kernel-Version 4.4 ausgeliefert. In der Kernel-Version 4.6 wurde der OOM-Killer (Out of Memory Task Killer) grundlegend überarbeitet, um Beschwerden wie Ihren zu begegnen. Kernel-Version 4.6 ist am Ende des Lebens und die aktuelle Ubuntu-Kernel-Version 4.7.2 ist auf der Website. Es behebt neben dem Upgrade des oom_reaper-Moduls viele andere Probleme.

Ich habe letzte Woche einen Test durchgeführt, bei dem RAM + SWAP voll war, und die Eingabe blieb stabil. Ich durfte auch mit nur minimaler Verzögerung zwischen aktiven Fenstern wechseln. Ich konnte keinen neuen Prozess wie 'alt' + 'print screen' aufrufen, aber ich konnte ein ordnungsgemäßes Herunterfahren aufrufen.

0

Versuchen Sie eines von zwei Dingen:

1) Ändern Sie die Swappiness-Einstellung von der Standardeinstellung von 60 auf 10 , dh: add vm.swappiness = 1 to /etc/sysctl.conf (Geben Sie im Terminal Sudo gedit /etc/sysctl.conf ein) und starten Sie das System neu. Suchen Sie hier nach swappiness, um weitere Informationen zu erhalten.

2) Wenn swappiness nicht hilft, obwohl Sie vielleicht nicht möchten, vergrößern Sie Ihre Swap-Datei auf 1,5x16G und prüfen Sie, ob dies hilft.

Halte mich auf dem Laufenden. Prost, Al

0
heynnema