Hallo!
Reinhard Foerster wrote:
Aha: Mal wieder unser Lieblingsthema. Und wieder kommen die gleichen nicht realisierbaren Ideen wie vor einigen Monaten auf.
Es ist eben theoretisch *nicht* möglich, den "bösen" als solchen zu finden und ggf. zu killen. Weil eben dein "Tanzt einer aus der Reihe"-Prozess *nicht* deterministisch zu ermitteln ist. Wäre das der Fall, würde ja kein Mensch mehr über dieses Themea reden.
Aber die Prozesse laufen im User-Scape, also sind sie einem Verursacher zuzurechnen. Damit könnte also ulimit greifen (sofern es im betreffenden Kernel brauchbar ist; zwischen Kernel 2.2.x und 2.4.x tun sich hier offen- bar Welten auf!)
Es ist eben gerade der Witz der Sache, das knapper Speicher in unixoiden Systemen ein Problem ist. Du hast nun zwei Möglichkeiten:
- du schmeisst das komplette Unix-Konzept in die Tonne
- du sorgst dafür, dass es zu diesen Speicherengpässen nur sehr, sehr, sehr, ... selten kommt. (das bedeutet: ohne Böswilligkeit eines Nutzers im praktischen Betrieb nie)
Was mich daran stört: Zu diesem Zeitpunkt reicht der Speicher aus! SWAP wird wie gesagt nicht angerührt, der Server hat 512MB physikalisch RAM und der ist NICHT VOLL. Was ich nun noch nicht verstehe: Wie kommen unter diesen Umständen so hohe Load-Werte zustande? Das Prozessmanagement sagt ja zu diesem Zeitpunkt: 17 von 196 Prozessen sind aktiv, der Rest schläft. Kann es Warten auf eine Ressource sein? Und wenn ja, welche könnte gemeint sein?
Leider ist auch das nicht so einfach:
- Prozessorlast: Dann kann man kein "make" mehr eingeben.
Was denkst Du, wie ich zu diesen Load-Werten kam? Der Server arbeitet ja noch und das Script ist ein cron-Job, der also gelaufen ist. Eine Anmeldung zu diesem Zeitpunkt wäre unmöglich.
- Speicherverbrauch: Dann kann man den gimp keine großen Bilder mehr öffnen
lassen.
Quark. Nur weil ein Prozess 99% CPU frisst oder 2 GByte gross ist, ist er noch lange nicht böse und damit potentielles Opfer eines kills.
Ich kille alle User-Prozesse, deren Time-Werte über 10 Minuten liegen und die von Usern ausgelöst wurden. So erholte sich der Server nach ca. 15 Minuten.
Ein System mit starren Mem-Limits funktioniert nur, wenn du darauf Programmiersprachen verwendest, die *keinerlei* automatische Speicherallokation benötigen. D.h. du musst entweder allen Speicher explizit besorgen und testen (wie malloc in C) oder einen Exception-Mechanismus erfinden, der bei mem=alle anschlägt und dir sagt, wie weit dein Programm noch funktioniert hat. Beides ist in einer klassischen Unix+C-Umgebung unmöglich.
Kommen wir mal zum Thema zurück: Ich will auf dem System nicht programmieren, sondern Anwendungen laufen lassen. Darunter sind auch Speicher-Monster wie Netscape, StarOffice und Gimp. Im Normalbetrieb geht das ja alles.
Es kommt nur gelegentlich zu diesen Extremsituationen. Wären ein Win-Rechner dann halt ausgeschaltet wird und nur dieser eine Rechner betroffen ist, fällt bei mir ein Server aus, der hinter verschlossenen Türen steht (wo er auch hingehört) und der einen ganzen RAUM lahmlegt. Das ist ja das Hauptproblem.
Solange lasse ich nun Kernel 2.4.1 auf der Maschine laufen und beobachte weiter...
Gruss Reiner