Ich häng mich auch mal in die Diskussion rein, nachdem der Thread schon meinen Bildschirm sprengt (seitlich, mutt user wissen wahrscheinlich was ich meine :)).
On Tue, Mar 06, 2001 at 08:58:24PM +0100, Konrad Rosenbaum wrote:
On Tuesday 06 March 2001 19:33, Eric Schaefer 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)
[snip - Geistesblitz von Eric]
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).
Hat das irgendetwas mit Erics Argumentation zu tun? klär mich mal bitte auf. Im Übrigen bist du glaub ich etwas zu verrannt in deine Position. Und was hast du gegen Erics Idee? Wäre doch die ideale Lösung, wie er schon sagt Festplattenspeicher ist spottbillig, und Swap hast du dann auch mehr als genug.
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.
Deine Argumentation hat nur einen furchtbren Haken. Wenn ich ein Programm schreibe, z.B. eine Datenbank, dann hätte ich gerne etwas Einfluß auf dieses Programm. Wenn ich auf ein malloc() keinen Speicher mehr kriege, weil das System ausgelastet ist, kann ich darauf reagieren, indem ich z.B. in einer Panikaktion alle Transaktionen durchführe und dabei einen Notspeicher benutze, den ich mir als cleverer Programmierer vorher alloziiert habe (da ich in Datenbankprogrammierung nicht übermäßig bewandert bin, gehe ich mal davon aus, daß diese Reaktion nicht ideal ist, aber es soll schließlich ein Beispiel sein). Wenn der Kernel mein böses, böses Programm natürlich abschießt, stehe ich dem etwas hilflos gegenüber.
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.
Dafür reservierst du den Swap. Gehst du eigentlich in diesem Thread überhaupt nicht auf die Argumentation Anderer mehr ein?
Beispiel: Du kaufst dir eine 10 Gig SCSI-Festplatte (ein SCSI-Anschluß ist im Gegensatz zu IDE bei teureren Systemen meines Wissens meistens vorhanden). Kosten: So um die 1000,- (großzügig kalkuliet). Für deinen Webserver oder was auch immer hast du allerdings normalerweise soviel Geld ausgegeben, daß dich das bißchen nicht mehr juckt. Dafür hast du aber jetzt 10 Gigabyte Swap zusätzlich zum Einbinden. Wenn dein Server z.B. normalerweise mit 1 Gigabyte RAM läuft, sollte das erstmal für eine Weile reichen. Wesentlich billiger wirds natürlich mit IDE.
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.
Und was ist, wenn bei einem Datenbankserver ein Skript plötzlich durchknallt und einen gigantischen select macht? Speicher alle => schade eigentlich, jetzt darfst du deine Datenbank neu starten. Das war glaub ich auch der Auslöser bei der ersten Diskussion zu diesem thema hier gewesen.
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? Der Kernel kann doch einfach eine Liste des herausgegebenen Speichers führen (was er ja schon macht), und einfach einen Wert hochzählen, wenn Speicher alloziiert wurde und runterzählen, wenn er freigegeben wird. Wenn der vorhandene Speicher überschritten wird, gibt er halt keinen Speicher mehr raus. Sooo kompliziert ist das ja meines Wissens nicht gerade.
Zu den CPU-Zyklen: Soweit ich mir vorstellen kann, gibt es zwei Möglichkeiten, den freien Speicher zu belegen/freizumachen, nämlich forken (bzw. einen (Kind-)Prozess beenden) und Speicheralloziierung/-freigabe. Beide Sachen sind auch ohne dieses zusätzliche Feature schon sehr teuer. Das ertse wird man versuchen zu reduzieren, indem man den Kindsprozeß solange wie möglich leben läßt anstatt ihn jedesmal neu zu erzeugen (siehe z.B. FastCGI); den zweiten Fall vermeidet man, indem man einen großen Speicherblock reserviert und dann eine Speicherverwaltung im Userspace benutzt (wird meines Wissens bei rechenintensiven Sachen auch so gemacht). Wenn ein Programm das nicht versucht, ist es ab einer bestimmten Größe blöd. Komm mir nicht mit Apache, soweit ich in der iX gelesen habe, soll die Version 2.0 dann auch Alternativen zum forken anbieten.
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).
Ich glaub, er hat eine Kerneloption gemeint.
Bitte Den langen Text oben zweimal lesen, einen Moment drüber meditieren und dann erst meckern... ;-)
...mecker. ;-)
zurückmecker :)
cu, Ulf