On Tue, Mar 06, 2001 at 05:54:37PM +0100, Konrad Rosenbaum wrote: Abend!
langsam entwickelt sich das wieder zu einem unserer typischen Kommunikationsprobleme.... ;-)
Ja. Ich versuche allerdings schoh in jedem Posting, alle off topic Dinge zu eliminieren.
[bitte komplett lesen vor dem Antworten]
habe ich
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.
Du brauchst nicht mehr Speicher als jetzt. Ich will nochmal kurz zusammenfassen warum: Soviele Seiten, wie innerhalb von kurzer Zeit (sagen wir 10 Sekunden) wirklich genutzt werden, solltest du physisches RAM haben. Anderenfalls gibts nur thrashing. Um ein Zahlenbeispiel zu machen, sage ich jetzt mal, daß das 100MB betrifft.
Bis hierher OK?
Betrachten wir nun den worst case: Die obigen 100 MB gehören alle zu einem Prozess und dieser muss forken. (entweder das Kind will nur HelloWorld ausführen oder aber es will die 100 MB auch nutzen, wir wissen es nicht)
Bis hierher OK?
NichtLinux: um nicht wie Linux zu bescheissen, benötigen wir im Augenblick des forks noch 100 MB mehr für die Kopie des 1. Prozesses. Deshalb rechnet das System beim fork: freierSpeicher=freierSpeicher-100MB falls die 100 MB im swap noch frei sind und erlaubt den fork. (Die Speicherseiten werden natürlich nicht wirklich kopiert). Rechenaufwand quasi 0 Nutzt das Kind seinen Speicher wirklich, gibts pagefault wegden der read-only Seiten und es werden entsprechend Seiten gemappt.
Um ein solches System zu realisieren benötigen wir also (worst case): * soviel RAM, dass die in einer kurzer Zeit aktiven Prozesse alle Platz haben * soviel Swap, dass eine grosser Prozess nochmal darin Platz hat + noch ein bisschen für die vielen schlafenden Prozesse des Systems (getty, sendmail, ...)
Bis hierher OK?
Linux: egal wieviel Platz wir noch haben, der fork wird erlaubt. Vom freien Speicher wird nix abgezogen. Rechenaufwand = 0 Nutz das Kind die Seiten, gibts wie im obigen System Pagefaults und Seiten werden gemappt (falls welche da sind, das wissen wir ja nicht, das wir sie nich reserviert haben wie im obigen System) Bei jeder nei gemappten Seiten wird jetz freierSpeicher=freierSpeicher-eine Seite berechnet. Rechenaufwand quasi null (aber eine Rechnung pro Seite, statt wie oben insgesamt nur eine. Diese Berechnungen spielen aber absolut keine Rolle. Ich nenne sie nur, weil du unten was von "CPU-Zyklen fressen" schreibst und das quatsch ist)
Um ein solches System zu realisieren benötigen wir also (worst case): * soviel RAM, dass die in einer kurzer Zeit aktiven Prozesse alle Platz haben * soviel Swap, dass eine grosser Prozess nochmal darin Platz hat + noch ein bisschen für die vielen schlafenden Prozesse des Systems (getty, sendmail, ...) (wer jetzt den Unterschied zu oben sucht, sucht vergeblich - es gibt keinen)
Soweit OK?
Jetz gehen wir mal vom worst case weg und nehmen an, das der 100MB Prozess nur forkt um ein winziges Progrämmchen zu starten, die 100 MB also selber nicht nutzt. Die Veränderungen gegenüber dem worst case oben sind:
NichtLinux: * keine, ich brauche genausoviel RAM und swap wie im worst case
Linux * keine Änderung beim benötigsten RAM * 100 MB weniger swap werden benötigt
Und genau das wollte ich zeigen. * Ein NichtLinux benötigt die gleiche Menge RAM wie das Linux. * Ein NichtLinux benötigt soviel swap wie Linux im worst case.
Ergebnisse: * Du sparst mit Linux keinen Speicherriegel ein * Wenn du das Linuxsystems ordenlich dimensioniert (d.h. worst case ist als mögliches Szenario erlaubt), benötigst du auch die gleiche Menge swap wie mit dem NichtLinux.
Hinweis: Da der Feld-, Wald- und WiesenPC üblicherweise für die an ihn gestellten Aufgaben völlig überdimensioniert ist, kommst du selten mit deiner Linuxkiste in die worst case Situation. Deshalb haben viele Leute wenig swap mit Linux und es funzt trotzdem. Bewegst du dich Richtung worst case und hast den nötigen swap nicht, werden Prozesse gekillt.
Was lernen wir daraus: Die Linuxspeicherverwaltung bringt mir die Einspaarung von ein paar MB Plattenplatz und kostet mich dafür die Gewissheit, dass meine Prozesse am Leben bleiben dürfen. Die eingesparte Menge Plattenplatz bewegt sich im Bereich von 1-2 x Hauptspeichergröße, also z.B. 2*256 MB = 512 MB und das sind weniger als 10 Deutsche Mark = ca. 2 Bier
Nein, da hab' ich mich etwas falsch ausgedrückt.
Jo, das sehe ich auch so :)
Mathematisch will ich dafür sorgen, dass das Optimum von der einzigen als zuverlässig einstufbaren Komponente bestimmt wird: der Netzwerkkarte (zuverlässig in dem Sinne: wenn sie ausfällt ist das originale Optimierungsproblem eh' uninteressant).
Was interessiert die netzwerkkarte beim design der Speicherverwaltung? Was mache ich, wenn mein Rechner keine Netzwerkkarte hat? Mal wieder off topic. Apropos "zuverlässig einstufbaren Komponente": wenn ich 128 MB RAM im Rechner habe, bin ich mir 100%ig sicher, dass ich 128 MB RAM im Rechner habe. Das ist gaaaaanz zuverlässig und eine gute Basis, um damit rumzurechnen.
Also bliebe als Konsequenz: jemand sollte entweder selbst eine Konfiguration für die VM schreiben
Naja, wer kann das schon. Gescheite fertige Standardalgos benötigt man.
oder einen Kernel-Entwickler dazu überreden einen weiteren Wert für /proc/sys/vm/overcommit_memory einzuführen: -1. Das Problem
gute idee
daran wird sein, dass dieses Feature viele CPU-Zyklen fressen und den VM-Code komplizieren wird.
Nein. Ich habe oben die Unterschiede aufgezeigt. CPU-Zyklen sind kein Thema. FreeBSD ist z.B. keinesfalls langsamer was den Speicher angeht.
Ich glaube das Problem löst sich anders: Da jetzt mehr und mehr Firmen Linux in <buzzword mode> enterprise critical environments </...> einsetzen wollen, werden sie oft genug damit auf die Nase fallen. Wetten, dass man dann den Beschiss in der Speicherverwaltung abstellt oder abstellbar macht.
Reinhard