Reinhard Foerster wrote:
Hallo LUG,
[fork und Speicher]
Das ist sonst wie mit ueberbuchten Hotels: 80 Betten habe ich, 100 verkaufe ich in der Hoffnung dass 20 Leute nicht anreisen. Kommen dann doch 85 muessen 5 mit anderen Hotels vertröstet werden. Auf Linux uebertragen wuerden 5 der 85 Gaeste erschossen. Dabei nimmt man nicht die zuletzt angereisten 5, sondern waehlt sich die Opfer zufaellig aus. Während billige Hotels das so machen, wird das in edlen Hütten nicht passieren. Diese lassen lieber mal eine Nacht 10 Betten frei als zu überbuchen. Wie so eine edles Hotel mit den betten sollte Linux mit dem Speicher umgehen. Die 10 freien Betten entspechen dort dann eine paar MB swap mehr auf der Platte.
IMHO ist das doch ein Statistik-Problem. Wie du oben selbst sagst, laesst ein edles Hotel auch mal ein paar Betten frei ... Die Frage ist halt nur, wieviele freie Betten man sich leisten kann (um mal beim Hotel-Bild zu bleiben). Auch wenn der Speicher heutzutage eher billig ist, ist doch ein maximale Ausnutzung erstrebenswert.
Dazu muesste man einfach mal fuer eine sehr grosse Anzahl Prozesse feststellen, wieviel ihres Speichers nach einem fork() veraendert wird. Und dann kannst du mit der Statistik berechnen wieviel mehr als vorhandenen Speicher ein fork() vergeben darf (bei einer bestimmten, von Dir frei waehlbaren Wahrscheinlichkeit, dass das dann doch noch schiefgeht). Ich habe das mal mit ueberbuchten Fluglinien gerechnet, sollte sich aber leicht auf Hotels und Speicher anpassen lassen ...
Dahingehend ist dein fork()-Beispiel eher schlecht gewählt und unrealistisch.
Es ist *der* Hauptgrund, der zu den out_of_memory Situatioen fuehrt und diese bescheuerten kills beliebiger Prozesse nach sich zieht, die es fast nur in Linux gibt.
Hm. Ich wuerde den Prozess killen, der zuviel haben wollte ...
Bye.
Jens