Am Sonntag 06 Dezember 2009 schrieb Tilo Schwarz: > Hallo Liste, Hallo Tilo, > folgende Situation: > > Ein Server wird als Rechenknecht für speicherintensive Anwendungen > benutzt. Er hat N Gig RAM + N Gig Swap. > > Problem: > Wenn die User in Summe mehr RAM als echten Speicher allokieren, fängt > das System an zu swappen - logisch. Da die Rechenprozesse ständig auf > ihren gesamten Daten herumturnen, kommt das System aus dem Swappen > nicht mehr heraus, d.h. CPU-Last ist fast Null, Swap-IO fast 100% und > das System ist praktisch tot, auch wenn es theoretisch noch lebt. Es > ist entsprechend auch nicht mehr möglich, sich über ssh remote > einzuloggen, weil man wegen der Swapperei auch nach Stunden per ssh > keinen Login-Prompt mehr bekommt. > > Was ich gerne hätte: > - Entweder sollte gar kein Prozess swappen dürfen, oder > - Prozesse eines bestimmten Typs/Gruppe dürfen in Summe nicht mehr als > X Gig allokieren, oder > - Jemand hat noch eine bessere Idee ... > > Was mit dazu bis jetzt eingefallen ist: [...] > - 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. > - 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. 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. > - 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. 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 ;). > - 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 bessere, wenn auch vielleicht noch teuerere Wahl. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.