Hallo,
langsam entwickelt sich das wieder zu einem unserer typischen Kommunikationsprobleme.... ;-)
[bitte komplett lesen vor dem Antworten]
On Monday 05 March 2001 18:33, Reinhard Foerster wrote:
On Mon, Mar 05, 2001 at 05:42:55PM +0100, Konrad Rosenbaum wrote:
Wir scheinen hier zwei sehr gegensätzliche Herangehensweise zu haben (wen wunderts): RF: es ist möglich ein korrektes System zu schaffen, dass theoretisch nicht crashen kann
Habe ich nie gesagt. Insbesondere habe ich auch schon eher erkärt, warum das auf Unix-basis unmöglich ist. Um einem solchen System aber *recht nah* zu kommen, sollte man nicht gleich bei jedem Problem eine 50%-Lösung akzeptieren und sie als tollen Kompromiss verkaufen, wenn auch problemlos eine 99%-Lösung möglich ist. (Vor allem dann nicht, wenn die 99%-Lösung schon seit -zig Jahren im Einsatz und allgemein bekannt ist.)
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.
KR: Programmierer sind alles andere als perfekt, also spielen wir hier mit Wahrscheinlichkeiten, die auf unterschiedlichen Wegen verändert werden können.
Es gibt einfach Stellen, an denen man ein Wahrscheinlichkeit von 1 erwarten kann. Nicht überall ist es nötig, Abstiche zu machen. Wiederum frage ich mich aber, was dein Posting mit Speicherverwaltung zu tun hat. Ich würde eine Speicherverwaltung völlig unabhängig davon konstuieren, ob der zukünftige Programmierer nur Mist programmiert oder nicht. Deshalb halte ich deine Ausführungen zur durchschnittlichen Qualitaet von Kode für off topic.
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).
Nach meinen Programmiererfahrungen kommt ein besseres System heraus, wenn man mit mistigem Code rechnet. Einfach zu sagen "Systeme können theoretisch perfekt sein" schafft mehr Probleme als es löst (momentan kämpfe ich z.B. mit einem Sybase-Programm, das annimmt seine Clients wären perfekt).
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....
Eben: mein Ansatz ist es die Randbedingungen (Hardwarebeschränkungen) zu beseitigen. Deiner ist es scheinbar ein Optimum auf den Randbedingungen zu finden.
Meinen Ansatz hast du richtig erkannt. So optimiert man nun mal. Dein Ansatz der Beseitigung von Hardwarebeschränkungen ist doch absolut unrealisierbar. Mir sind bisher jedenfalls weder der unendlich grosse Speicher, die unendliche Rechenkapazität noch die unendlich grosse Festplatte über den Weg gelaufen. Wie willst du also die Hardwarebeschränkungen beseitigen? (Falls du eine allgemeine Lösung zur Beseitigung von Randbedingungen in Optimierungsproblemen gefunden hast, schreib mir bitte ne private Mail. Die am häufigsten zuschlagende Randbedingung bei meinen privaten Optimierungsproblemen ist zu knappes Geld. Mit deiner Hilfe werde ich diese Randbedingung dann wohl einfach beseitigen können. *jubel*)
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.
Mathematisch: du willt ein OP mit NBs dadurch lösen, dass du die NBs beseitigst. Das ist völliger Humbug.
Nein, da hab' ich mich etwas falsch ausgedrückt. 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).
Deine Geldprobleme lassen sich mit diesem Ansatz leider nicht lösen sondern nur verschlimmern (ich habe die Variable "Geld" nicht einbezogen).
Und hier kommen wir zu Deinem Ansatz zurück: die meisten Chefs machen wahrscheinlich nicht genug Geld locker, um meinen Ansatz zu unterstützen.
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.
Konrad