Ausfall 06.06.

[ThomasB.]

Thomas? Kannst Du diesen Teil auch noch übersetzen?

Gerne: Elrond weiß nix, aber das macht nix, solange das Programm alles weiß.

 

Und das Forenproblem am Dienstag entstand dadurch, daß das Programm vorübergehend auch nichts wußte, sondern nur dachte, es wüßte etwas.

[Elrond]

Genau, Programme haben einfach nicht genug Seele, Kommunikationskompetenz und emotionale Intelligenz, um die Sache in Betrieb zu halten. Waere der Webserver ein Angestellter eines Unternehmens, waere er als stur und unflexibel verschrien, der im Falle eines Feuers solange Kollegen in selbiges wirft, bis das Feuer aus ist.

[Lissie]

Dann wäre es also eine Marktlücke, Programme mit sog. soft skills zu entwickeln?

[Elrond]

Wer kennt nicht die Bueroklammer in Word ...

[Inge]

Wer kennt nicht die Bueroklammer in Word ...

Diesen nervigen ldioten habe ich schön längst ins Nirvana geschickt!

[Caveman]

@Caveman

 

Leider ist der Server gemietet, d.h. Aufruesten kommt leider nicht in Frage. Nur wechseln zu einem anderen Provider/einem anderen Geraet. Die Swap Partition zu vergroessern ist nicht ganz trivial, zum einen muss man dazu die Partitionierung an sich aendern (weil natuerlich kein freier Platz mehr da ist) und zum anderen hat man eigentlich auch verloren, wenn die Datenbank mit aktuellen Operationen im Swap landet.

 

Stimmt, ich vergass, der ist gemietet (was für ein Hobel ist das überhaupt?). Wäre denn ein Upgrade auf einen größeren Hobel teuer?

Was die Swappartition angeht: Das kann man sehr leicht mit PartitionMagic regeln, ganz ohne Neuinstallation des Systems. Ich persönlich bevorzuge aber sowieso eine Swapdatei statt einer Swappartition, weil das erheblich flexibler ist.

 

Das man "verloren" ist, wenn die Datenbank auslagern muss, habe ich aber bisher noch nicht erlebt. Der Datenbankserver kann sowieso selten die gesamte DB im RAM halten, swappen tut er bei einer genügend großen Datenbank sowieso.

 

Ich würd's ruhig mal mit ParitionMagic probieren. Schlechter als vorher kann eigentlich nicht werden, in dem Sinne riskiert man nichts (oder nicht viel).

[Elrond]

Das man "verloren" ist, wenn die Datenbank auslagern muss, habe ich aber bisher noch nicht erlebt. Der Datenbankserver kann sowieso selten die gesamte DB im RAM halten, swappen tut er bei einer genügend großen Datenbank sowieso.

 

Ich sehe das Problem eher darin, dass die Performance einbricht, wenn nicht nur Teile des Key Caches o.ae. im Swap landen, sondern die Engine an sich, weil z.B. von hunderten Apache Instanzen verdraengt. Dann entsteht die Situation, dass die Apaches auf das mysql warten, das durch die Auslagerung nicht in angemessener Zeit antworten kann -> es warten immer mehr Apache Instanzen -> das mysql hat es noch schwerer, wieder zeitnah ins RAM zu kommen -> trudel -> OOM

 

Stimmt, ich vergass, der ist gemietet (was für ein Hobel ist das überhaupt?). Wäre denn ein Upgrade auf einen größeren Hobel teuer?

 

Momentan ist der Server eine 2 GHz Maschine mit 512 MB RAM. Ein Upgrade wuerde 180 Euro Einrichtungsgebuehr fuer eine neue Maschine und ca. 70 Euro Miete im Monat kosten. wenn man die kleinste Maschine ueber den Minimalanforderungen nehmen wuerde.

 

Ich persönlich bevorzuge aber sowieso eine Swapdatei statt einer Swappartition, weil das erheblich flexibler ist.

 

