On Tuesday 27 February 2001 23:36, Reinhard Foerster wrote:
On Tue, Feb 27, 2001 at 07:58:11PM +0100, Konrad Rosenbaum wrote:
Auf Mission-Critical Systemen darf es weder zu malloc- noch zu fork-OOM's kommen.
Warum? Beide fange ich als Programmierer doch ab und kann sie behandeln. Sie sind also unproblematisch.
Du als Programmierer? Tschuldige, aber ich find das lustig. ;-)
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. Signal-Handling und das Prüfen von Ressourcen ist keine triviale Angelegenheit und Fehler, die zu OOM's führen werden nur sehr schwer entdeckt. Abgesehen davon belegen korrekte Prüfungen für diese Fälle nicht unerhebliche Mengen an Speicher und Rechenzeit.
Meine Projekte sind zwar meist nur im Bereich von einigen 10kB (C-Sourcen alleine), aber ich habe diese Probleme schon oft genug gesehen. Inzwischen kann ich Dir auch sagen, dass meine freien Programme regelrecht vorbildlich dastehen im Vergleich zu kommerzieller Software (hab' schon einige Quellen bewundern dürfen) - und z.B. Datenbanken sind meist kommerziell (oder nicht mission-critical).
Spielt in der Branche keine Rolle, da die Kosten woanders liegen (Mitarbeiter, Schulungen, Wartung). Eine Solaris-Kiste kommt in etwa genauso teuer, wie ein Linux oder ein NT4 --- das Kriterium sind Kosten durch Ausfälle und die persönlichen Vorlieben des Managements.
Jo.
Das ist das Argument, warum ich nicht gegen das Fehlen eines zentralen Linux-CVS protestiere.... Linus' Zeit"budget" ist die Ultimative Grenze[tm], die jedes Feature überwinden muss.
Diese Betrachtungweise gefällt mir. Das klappt aber nur, wenn linux sich das Zeug auch anschaut. Ob er das macht?
Soweit ich seine Kommentare in der Mailliste verstanden habe: *die kritischen Teile (Scheduler, VM etc.) schaut er genauestens durch bevor er irgendeine Änderung an "seinem Baby" zuläßt *die weniger kritischen (Treiber) übernimmt er weitestgehend ungeprüft von Alan Cox und Co.
Wie schon oben erwähnt: wenn eine Ressource knapp wird kann man vom Kernel keine Wunder erwarten - er wird tun, was notwendig ist: killen.
Nein, du willst den Kern erst mit Denken anfangen lassen, wenn das Kind schon in den Brunner gefallen ist. Das ist nicht die übliche Methode mit einer knappen Ressource umzugehen.
Die Alternative wäre: das Programm muss vom Admin oder vom Programmierer nach Wichtigkeit eingestuft werden und einer stateful inspection unterzogen werden (siehe Mainframe-Welt). Dann hast Du aber das Problem, dass Du nur auf fest definierter Hardware mit fest definierten Services und wenigen Prozessen arbeiten kannst oder der Kern ein sehr kompliziertes Automaten-Modell abbilden muss.
Auf jeden Fall wird es seeeeehhhhhhr laaangsaam, wenn der Kernel das Programm überwachen muss.
Diejenigen, die für kritische Systeme zuständig sind müssen auch einplanen, dass es Extremsituationen geben kann. Ausserdem haben grosse DB's immer auch Statistiktools, die einem sagen, wann es knapp wird, dann kann man entsprechend reagieren.
Ja, ausser auf Linux. Was den Speicher angeht würden die Statitiken dort immer sehr beruhigend aussehen - falls nicht gerade das Statistikprogramm gekillt wird.
Das Problem ist ja wohl bekannt: nur weil die Straße bis zur Kurve frei ist muss es dahinter nicht genauso aussehen....
Überlegen wir uns mal ein Szenario: DDOS-Attacke auf den WebServer (nehmen wir mal an Apache, Oracle, Perl/PHP, einige andere Tools).
Linux: <- OOMs werden bei Zugriff auf den Speicher ausgelöst
-> Apache wird haufenweise neue Prozesse erzeugen, die wiederum Verbindungen behandeln oder exec aufrufen -> bis hierher nur wenige OOMs
-> die neuen Prozesse machen DB-Aufrufe und wandeln Daten in Queries und Resultsets in HTML -> einige OOM's, da neuer Speicher belegt wird -> die Seiten kommen nicht an oder die Transaktionen werden nicht abgeschlossen und daher auch nicht in die DB geschrieben (ROLLBACK)
-> die DB wird evtl. neue Prozesse für Transaktionen starten (bis dahin kein Problem), die Prozesse verbrauchen Speicher und einige Transaktionen schlagen daher fehl (ROLLBACK)
-> eventuell erwischt es die DB selbst, d.h. ab dem Zeitpunkt ist eine Arbeit mit dem System nicht mehr möglich (vom Web aus), der Stand vor dem Angriff ist eingefroren
-> Schlimmer Fall: die Skripte sind schlampig programmiert, d.h. die Daten in der DB sind inkonsistent, da logische Zusammenhänge nicht Transaktionen entsprechen und "halbe" Transaktionen gespeichert werden
-> Schlimmster Fall: die DB ist schlecht programmiert, d.h. die Datenbank ist nicht aus sich selbst wiederherstellbar (via transaction-log); Folge: das Backup der letzten Nacht muss eingespielt werden und der DB-Hersteller wird verklagt (aber den Prozess gewinnen)
Solaris: <- 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
-> die Transaktionen werden gar nicht erst begonnen
-> Schlimm: die Skripte sind schlampig und rufen andere Skripte auf, die "Subtransaktionen" durchführen, selber Effekt wie oben: "halbe" Transaktionen in der Datenbank
-> GAU: die DB ist auch schlampig, fordert neuen Speicher an (z.B. um die Prozesstabellen oder selbst bearbeitete Transaktionen zu speichern), checkt ihn nicht auf NULL, greift zu und stürzt ab ohne ein gültiges Log zu hinterlassen; der Effekt ist wieder der selbe: das Backup muss her
Mainframe (Hinweis: wird nur selten dafür benutzt): <- der Kernel überwacht die Programme und weiss was passieren wird (ich nenne das mal "Mainframe", nur die wenigsten Mainframe-OS's werden das so restriktiv handhaben)
-> im Normalbetrieb ist das System teuer und langsam
-> im Angriffsfall ist es noch langsamer aber einige wenige Anfragen kommen durch und werden korrekt bearbeitet
Aus diesem Szenario kann ich nur das ablesen: *Mainframes (nach unserer Definition) werden das Untenehmen ruinieren, da der Break-Even-Point nie erreicht wird (die User laufen weg, weil sie woanders weniger Gähnanfälle bekommen) *Solaris braucht viel Speicher für den Normalbetrieb (zu viele Programme in diesem Szenario belegen Ressourcen im Voraus statt on-demand) *Linux produziert etwas weniger-deterministische Abstürze *Beide Systeme sollten vom Netz genommen, neu gebootet und danach durchgecheckt werden
Bleibt im Grunde nur: machen wir uns mal Gedanken über Schadensminimierung: *die Skripte auf korrekte Transaktionen checken *Prüf-Utilities für den Ernstfall schreiben *eine ordentliche Firewall-Struktur aufbauen *das System von Anfang an gross genug dimensionieren *bereits an eine Aufrüstung denken (für den Fall, dass die normale Belastung überproportional wächst)
Konrad