Können Sie eine Mindestgröße für den Linux-Festplattenpuffer festlegen?

Ich habe eine ziemlich alte Linux-Maschine mit 2 GB RAM, kein Swap, und sie funktioniert sehr gut, da das System jeden nicht verwendeten Speicherplatz für das Caching mit großer Wirkung verwendet.

Wenn ich jedoch kurz davor bin, den Speicher zu belasten (z. B.> 1950 MB zugewiesen), verlangsamt sich das Crawlen. Ich vermute, das liegt daran, dass keine Festplattenpuffer mehr vorhanden sind. Ich weiß, dass der OOM-Killer bald in Kraft treten würde, aber er kommt normalerweise nicht dort an - er wird so langsam, dass das Laden auf 30-40 schießt, kein Prozess Fortschritte macht (also nicht mehr Speicher zuweist), und Ich muss es neu starten.

Wenn ich versuche, nur einen Prozess abzubrechen, damit der Computer reagiert, z. B. indem ich zur Konsole gehe (über Alt-F1, Anmelden und nur einen "Killall Badprocess"), funktioniert dies normalerweise, außer dass ich warten muss ~ 10 Minuten zwischen Benutzer / Passwort und dem Erhalten einer Eingabeaufforderung - alles während der Festplattenaktivität.

Auch hier gibt es keinen Tausch, es wird also nicht getauscht - es wird nur verprügelt, weil keine Puffer mehr vorhanden sind.

Ich hätte ungefähr 100 MB ausschließlich für Festplattenpuffer, was den OOM-Killer früher auslösen würde (immerhin weniger Speicher für Programme), aber andererseits die Maschine jederzeit reaktionsfähig machen würde.

Gibt es eine Möglichkeit, das zu tun? Ich konnte keinen / proc / kernel- oder / sys / vm-Eintrag finden, der so etwas macht.

linux cache

— HopelessN00b
quelle

Ich habe auch das gleiche Problem, und leider hilft keine der Antworten auf dieses Datum in dieser Angelegenheit.

— Krišjānis Nesenbergs

Antworten:

Schauen Sie sich / proc / sys / vm / min_free_kbytes an . Es ist die Grenze der freien KB, die den Oom-Killer auslöst. Es wäre auch gut, in den Protokollen nach dem Schlüsselwort oom- kill zu suchen, um zu wissen, was getötet wird {wahrscheinlich willst du ssh nicht töten , du solltest es besser wiederholen }

— Nikolaidis Fotis
quelle

Vielen Dank. Ich habe es vergrößert, aber das scheint das Problem nicht zu lösen - sobald der physische Speicher fast erschöpft war, war kein Pufferspeicher mehr vorhanden, und die Maschine wurde langsamer.

Auch hier keine Hilfe, das System reagiert immer noch nicht.

— Tronic

Das hat mir tatsächlich geholfen, ich habe auch 2 GB RAM und ich habe dies auf fast 500 MB eingestellt

— vorerst

Ich teste diese Einstellung derzeit auf meiner Workstation. Ich habe 8 GB RAM und die meiste Zeit verwende ich nicht mehr als 5 ... außer wenn ich aus irgendeinem Grund eine Windows-VM starten muss, die ungefähr 4 GB RAM benötigt. Ich habe ZRAM auf meinem Host-Betriebssystem eingerichtet, da meine Festplatte mechanisch ist, aber es wird immer noch ziemlich langsam, da der RAM fast voll ist, gerade wegen des geringen RAM-Speicherplatzes für Dateisystempuffer und -caches. Ich habe gerade vm.min_free_kbytes verwendet, um sicherzustellen, dass immer mindestens 2 GB frei sind und der Rest auf komprimiertes RAM ausgelagert wird (was viel schneller als normaler Swap-Speicher ist). Wird später mit Ergebnissen posten.

— RAKK