Dabe ist jedoch das Problem, dass das Dateisystem, in dem die Swap-Partition liegt, bei jedem Zugriff auf das Swap involviert ist. Bei einer dedizierten Swap Partition gibt es kein ext3, xfs oder whatever, was vorher befragt werden muss -> schneller.

[Caveman]

Das man "verloren" ist, wenn die Datenbank auslagern muss, habe ich aber bisher noch nicht erlebt. Der Datenbankserver kann sowieso selten die gesamte DB im RAM halten, swappen tut er bei einer genügend großen Datenbank sowieso.

 

Ich sehe das Problem eher darin, dass die Performance einbricht, wenn nicht nur Teile des Key Caches o.ae. im Swap landen, sondern die Engine an sich, weil z.B. von hunderten Apache Instanzen verdraengt. Dann entsteht die Situation, dass die Apaches auf das mysql warten, das durch die Auslagerung nicht in angemessener Zeit antworten kann -> es warten immer mehr Apache Instanzen -> das mysql hat es noch schwerer, wieder zeitnah ins RAM zu kommen -> trudel -> OOM

 

 

Gut, bei MySQL kenn ich mich nicht aus. Von Oracle und MS SQL-Server weiß ich, dass die das Swappen nicht dem System überlassen sondern es selber regeln. Die zwacken sich einen fixen Teil vom RAM ab und gut ist. Eine Vergrößerung der Swappartition dürfte da keinen negativen Einfluß haben, Dir aber ggf. mehr Möglichkeiten bei der Wartung geben. Zugebenermassen gilt das alles nur für einen "echten" Rechner. Wie dies nun bei virtuellen System z.B. in einem Bladearray aussieht, weiß ich allerdings auch nicht.

Stimmt, ich vergass, der ist gemietet (was für ein Hobel ist das überhaupt?). Wäre denn ein Upgrade auf einen größeren Hobel teuer?

Momentan ist der Server eine 2 GHz Maschine mit 512 MB RAM. Ein Upgrade wuerde 180 Euro Einrichtungsgebuehr fuer eine neue Maschine und ca. 70 Euro Miete im Monat kosten. wenn man die kleinste Maschine ueber den Minimalanforderungen nehmen wuerde.

 

Fook, das ist viel Geld.

 

Ich könnte ggf. für lau/umsonst an einen etwas älteren Server kommen (2 CPUs) oder an ein oder zwei durchschnittliche 1 CPU-Systeme, aber da Ihr wohl nicht nur den Rechner sondern auch die Anbindung gemietet habt, würde Euch ein neuer Rechner so stand alone nicht viel bringen, oder?

Wenn ja, dann sag Bescheid, hier bei uns in der 4ma wird regelmässig Hardware ausgemustert...

[Explorer]

Kann es eigentlich sein, dass durch den Absturz ein paar Beiträge verloren gegangen sind?

 

Mir ist heute zufällig aufgefallen, dass ich irgendwas mit 9000 Beiträgen oder so habe. Vor zwei Monaten war ich bereits bei 11000 Beiträgen.

 

Oder löscht ihr hier alte Threads? Das fände ich ohne Ankündigung schade, weil ich mir sonst gerne einiges archivieren möchte...

[Caveman]

Soweit ich das mitbekommen habe, hat das System nach dem Ausfall die Postings neu gezählt. Wurden anno dazumal Beiträge gelöscht, ging der Zähler nicht entsprechend wieder runter. Ebenso waren im Zähler noch Postings drin, die so gar nicht mehr existieren (wer mal in die ganz alten Threads reingeht, wird diese leer vorfinden).

 

nach dem Ausfall wurden - wie gesagt - die Postings neu gezählt und zwar nur die noch vorhandenen. Daher die Diskrepanz.

[andre...]

