On Friday 02 March 2001 01:30, Reinhard Foerster wrote:
On Thu, Mar 01, 2001 at 07:12:23PM +0100, Konrad Rosenbaum wrote:
Im Ernst: wenn man ein Projekt mit C-Quellen im Megabyte-Bereich (nur Quellen, keine Doku, keine Bilder, etc.) hat wird man nicht mehr jedes einzelne malloc und auch nicht jedes fork korrekt prüfen können.
Man kann. Oft fehlt die Zeit und/oder Geld, um so zu programmieren. Dafür kann ja aber das System nichts. Wer sich etwas Mühe gibt hat kein Problem damit, daß mal ein malloc oder fork in die Hose geht.
Zeit und Konsequenz, Zitat von mir: "hmm, das lass ich erst mal, kommt sowieso vor dem Release wieder raus" - zu oft stellt sich dann heraus, dass die enstcheidende Stelle doch drin bliebt (meist stark modifiziert, aber malloc's machen kaum Probleme und bleiben daher unberührt stehen).
Wenn Du die Theorie des Software-Engineering meinst wird Dir jeder Programmierer zustimmen, dass soetwas vermeidbar ist und auf keinen Fall guten Stil darstellt. 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%).
kann ich Dir auch sagen, dass meine freien Programme regelrecht vorbildlich dastehen im Vergleich zu kommerzieller Software (hab' schon einige Quellen
Siehste, du schreibst normalerweise auch nicht solchen Schrott.
Ich muss Dich leider enttäuschen. Um präziser zu werden: in wichtigen Projekten (Server) sind etwa 40% der mallocs und 90% der forks abgecheckt. In zusammengehackten Mini-Projekten 5% respektive 50%.
In den kommerziellen Quellen, die ich bisher bewundern durfte war grundsätzlich letzteres der Fall. Zeitdruck.
zu NichtLinux:
<- OOMs werden bei fork ausgelößt, wenn nicht genug "potentiell notwendiger" Speicher da ist
-> Das System friert ein, da als erstes die DB keine neuen Prozesse erzeugen kann, danach kommen die CGI's, dann Apache
Wieso friert das System hier ein? Die DB probiert halt weiter ihre forks und zwischendurch kommen die anderen Prozesse auch alle mal dran. Die DB schreibt heftig in ein Logfile, dass ihr der Saft ausgeht und der Admin ihr doch bitte in Zukunft etwas mehr Platz verschaffen möchte. Der Admin kann dann z.B. die Maximalzahl der Apachen begrenzen damit die DB mehr Luft hat oder einen Speicherriegel nachrüsten.
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.
(Der Linuxadmin kann nur im sylog suchen, ob er irgendwelche Hinweise findet. Die DB selbst hat ja keine Chance die Speicherknappheit zu bemerken und entsprechene Warnungen ins logfile zu schreiben. Die DB ist für Linux dann einfach böse und muss sterben.)
Da gibt es eine witzige Technik, die sowas abfängt: AFAIK haben größere DB's einen eigenen Log-Prozess bzw. einen Notfall-handler für SIGSEGV und SIGTERM - die DB wird also versuchen sich sauber zu beenden und auf jeden Fall einen Log-Eintrag hinterlassen ("xDB server killed by SIGSEGV: shutdown").
Naja, ich baue jedenfalls meistens sowas in meine grossen Server ein.
Nebenbei bemerkt: Wenn es soweit kommt, macht die Kiste whrscheinlich sowieso schon nix mehr ausser trashing. Der Admin dürfte also sehr schnell davon Wind bekommen, da die Leistung der Kiste arg sinken wird. Und die Kiste macht ja schliesslich was gaaaaanz wichtiges :)
Hmm, der Quake-Server verabschiedet sich schließlich auch! ;-)
Soweit ich hohe Netzlast bisher beobachten konnte sollten Angriffe genügend Auswirkungen auf das gesamte System haben, um den Admin zumindest in Alarmzustand zu versetzen.
Konrad