Re: Wie Multi-User-System vor Dauer-Swapping bewahren?
On Sun, 06 Dec 2009 20:52:41 +0100, Martin Steigerwald
<Martin@lichtvoll.de> wrote:
Am Sonntag 06 Dezember 2009 schrieb Tilo Schwarz:
Hallo Liste,
Hallo Tilo,
[...]
- Den Swap komplett abschalten zusammen mit dem OOM Killer und den
richtigen Overcommit-Settings sollte das Problem eigentlich lösen
(stimmt das?), nur würde ich lieber Swap erlauben, bloß nicht für die
Prozesse, die ständig random access mäßig ihren ganzen allokierten
Speicher durchforsten (weil sie dann dauernd viele Swap Page-Faults
provozieren).
Das sollte funktionieren, kann jedoch als Nebenwirkung den Effekt haben,
dass weniger Prozesse laufen können, als die Maschine eigentlich laufen
lassen könnte. Insbesondere, wenn Prozesse beteiligt sind, die wie blöde
Adressraum belegen, ohne ihn auch zu nutzen.
Genau (aber immer noch besser, als daß die Kiste quasi einfriert ;-).
- Vielleicht kann man das Problem auch mit cgroups lösen?
Mit dem Memory Resource Controller via cgroups geht sowas prinzipiell -
seit einiger recht neuen Kernel-Version glaub sogar differenziert nach
Hauptspeicher und Swap. Jedoch bis zum letzten Mal, als ich nachschaute,
war die ausgelöste Aktion beim Überschreiten eines Limits ziemlich
drastisch: Der Kernel beendete den Prozess einfach hart.
Das wäre zwar nicht schön, aber jetzt werden irgendwann alle Prozesse hart
gestoppt - wenn einer den Resetknopf drückt ...
Ich weiß auch nicht, ob man einfach nur Swap für einen Prozess
ausschalten
kannst. Aber da kannst Du ja in der Kernel-Dokumentation nachschauen. Da
gibs eine Text-Datei, die das Teil beschreibt.
Interessante Idee, werde ich nachgucken.
- Wenn der Scheduler die Rechenprozesse nicht alle 100ms sondern z.B.
einmal pro Stunde rechnen ließe, würden sich die Prozesse nicht immer
gegenseitig den Speicher _gleichzeitig_ streitig machen. Kann man so
etwas realisieren?
Du könntest CFS Group Scheduling verwenden und die Prozesse in mehrere
Gruppen aufteilen. Dann machst Du ein Skript, dass einer Gruppe nach der
anderen maximale Rechenzeit gibt, während die anderen sehr wenig
Rechenzeit bekommen. Obs denn Aufwand allerdings wert ist?
Zudem geht glaub nur sehr wenig Rechenzeit, nicht gar keine Rechenzeit.
Weiß ich aus dem Kopf auch nicht mehr, muß ich noch mal nachsehen.
Einfacher ginge es vielleicht mit SIGSTOP und SIGCONT. Und das würde den
Prozess halt wirklich stoppen. Zumindest mit meinem KMail in Kontact
klappt das via:
martin@shambhala:~> kill -STOP $(pidof kontact)
martin@shambhala:~> kill -CONT $(pidof kontact)
einwandfrei ;).
Noch eine gute Idee (vor allem simpel), werde ich mir auch mal ansehen.
- Gibt es vielleicht ein Batch-Management-System im Archiv, das
konfigurierbar nur soviele Prozesse startet, solange noch genug
Speicher frei ist (man müßte dann den MAX-Speicher für einen Prozeß
angeben können).
- Ich hab im Paket-Archiv nach queue, batch, accounting etc. gesucht,
aber die Ergebnisse passten nicht so recht.
Keine Ahnung. Wenn Du was findest, lass es uns wissen.
Ich tendiere ansonsten zur bereits ausgeschriebenen Empfehlung: Mehr RAM
oder weniger Prozesse.
Eine Möglichkeit, falls es am Geld nicht mangelt, wäre evtl. auch ein
Swap-RAID 0 auf mehreren SSD's. Allerdings wäre dann ein Server mit mehr
RAM wohl immer noch die besse
Wie gesagt, sind schon 196 Gig drin.
Allem im Thread danke für die Antworten!
Viele Grüße,
Tilo
Reply to: