On Tue, Mar 06, 2001 at 05:54:37PM +0100, Konrad Rosenbaum wrote:
langsam entwickelt sich das wieder zu einem unserer typischen Kommunikationsprobleme.... ;-)
Genau.
Mein Problem: _Deine_ 99%-Lösung ist eine 40%-Lösung für _mich_ (privat), da ich nicht genug Geld für Speicherriegel für den _Normalfall_ eines fork-OOM-Systems habe (und privat gehe ich nur vom Normalfall aus, da es unkritisch ist, ob mein Privatrechner 10Minuten oder 3 Tage ausfällt). Ein malloc-OOM-System hat den Vorteil, dass es den Speicher effizienter ausnutzt.
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.
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>
Würde man beim Design des Kernels nicht darauf achten, dass es eine Menge Programmierer gibt, die einfach nur Mist bauen, dann würde das System sehr wacklig dastehen. Das wäre ungefähr so, als würde ein Autofahrer davon ausgehen, dass sich alle anderen korrekt verhalten....
Hä? Der Kern geht davon aus das Prozesse Mist bauen, deshalb sollte es sie voreinander und nicht jeweils vor sich selbst schützen.
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.
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...
Bitte Den langen Text oben zweimal lesen, einen Moment drüber meditieren und dann erst meckern... ;-)
Gruß, Eric