On Tuesday 06 March 2001 19:33, Eric Schaefer wrote:
On Tue, Mar 06, 2001 at 05:54:37PM +0100, Konrad Rosenbaum wrote: Die ganze Diskussion ist schon furchtbar verrannt, deshalb fang ich noch mal von ganz vorne an: (wer mag darf schnell noch mal gähnen)
Das Ausgangsproblem ist doch einfach, daß der Speicher zu knapp ist. Bei !linux wird einfach kein Speicher mehr ausgegeben, bei linux wird der Zähler für den belegten Speicher nur dann hochgezählt, wenn ein pagefault auftritt, d.h. wenn ein Prozess auf eine Seite zugreift, die er zwar angefordert hat, auf die er aber noch nie zugegriffen hat. Daraus entsteht folgendes Problem: Prozesse fassen in der Summe mehr Speicher aus, als wirklich da ist und irgendwann gehen evtl. dem Kern die Seiten aus, weil er mehr ausgegeben hat, als verfügbar sind. Dieses Vorgehen erscheint in gewissen Situation sinnvoll. Aber: In einem sinnvollen System sollten nie auf Dauer wesentlich mehr Seiten _gebraucht_ werden, als tatsächlich physisch (!!) da sind, weil das System vor lauter Swappen nicht mehr zum arbeiten kommt. Ausnahmen sind kurzzeitige Hochlastsituationen. Sagen wir ein System hat x physische Seiten und y*x soviel Swap (in Seiten), wobei y > 2 ist (Swap ist billig). In diesem Fall ist die Gesamtzahl der verfügbaren Seiten (y+1)*x. Wenn wir für y z.B. 5 annehmen, dann haben wir mehr verfügbare Seiten, als sinnvoll ist. Wenn die Seiten nähmlich gar nicht gebraucht werden (siehe "linux-szenario" oben), dann wird der swap auch nicht angefasst, aber die Seiten können zumindest ausgegeben werden. Wenn die Seiten doch gebraucht werden sollen, dann wird eben wild geswapt. Soweit kommt es nach dem "linux-szenario" ja aber nicht (denn selbiges würde killen). Garantiert steht in jeder !linux-Dokumentation "wie dimensioniere ich meinen Server" drin, daß man mindestens 3 mal soviel Swap braucht wie physischen RAM.
Naja, mal angenommen es gibt haufenweise per mmap geladene Seiten, dann braucht er die nur zu verwerfen, weil es die ja nochmal in der originalen Datei gibt (es sei denn das dirty-Flag ist gesetzt, dann muss vorher synchronisiert werden).
Du _kannst_ (im Sinne von "darfst") gerne perfekte Programme erwarten. Es ist Deine Enttäuschung. Meine Erfahrung sagt mir etwas vollkommen anderes über Programme (ja, ich habe auch schon Bugs in ausgetesteten 100-Zeilern gefunden).
Und weil die Programmierer nicht perfekt sind, sollte der Kern die Prozesse voreinander schützen und nicht wahllos killen <PUNKT>
Moment, meinst Du "Speicherschutz"? Der sorgt dafür, dass Prozess A nicht auf den Speicher von Prozess B kommt. Das löst aber das Problem nicht: der Speicher ist voll.
Problematisch in OOM-Situationen ist: wie entscheide ich, wer der Böse ist. Aus Kernelsicht kann ein Prozess schlimm aussehen, der wichtig für's System ist. Fork-OOM-Systeme umgehen das, indem sie vorbeugend keine Prozesse starten, die schon zuviele Pages haben, auch wenn die nächste Anweisung execve("/bin/echo",...) heißt (deswegen wurde auf solchen Systemen vfork eingeführt, was aber kaum ein Programmierer nutzt). Auf solchen Systemen kann es Dir auch passieren, dass noch Megabyteweise Speicher da ist und nix mehr geht, weil das System der Meinung ist: im schlimmsten Nutzungs-Fall sind alle Pages belegt.
du musst nicht unendliche Hardware erfinden, um die Randbedingungen aus dem Weg zu schaffen ("beseitigen" war eigentlich der falsche Begriff) - es reicht die Hardware so zu dimensionieren, dass das System nicht mehr überlastet werden _kann_. Sprich: genug Rechenpower und Speicher, dass der maximale Durchsatz auf der Netzwerkkarte noch nicht die Limits der reagierenden Server erreicht.
Da hast Du recht, so macht man das auch oft, aber nicht immer funktioniert das so. Du hängst Dich zu sehr am Thema Webserver auf.
Das war nur so schön einfach. Jeder andere Server geht auch, nur ist es da meist nicht so schlimm, weil im Intranet kaum jemand mutwillig angreift - der Server muss nicht vollkommen überdimensioniert werden.
Also bliebe als Konsequenz: jemand sollte entweder selbst eine Konfiguration für die VM schreiben oder einen Kernel-Entwickler dazu überreden einen weiteren Wert für /proc/sys/vm/overcommit_memory einzuführen: -1. Das Problem daran wird sein, dass dieses Feature viele CPU-Zyklen fressen und den VM-Code komplizieren wird.
Warum nicht zur Compilezeit einstellen, das ich kein Overcommit will, dann frißt das auch keine Zyklen weiter...
...und wenn der erste Prozess "no overcommit" anfordert fängt der Kern an seine Pages zu zählen...
Kernel-Option ist besser (weil konsistenter und einfacher).
Bitte Den langen Text oben zweimal lesen, einen Moment drüber meditieren und dann erst meckern... ;-)
...mecker. ;-)