On Saturday 03 March 2001 00:44, Reinhard Foerster wrote:
On Fri, Mar 02, 2001 at 06:02:09PM +0100, Konrad Rosenbaum wrote:
Wenn Du die Theorie des Software-Engineering meinst wird Dir jeder Programmierer zustimmen, dass soetwas vermeidbar ist und auf keinen Fall guten Stil darstellt.
Die "Theorie des Software-Engineering" ist mir relativ schnuppe. Soll doch jeder wuseln wie er will (solange es nicht mein Geld kostet)
Witzige Einstellung - hat schon sehr interessante Effekte gezeigt ;-)
Mit Theorie waren hier Deine eigenen Forderungen, wie "malloc muss auf NULL geprüft werden" (malloc OOM), SIGSEGV muss korrekt behandelt werden (malloc OOM) oder "fork auf -1 testen" (fork OOM) gemeint.
Nach ein paar Glas Bier (oder in hitzigen Diskussionen, wie man sieht) wird er aber zugeben, dass die Konzentrationsfähigkeit eines durchschnittlichen Programmierers nur für etwa 30% der mallocs und 60% der forks reicht (gute, wie Linus oder Alan, schaffen es bei guter Laune auf 50% und 90%).
Mag sein. Dagegen kann man wahrscheinlich wenig tun. Jeder bekommt, was er fabriziert.
Oder was die Firma auf der anderen Seite der Verpackung auf die CD's gepresst hat.
Mein Punkt ist der: Das OS muss so gebaut sein, dass ein *ordentliches Programm* auch ordentlich ablaufen kann. Ein OS, was hier unnötige Kompromisse eingeht, ist Schrott.
Ein Kompromissloses OS gibt es nicht. Nur das Ziel des Kompromisses variiert. In unserem Beispiel: Linux -> die Ressourcen ideal ausnutzen Solaris -> dem Programm keinesfalls mehr versprechen als man halten kann ..."your milage may vary"...
Hast Du mal lineare Optimierung oder ähnlichen Blödsinn gehabt? Die wichtige Lektion war nicht, dass man 3 Anläufe für Mathe-Prüfungen braucht oder jemals den Kram praktisch einsetzt, sondern: Komplexe Systemen bestehen aus wenigen Gegebenheiten (digitales Rechensystem), einigen Zielen (wenige Crashes, Geschwindigkeit, optimale Ressourcen-nutzung, ...) und haufenweise Randbedingungen (Hardware, Fähigkeiten und Zeit der Programmierer, Fehlerwahrscheinlichkeit, ...), die einen zu Kompromissen zwingen. Leider. Ich würde gerne mal mit einer idealen Turing-Maschine arbeiten...
Oder andersrum ausgedrückt: Wenn das Nutzerprogramm Mist macht (z.B. stirbt) sollte es mit nahezu 100%er Sicherheit am Nutzerprogramm liegen und nicht am OS.
Das erreichst Du teilweise mit fork-OOMs. Problem dabei ist: bei gegebenem RAM macht das System eher schlapp, da die OOM-Algorithmen schneller triggern. Gerade Server, die Daten ausliefern, haben die Angewohnheit Megabyte-weise Speicher zu allozieren, den sie erst später nutzen. Ausserdem starten sie haufenweise Kindprozesse, die nur einen Teil der Ressourcen nutzen. Bei einem overcommit-mem-System (malloc-OOM-System) wird das sehr lange gut gehen, da nur ein Teil der allozierten Ressourcen wirklich physisch vorhanden sein muss. Ein fork-OOM-System wird Alarm schlagen, wenn es auch nur den Verdacht eines overcommit hat: also wesentlich eher als ein overcommit-System.
Mit hoher Wahrscheinlichkeit ist ein fork-OOM-System schneller zum (scheinbaren) Stillstand zu bringen als ein overcommit-System, das dann aber spektakulärer crasht. Was für mich (mit meinen begrenzten finanziellen Ressourcen) ein verdammt guter Kompromiss ist.
Der Admin wird es problemlos bedienen können (klarer Vorteil gegenüber Linux), aber es existieren immer genug offene Apache/Skript/DB-Prozesse, so dass keine weiteren Web-Nutzer reingelassen werden - aus Sicht der Nutzer ist es eingefroren.
Diese Fehlersituation (bei überlast werden keine neuen Nutzer/Jobs werden mehr angenommen) ist deutlich günstiger, als weiterhin Jobs anzunehmen, die aber auf halbem Weg zum Ziel abgebrochen werden müssen.
Der Effekt für den User ist der selbe: keine Antwort auf Fragen.
Bitte versteh' mich jetzt nicht falsch: rein technisch ist ein fork-OOM-System auf einem kritischen System vorzuziehen, da die Wahrscheinlichkeit eines katastrophalen DB-crashs und halbfertigen Transaktionen geringer ist (ich schätze ca. 20-25%). Rein praktisch habe ich bisher Solaris immer als anfälliger als Linux erlebt (mein subjektiver Eindruck, ich kann ihn nicht mit Daten unterlegen).
Konrad