Wie soll ein Programm im Userspace, welches vom Kernel einen zusammenhaengenden Speicherbereich vorgegaukelt bekommt, wissen, wieviel Speicher *tatsaechlich* noch verfuegbar ist?

Durch Anfrage beim Betriebssystem bzw. beim eigenen Speichermanager. Bevor z.B. eine Datei komplett in den Speicher geladen wird, muss das Anwendungsprogramm gucken, wie groß die Datei ist und wieviel Speicher momentan noch frei ist. Wenn der freie Speicher größer als die Datei ist, kann sie in einem Stück geladen werden, ansonsten nicht oder nur teilweise/blockweise.

 

Das ist ja auch letztendlich nicht wirklich wichtig, ob das einzelne Programm das weiss. Hauptsache der Kernel bzw. die VMMU weiss es.

Nein, beide müssen wissen, was sie tun und zu diesem Zwecke miteinander kommunizieren. Ein Programm muss sich - wie auch immer - davon überzeugen, dass der für die nächste Operation benötigte Speicherplatz auch tatsächlich verfügbar ist. Unter DOS gab es zwei Methoden, die m.W. auch in heutigen Systemen in Kombination verwendet werden. 1. Das System hat einen eigenen Speichermanager, der von Anwendungen aufgerufen werden kann, um Speicherblöcke zu belegen und später wieder freizugeben. 2. Die Anwendung hat einen eigenen Speichermanager, der sich beim Programmstart einmalig vom Speichermanager des Systems einen großen Speicherbereich reserveren lässt und den dann selbst verwaltet. - Die Kombination von beidem wäre, dass der Speichermanager der Anwendung bei Bedarf Speicher beim System nachfordert.

 

Wie auch immer, das alles sind genau beschreibbare Vorgänge, und die Speichermanager befinden sich davor und danach in einem definierten Zustand, den man abfragen und analysieren kann - bzw. können sollte. - Und wenn nun die Datenbank-Engine bei einem Optimierungslauf feststellt, dass für den nächsten Operationsschritt kein Speicher mehr frei ist, muss sie diesen Schritt unterlassen, die Datenbank in einen definierten Zustand versetzen und schließen und eine Meldung ausgeben. Letzteres ist oft gar nicht nötig, denn manche Algorithmen, wie z.B. Quicksort, können nach einem Abbruch einfach erneut losgejagt werden und kommen nach ein paar Anläufen dann doch noch sauber ins Ziel.

 

Über solche Dinge macht sich aber - wie ich ja schon schrieb - kaum noch jemand Gedanken. Und viele heutige Programmiersprachen unterstützen das auch noch, indem sie z.B. eine Funktion zur Abfrage des freien Speichers gar nicht mehr anbieten.

 

André

[Elrond]

@andre

 

Ich denke, es ist nicht so, wie Du es beschreibst. Ein Programm im Userspace kann Speicher anfordern, hat aber keine Chance zu wissen, wieviel Speicher tatsaechlich noch zur Verfuegung steht. Es erhaelt jedoch eine Rueckmeldung, ob die Anforderung geklappt hat.

 

Das macht auch schon alleine deshalb Sinn, weil andernfalls freien Speicher abfragen und Speicher allokieren fuer den Scheduler ein atomarer Vorgang sein muesste.

 

Es ist gerade ein Feature moderner Betriebssysteme, dass es eine Trennung zwischen Userspace und Kernelspace gibt und sich Anwendungen im Userspace um manche Dinge (Scheduling, IO, Memory-Verwaltung etc) keine Gedanken machen muessen, sondern das dem Kernel per definierter Schnittstelle ueberlassen. Auch wissen Sprachen wie Java oder die .NET Sprachen auf Grund der Konstruktion mit einer Virtual Machine garnicht, wieviel Speicher eine Datenstruktur aus Sicht des Betriebssystems am Ende wirklich belegt. Ist auch gut so, dass man sich darueber keine Gedanken machen muss.

 

