Am Donnerstag, 7. Juni 2001 19:58 schrieb Jan Trippler:
Kein gangbarer Weg für ein Multiusersystem. Stell Dir mal vor, an einem Server arbeiten 20 Leute gleichzeitig mit den verschiedensten Anwendungen. Und dann bleibt er einfach mal 1 Minute stehn.
Naja, zur Zeit bleibt Linux doch auch einfach stehen - und nicht nur für 1 Minute. Ich frage mich, was besser ist.
Hm, das hab ich eigentlich nur bei einem (bugy) 2.2.16er Kernel erlebt, normal ist es so, dass, wenn der Swap voll ist und ein Programm neuen Speicher anfordert, diesen nicht mehr zugewiesen kriegt. Das Programm hat dann verschiedene Möglichkeiten darauf zu reagieren (üblich dürfte wohl sein, mit einer Fehlermeldung tschüss zu sagen, nachdem Datenbankverbindungen und offene Dateien geschlossen wurden). Wenn es den Status nicht abfrägt, und versucht in den vermeintlich angeforderten Speicher zu schreiben, dürfte es vom Kernel (Memory- protektion) eine auf die Finger kriegen und mit einem Sig 11 rausfallen. Linux lahmzulegen sollte auf diese Weise aber eigentlich nicht möglich sein. Dass er ne weile braucht, nen Amoklaufenden Prozess zu liquidieren und all den Speicher frei zu geben (immerhin liegt VM auf der Platte und da z.B. ein halbes Gigabyte freizuschaufeln ist halt mal arbeit). Auch kann es selbstverständlich passieren, dass einige Programme unberechtigterweise das zeitliche gesegnet haben, weil sie eben auch keinen Speicher mehr zugeordnet bekommen haben, aber wie soll der Kernel das entscheiden? Immerhin gibt es Programme die ganz regulär jede Menge Speicher ziehen.
Es hängt IMHO immer ganz entscheidend von der Systemkonfiguration ab, ob die Gefahr eines Überlaufens der swap-Bereiche besteht. _Wenn_ man so ein System hat (bei dem man sich wohl von der Vorstellung performanten Arbeitens eh verabschieden muss), dann kann man als Administrator doch eingreifen:
- per cron oder Dämon regelmäßig die Auslastung der swap-Bereiche überwachen (cat /proc/meminfo), Auslastung + Trend berechnen - bei Überschreiten einer definierten High-Water-Mark wie beschrieben per mkswap eine zusätzliche Swap-Datei anlegen und per swapon aktivieren. - bei Unterschreiten einer Low-Water-Mark diese Datei wieder deaktivieren. - Alarm an den Administrator, damit evtl. amoklaufende Prozesse gestoppt werden können.
Das ist alles mit Standard-Shell-Mitteln in wenigen Stunden realisierbar. Aus Performance-Sicht ist das natürlich nicht so
Ich seh bei der Lösung ein grosses Problem, wenn wirklich ein Programm amok läuft, knallt es Dir die Platte bis oben hin voll, das hat dann auch den Nachteil, dass keine Logs mehr geschrieben werden können, dass offene Programme die, da sie den benötigten Speicher nicht kriegen, keine Chance mehr erhalten, ihre Daten zu sichern, oder einen Dump wegzuschreiben. Es kann also dazu führen, dass es deutlich schwieriger wird, den Fehler dann letztendlich zu finden.
toll, da hilft nur 1. mehr RAM 2. mehr RAM 3. mehr RAM aber im Notfall sollte das doch gehen, oder?
Es gibt noch eine bessere Lösung: viel mehr RAM -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ | http://www.knightsoft.de Manfred | http://www.knightsoft-net.de