Das Warten auf den Oom-Killer, um Speicher freizugeben, ist ein bisschen so, als würde man darauf warten, dass der Motor an Ihrem Auto stoppt, um Ihnen mitzuteilen, wann es Zeit ist, Ihren Benzintank aufzufüllen. Der Oom-Killer ist ein hartnäckiges Werkzeug der letzten Instanz und der Verzweiflung nach einer ressourcenarmen Maschine. Das nächste Programm, das es berührt, wird beendet, ohne zu berücksichtigen, wie sich dies auf Ihre Anwendung, Erreichbarkeit, Zuverlässigkeit usw. auswirkt. Wenn der Oom-Killer aufgerufen wird, schnappt Ihr Server nach Luft und befindet sich in einem kritischen Zustand.

Stattdessen ist es viel besser, wenn Sie Ihre Speichernutzung in Ihrer Anwendungsumgebung aktiv verwalten. Sie können / proc / meminfo auf Probleme überwachen und geeignete Maßnahmen ergreifen und Ihre Arbeitslast drosseln, bevor eine ernsthafte Situation hässlich wird.

— tylerl
quelle

Die Situation, die ich entdeckt habe, ist genau der Zeitpunkt, zu dem mein Server nach Luft schnappt und sich in einem kritischen Zustand befindet. Es dauert weniger als 20 Sekunden, bis ein voll ansprechender Computer auf Strg-Alt-F1 reagiert (von X zur Konsole wechseln). Ein Login ist nicht möglich, da das Zeitlimit nach 1 Minute abgelaufen ist, ohne dass Sie nach einem Passwort gefragt haben. Dies ist eine Maschine, auf der viele Prozesse ausgeführt werden. Jeder ist unabhängig NICHT das Problem. Dies ist ebenfalls ein Speicherproblem - die CPU ist in Ordnung, und die Festplatte ist in Ordnung, solange noch etwa 50 MB Festplattenpuffer vorhanden sind.

Was ist, wenn Sie ulimit verwenden und eine Anwendung einen Schwellenwert überschreitet, um eine Aktion auszuführen?

— Nikolaidis Fotis

Das Problem ist die Summe aller Anwendungen; Es laufen ungefähr 20 mit jeweils 20 bis 100 MB. Es funktioniert gut für Wochen, sogar Monate, aber wenn alle ~ 100 MB gleichzeitig zugewiesen haben möchten, stürzt alles ab und brennt; Ich möchte lieber, dass oom_killer einen von ihnen tötet, als dass ich den Computer neu starten muss. Wie auch immer, ich habe Swap vorerst aktiviert - die meisten Apps nutzen nicht immer ihren gesamten Speicher, sodass der Computer auch dann stabil bleibt, wenn er bis zum Ende des physischen Speichers belastet ist. Ich hätte jedoch lieber überhaupt keinen Tausch für diese Maschine, wenn ich kann.

Löst nicht das eigentliche Problem, das darin besteht, dass nicht die richtigen Speicherbeschränkungsgrenzen festgelegt werden (ulimits sind nicht sehr nützlich), Anwendungen, die leicht mit Speicherzuweisungen in Konflikt geraten, der OOM-Killer nicht früh genug ausgelöst wird und der massive Papierkorb und die Unempfindlichkeit verursacht durch all das. Ich habe gerade 30 Minuten der Zeit meines Arbeitgebers verschwendet, weil die Entwicklungsmaschine die Festplatte beim Kompilieren meines Codes eine halbe Stunde lang in den Papierkorb geworfen hat, anstatt einfach die Chromium-Prozesse zu beenden, die zum Beenden (oder zum Kompilieren selbst) in weniger als einer Sekunde erforderlich waren damit fertig sein.

— Tronic

Wenn Sie oom_adjrichtig eingestellt haben, kann Ihr Desktop-System ein bisschen wie Android funktionieren, wo das System praktisch immer gegen OOM Killer läuft (technisch gesehen gibt es einen "Low Memory Killer" und es ist über eingestellt /sys/module/lowmemorykiller). Die Logik besteht darin, unkritische Hintergrundprozesse kontinuierlich als potenzielle Opfer für OOM-Killer zu markieren, nach getöteten Prozessen zu suchen und die erforderlichen getöteten Programme langsam neu zu starten, um eine Überlastung des Systems zu vermeiden. Stellen Sie einfach sicher, dass der Prozess, bei dem andere Prozesse immer wieder neu gestartet werden, außerhalb der Grenzen von OOM Killer liegt.

— Mikko Rantalainen