Der Speichermanager kann auch hingehen und das Programm ohne Ruecksprache rauswerfen, wenn der Speicher dringend anderweitig benoetigt wird (genau das ist bei dem Absturz am 06. passiert).

[heideggern]

Der Speichermanager kann auch hingehen und das Programm ohne Ruecksprache rauswerfen, wenn der Speicher dringend anderweitig benoetigt wird (genau das ist bei dem Absturz am 06. passiert).

Das passiert auch in schlechten Restaurants: Da wirft der Wirt die Gäste ohne Rücksprache raus, weil der Platz gerade von anderen Gästen benötigt wird *hicks*

[andre...]

Ein Programm im Userspace kann Speicher anfordern, hat aber keine Chance zu wissen, wieviel Speicher tatsaechlich noch zur Verfuegung steht. Es erhaelt jedoch eine Rueckmeldung, ob die Anforderung geklappt hat.

Ja, das reicht als Alternative ja auch völlig aus. Und was du im folgenden geschrieben hast, ist ja auch völlig einleuchtend und durch den Programmierer auch beherrschbar, aber das hier ...

 

Der Speichermanager kann auch hingehen und das Programm ohne Ruecksprache rauswerfen, wenn der Speicher dringend anderweitig benoetigt wird (genau das ist bei dem Absturz am 06. passiert).

... macht jeden guten Willen wieder zunichte. Ich muss mich doch darauf verlassen können, dass ich Speicher, den mir das System gegeben hat, auch solange behalten darf, wie ich ihn brauche. Wenn ein anderes Programm mehr Speicher braucht, als da ist, kann dieser Speicher doch nicht einfach einem anderen Programm weggenommen werden - auch dann nicht, wenn das System selbst das Programm ist, das mehr will als da ist. Dann muss sich das System beim Booten eben vorsorglich Speicher für eigene Zwecke "zurücklegen" - und da kommen wir wieder genau an den Ausgangspunkt zurück: dass eigentlich jeder nur hofft, es möge schon irgendwie gutgehen, weil sich niemand vorausschauend ein reales Bild von den tatsächlichen Speicherverhältnissen macht/machen kann. Dass das Problem von den Anwendungsprogrammierern weggeschoben wurde, ist ja ganz nett und bequem, aber irgendeine Instanz muss das weggeschobene Problem in Empfang nehmen und lösen; das löst sich beim Hin- und Herschieben ja nicht wie bei Hütchenspielern in Luft auf.

 

André

[Elrond]

Das Verhalten von Linux im Falle mangelnden Hauptspeichers ist wirklich nicht optimal.

 

Grundsaetzlich finde ich den Ansatz, Prozesse zu entfernen, um wenigstens den Kernel in Betrieb zu halten, sinnvoll. Aber die Auswahl der zu toetenden Prozesse koennte man IMHO besser gestalten. Frueher war es so, dass zufaellig ausgewaehlte Prozesse erledigt wurden. Ich hatte immer das Pech, dass sshd dabei und die Maschine dann auch nicht mehr erreichbar war. Heute schaut der Kernel danach, welcher Prozess am meisten Speicher belegt und entfernt diesen zuerst (nach dem Motto "Kleine Aktion, grosse Wirkung").

 

Das hat aber auch Nachteile, wie diese Geschichte hier zeigt. Ich faende es am besten, wenn man Prioritaeten vergeben koennte (lieber 100 Apache Instanzen als die Datenbank verlieren) oder der Kernel auch die Aenderungsgeschwindigkeit (z.B. wieviele Kinder hat der Prozess in den letzten 10 Sekunden erzeugt) eines Prozessbaums beruecksichtigt. Oder man killt erst Prozesse, die keine zu schreibenden Dateien offen haben oder keine Network Sockets ...

 

Oder man steckt einfach mehr RAM rein und gut ist :->

[Caveman]

Der Speichermanager kann auch hingehen und das Programm ohne Ruecksprache rauswerfen, wenn der Speicher dringend anderweitig benoetigt wird (genau das ist bei dem Absturz am 06. passiert).

... macht jeden guten Willen wieder zunichte. Ich muss mich doch darauf verlassen können, dass ich Speicher, den mir das System gegeben hat, auch solange behalten darf, wie ich ihn brauche. Wenn ein anderes Programm mehr Speicher braucht, als da ist, kann dieser Speicher doch nicht einfach einem anderen Programm weggenommen werden - auch dann nicht, wenn das System selbst das Programm ist, das mehr will als da ist.

Es ist garantiert, dass angeforderter Speicher dem Programm solange zur Verfügung steht, wie das Programm ihn braucht (dies gilt auch für das OS), ggf. wird halt geswappt. DAS ist nie das Problem. Problematisch wird es dann, wenn der gesamte Speicher aufgebraucht ist, pyhiskalischer UND virtueller.

 

Die meisten Programme fangen eine OOM-Situation einfach nicht ab und gehen auf Grundeis (stürzen ab). Diese Fehlersituation abzufangen, bringt in der Regel auch nicht viel. Das Programm muss seine Arbeit dann sowieso einstellen (was durch den Absturz dann ja auch passiert) und einen Fehlerdialog hochpoppen zu lassen, bringt es oftmals auch nicht, der verbraucht auch Speicher.

 

Es ist nicht so, dass das System normalerweise selbst diese Programme rauskickt, um seinen eigenen Betrieb zu garantieren, die Programme "verabschieden" sich wie gesagt normalerweise selbst. Ob Linux so dreist ist, Programme zu kicken, weiß Elrond aber besser, Windows tut dies nicht, wird aber dann als Gesamtsystem quasi unbedienbar (was auch nicht der wahre Jakob ist).

Dann muss sich das System beim Booten eben vorsorglich Speicher für eigene Zwecke "zurücklegen" - und da kommen wir wieder genau an den Ausgangspunkt zurück: dass eigentlich jeder nur hofft, es möge schon irgendwie gutgehen, weil sich niemand vorausschauend ein reales Bild von den tatsächlichen Speicherverhältnissen macht/machen kann. Dass das Problem von den Anwendungsprogrammierern weggeschoben wurde, ist ja ganz nett und bequem, aber irgendeine Instanz muss das weggeschobene Problem in Empfang nehmen und lösen; das löst sich beim Hin- und Herschieben ja nicht wie bei Hütchenspielern in Luft auf.

Das Problem MUSS vom Programm weg ins Systgem hinein verlagert sein. Kein einziges vernünftiges OS (und MS-DOS war keins) erlaubt einem Anwenderprogramm in irgendeiner Art und Weise direkte Kontrolle über die Hardware, auch nicht auf den Speicher. Alles ist virtualisiert. Und ja, für den normalen Betrieb reserviert sich das System das, was es braucht. Ansonsten läuft alles dynamisch. Systemprozesse aber, die dauerhaft Speicher für ihren Betrieb brauchen, fordern diesen auch beim Booten schon an und geben ihn erst beim Runterfahren wieder her.

 

Ein Anwenderprogramm kann aber die größe des freien Speichers erfragen. Als Speichergröße gilt Größe des phyiskalischer RAMs plus virtuellen Speicher aufaddiert, das wird nicht getrennt betrachtet (macht auch keinen Sinn).

 

Passt eine Speicheranforderung da noch rein, wird sie durchgeführt, ansonsten abgelehnt. Wie gesagt, letzterer Punkt wird von den Programmen meistens nicht abgefangen. Einige sehr schlaue Programme die sehr kritische Operationen durchführen, verabschieden sich "gracefully" und räumen vielleicht hinter sich auf, aber ansonsten wird ganz gepflegt gegen die Wand gelaufen.

bearbeitet 12. Juni 2006 von Caveman