Am Dienstag, 20. Februar 2001 15:19 schrieb Andreas Reich zu "Re: [Lug-dd] Prozess oder Speicherproblem":

(Eine andere Möglichkeit, bei der Load astronomisch hochgeht, ist, wenn der Rechner auf einen abgeschmierten NFS-Server wartet.)

Oder ein SambaTNG als PDC und Fileserver für 2 Netze -> Viel Spaß -> 2.0.7 läuft tausendmal besser (auch als PDC)

cu, Konrad

Am Dienstag, 20. Februar 2001 16:45 schrieb Andre Schulze zu "Re: [Lug-dd] Prozess oder Speicherproblem":

Die Lösung wäre z.B. wie damals von Thorsten Werner vorgeschlagen, per default ein ulimit zu setzen. Du könntest das für jeden User machen. Es gibt allerdings keine wirklich gute Lösung. Mit einem 2.4.1 habe ich das noch nicht getestet, sollte aber besser funktionieren.

Das klingt hier immer so, als wäre Kernel 2.4 die Lösung für ALLE Probleme ;-) Ne Frage dazu: funktioniert das ISDN-System von SuSE 6.4 mit dem neuen Kernel? Muß ich nur den pppd updaten oder noch was anderes?

cu, Konrad

On Tue, Feb 20, 2001 at 04:45:14PM +0100, Andre Schulze wrote:

Am Tue den 20 Feb 2001 um 03:18:10PM +0100 schrieb Reiner Klaproth:

...

Hallo!

An meinem Terminalserver bleiben gelegentlich alle Prozesse hängen. Bei der Suche nach dem Auslöser habe ich mein System mal genauer unter die Lupe genommen:

Zum Zeitpunkt des Hängenbleibens steigen die Load-Werte in kürzester Zeit ohne jede Vorwarnung in astronomische Höhen. Heute war es # cat /proc/loadavg 114.32 116.51 113.89 17/196 9854

Zu diesem Zeitpunkt kam in /var/log/messages: kernel: cape ... kernel: VM: do_try_to_free_pages failed for <prozess>

Genau zu diesem Thema gab es schon mal einen langen Thread:

Der Fehler liegt IMHO im Verhalten des Linux kernels, der bis über die Grenze dessen, was sinnvoll ist, Programmen Speicher vergibt. Erreicht das System dann die Grenze, wo wirklich der gesamte physische und virtuelle Speicher voll ist, kommt es zu genau dem Phänomen, welches du hier schilderst.

Wenn der Kernel keinen Speicher mehr hat, schießt er wahllos Prozesse ab, bis er wieder genug hat (das sieht man dann auch wunderbar in /var/log/messages), hängt sich aber nicht auf.

Ciao, Tobias

Am Mittwoch, 21. Februar 2001 16:50 schrieb Reiner Klaproth:

Dennoch gibt mir zu denken: Wie verkaufe ich Linux als stabiles System, wenn eine "solche Kleinigkeit" das System derart straucheln läßt!

Ich denke mal, Featuritis und Instabilität lassen sich schlecht trennen. Beim Kernel werden Codebäume, die für Nicht-Kernel-Programmierer solide aussehen, abgelehnt, wenn die Stabilität nicht hinreichend ist. KDE ist ein Projekt, daß es sich auf die Fahnen geschrieben hat, an erster Stelle dem Windows-Umsteiger das Leben leicht zu machen. Wahrscheinlich mit allen Abstürzen gratis dazu ;-)

Wenn die Core-Programme von KDE instabil laufen, dann ist das Entwicklersache und wird IMO auch schnell gefixt. Was Anwendungsprogramme angeht, da hat oft die Wishlist der Nutzerschaft die Finger mit im Spiel. Beispiel von vorletzter Woche auf KDE-Devel: Das Programm Xpcd, mit dem man Foto-CD's anschauen kann, ist zwar ganz ok, aaaaber es ist ja kein KDE-Programm, also muß man eines daraus machen... KDE hat's gut, die haben genügend Entwickler für solche Späße. Und vor allem genügend Präsenz. Da tut sich aber so einiges im Moment, z.B. der "red carpet" von Ximian, der (angeblich) die Paketabhängigkeiten stets zu Ungunsten von KDE auslegt. Aber stop jetzt, das ist schon OT.

Josef Spillner

On Thu, Feb 22, 2001 at 09:23:10AM +0100, Andre Schulze wrote:

Tritt bringen. Eine etwas unangenehme Nebenerscheinung ist auch, das bei extremen Speichermangel _beliebige_ Prozesse gekillt werden.

Wie sieht es damit eigentlich in 2.4.x aus? Wurde dort der Umgang mit Speichenengpässen geändert?

Reinhard

Hallo!

Reinhard Foerster wrote:

Wie sieht es damit eigentlich in 2.4.x aus? Wurde dort der Umgang mit Speichenengpässen geändert?

ich kann zumindest soviel beitragen: Ich habe besagten Server auf Kernel 2.4.1 (und reiserfs) umgestellt. Die Load-Werte blieben diese Tage im unkritischen Bereich. Wichtig war zudem: Es wurde ein Kernel-Thread ausgelöst für APM (Advanced Power Management), der sich ebenfalls festgefressen hatte und über Nacht fast 80% CPU-Auslastung brachte. Ich habe einen neuen Kernel erstellt ohne APM, der zumindest heute recht zufriedenstellend läuft.

Eine unangenehme Eigenschaft hat der neue Kernel noch: Die Tools für das Prozessmanagement unter KDE arbeiten damit nicht sauber zusammen: Die Prozesse, die von Nutzern angeworfen wurden, gehören plötzlich root. Dieser Effekt betrifft ausschließlich ktop/ksysguard und nicht ps oder top an der Konsole.

Gruss Reiner

Andre Schulze (as8@Rcs1.urz.tu-dresden.de) wrote:

AS> Am Don den 22 Feb 2001 um 10:44:53 +0100 schrieb Reinhard Foerster:

...

Wie sieht es damit eigentlich in 2.4.x aus? Wurde dort der Umgang mit Speichenengpässen geändert?

AS> Super! Obwohl das Verhalten mit dem overcommit memory immer noch so AS> ist, trifft es jetzt wenigstens bei kills den richtigen Übeltäter. Das AS> Verhalten ist reproduzierbar. Ob immer der größte Prozess gesteinigt AS> wird, muß man wohl mal im Code nachsehen.

Ich poste einfach mal den Ausschnitt aus /usr/src/linux-2.4.0/mm/oom_kill.c ... man möge mir verzeihen, falls das irgendwie gegen die Netikette ist.

/** * oom_badness - calculate a numeric value for how bad this task has been * @p: task struct of which task we should calculate * * The formula used is relatively simple and documented inline in the * function. The main rationale is that we want to select a good task * to kill when we run out of memory. * * Good in this context means that: * to kill when we run out of memory. * * Good in this context means that: * 1) we lose the minimum amount of work done * 2) we recover a large amount of memory * 3) we don't kill anything innocent of eating tons of memory * 4) we want to kill the minimum amount of processes (one) * 5) we try to kill the process the user expects us to kill, this * algorithm has been meticulously tuned to meet the priniciple * of least surprise ... (be careful when you change it) */

static int badness(struct task_struct *p) { int points, cpu_time, run_time;

if (!p->mm) return 0; /* * The memory size of the process is the basis for the badness. */ points = p->mm->total_vm;

/* * CPU time is in seconds and run time is in minutes. There is no * particular reason for this other than that it turned out to work * very well in practice. This is not safe against jiffie wraps * but we don't care _that_ much... */ cpu_time = (p->times.tms_utime + p->times.tms_stime) >> (SHIFT_HZ + 3); run_time = (jiffies - p->start_time) >> (SHIFT_HZ + 10);

points /= int_sqrt(cpu_time); points /= int_sqrt(int_sqrt(run_time));

/* * Niced processes are most likely less important, so double * their badness points. */ if (p->nice > 0) points *= 2;

/* * Superuser processes are usually more important, so we make it * less likely that we kill those. */ if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_ADMIN) || p->uid == 0 || p->euid == 0) points /= 4;

/* * We don't want to kill a process with direct hardware access. * Not only could that mess up the hardware, but usually users * tend to only have this flag set on applications they think * of as important. */ if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO)) points /= 4; #ifdef DEBUG printk(KERN_DEBUG "OOMkill: task %d (%s) got %d points\n", p->pid, p->comm, points); #endif return points; }

Am Die den 27 Feb 2001 um 12:31:26 +0100 schrieb Torsten Werner:

Am Montag, dem 26. Februar 2001 um 20:58:51, schrieb Andre Schulze:

...

der urspruengliche Thread vom letzten Jahr zu dem Thema hatte ich angefangen, weil meine Linux Kiste durch ein unkonditionales "select * from foo" fast abgeschmiert war.

Jetzt sieht es so aus: Feb 26 20:41:31 tux kernel: Out of Memory: Killed process 410 (mysql).

Und wenn Du den Kernel wechselst, hast Du dann wieder das Verhalten vom letzten Jahr? Waere wirklich interessant...

Ich habe es nochmal ausprobiert und hier ist ein Auszug aus dem syslog: Feb 26 23:32:53 inspiron kernel: VM: do_try_to_free_pages failed for nmbd... Feb 26 23:32:56 inspiron last message repeated 15 times

<schnipp - geht so für diverse Prozesse weiter...>

Feb 27 00:33:44 inspiron kernel: VM: do_try_to_free_pages failed for kswapd... Feb 27 00:51:31 inspiron last message repeated 3 times

Jetzt habe ich nach 1.5 Stunden die Hoffnung verloren, daß noch irgendwas zu retten ist und neu gebootet, da die Kiste auf rein gar nichs mehr reagiert hat (außer pings). Interessant ist, daß so wie es hier aussieht, nichts gekillt wurde, d.h. der kernel noch in dem Stadium war, in dem er versucht Speicher frei zu machen. Danach hatte damals der kernel angefangen, Prozesse zu killen. Vielleicht wäre es nach ewigem Warten auch noch dazu gekommen.

andre

Am Don den 22 Feb 2001 um 07:58:16 +0100 schrieb Josef Spillner:

Am Donnerstag, 22. Februar 2001 09:23 schrieb Andre Schulze:

...

Nicht desto trotz: ein user level Programm darf keinen kernel aus dem Tritt bringen. Eine etwas unangenehme Nebenerscheinung ist auch, das bei extremen Speichermangel _beliebige_ Prozesse gekillt werden.

Richtig. Der Kernel hat dafür zu sorgen, daß "seine" Kinderchen (genauer gesagt die von init) ihm nichts anhaben können. Das macht Linux als Gesamtsystem ja auch stabiler als Windows, weil Leute, die mal eben was programmieren, nicht viel anrichten können (und deshalb mag ich diesen Kernel :))

Amen. Unter einen NT Kernel passiert genau sowas nicht - schluss aus. Nur weil es hier um Linux geht wird der bug gleich zum feature hochgehype't.

Das mit den beliebigen Prozessen sehe ich mittlerweile auch von dieser Seite her. Rein theoretisch kann man aber hier Abhilfe schaffen, wenn ein root-Daemon (von dem optimistischerweise angenommen wird daß er stabil läuft) alle Prozesse beobachtet und über ihr Verhalten Buch führt. Tanzt einer aus der Reihe wird er gekillt.

Wäre es nicht einfacher, wenn der kernel nur soviel Speicher vergibt wie er hat, bzw. nur wenn ein Schalter gesetzt ist, sich so verhält, wie er das jetzt tut?

Und es würde mich sehr wundern wenn es sowas nicht schon gibt, als Frontend zu ulimit und Konsorten...

kuhlimit?

andre

On Fri, Feb 23, 2001 at 09:38:47AM +0100, Torsten Werner wrote:

Mensch, wer hat denn diesen Schwachsinn wieder angefangen? Gibt es keine besseren Themen? Es kommt mir vor, als wuerden hier Windows-DAUs diskutieren.

Das mag sein. Mir scheint auch, dass hier viele ziemlich aneinander vorbei reden und 10 verschiedene Dinge total vermischen.

Wer wirklich fachliches Interesse am Thema hat, sollte sich die Muehe machen, die Kernel-Listen-Archive zu lesen, und hier nicht unqualifiziert rumnerven.

Aha. Gut. Dann lassen wir mal alles "komplizierte" weg (also automatisch allokierten Speicher und die fork/exec-Sache mit copy on write) und begeben uns auf Niveau eines Schülers der 4. Klasse. In diesem Alter sollte man mit 3-stelligen ganzen Zahlen rechnen können. Also schauen wir doch dem 4-klässler mal bei seinen ersten Linuxerkundungen über die Schulter.

Er hat folgendes System:

rf11@max:~/tmp> uname -a Linux max 2.2.18 #1 Mon Feb 19 21:58:07 CET 2001 i586 unknown rf11@max:~/tmp> free total used free shared buffers cached Mem: 95788 41048 54740 20320 6460 15540 -/+ buffers/cache: 19048 76740 Swap: 266608 0 266608 rf11@max:~/tmp>

Also ein Linux-2.2 mit ca. 75 MB freien RAM und ca. 250 MB freiem Swap. Der Viertklässler erkennt sofort, dass er insgesamt 325 MB freien Speicher hat, da er schon richtig gut Addieren kann. "Sooo." denkt er sich: "Den Speicher will ich jetzt mal nutzen."

(das Programm sagt genau was es tut, der Code folgt unten, falls es jemand nicht glaubt)

rf11@max:~/tmp> ./a.out 300 Allokiere 300 MB: ok Allokiere zusätzlich noch 300 MB: ok gebe ggf. alles wieder frei Allokiere 600 MB in einem Stück: failed gebe ggf. alles wieder frei rf11@max:~/tmp>

Da hat unser Probant also von seinem Rechner nach der 2. Ausgabezeile tatsächlich 600 MB Speicher in zwei Teilen á 300 MB bekommen, obwohl sein Rechner doch eigentlich nur 325 MB hat. Der 4.-klässler staunt wie Sau und glaubt ab diesem Moment an die göttliche Speichervermehrung.

Nachdem er in Zeile 3 die 2*300 MB wieder freigegeben hat, holt er sich in Zeile 4 die 600 MB nochmal, diesmal aber als ein Stück. "Oooops!!!" sagt der 4-klässler "Das geht schief? Doch nix mit göttlicher Speichervermehrung?"

Unser 4-klässler ist nun völlig von der Rolle: 2*300 MB hat ihm seine Kiste gegeben, 600 MB am Stück hingegen nicht. Nachdem er sich das 2 Sekunden durch den Kopf gehen läßt, greift sich unser 4-klässler kurz an die Birne und gibt einen unverständlichen Ton von sich. Dann löscht er flugs das ulkige Linux von der Platte und installiert sich ein System, das ihn nicht so sehr bescheißt wie das Linux.

Ich kann ihn gut verstehen ...

... und ich kann die Leute nicht verstehen, die dieses, schon auf den ersten Blick völlig idiotische, Verhalten nicht stört.

Torsten: Während so ein gundlegendes Probleme in einem Stable-Kernel von vielen Entwicklern völlig ignoriert wird (bzw. zum Feature erklärt wird), streitet man sich auf der Kernelliste darüber, wie man noch 3% mehr Performance durch eine andere Strategie der Speicherverwaltung herausholt. Das ist mir als Nur-Nutzer sehr unverständlich.

Reinhard (bitte nur ernstgemeinte Zuschriften :-)

PS: Weil die Frage hier im Thread auch aufkam: Alle anderen Unixe haben das oben beschriebene Fehlverhalten von Linux nicht. Das ist wohl der Hauptgrund dafür, daß es bei den anderen Systemen um viele Größenordnungen seltener zu einem Speicherengpass kommt, den wir ja als ein generelles Problem für unixoide Systeme ausgemacht hatten.

--------------------------------- Nun noch der Code. Mich würde mal interessieren, was linux-2.4 dazu sagt.

#include <stdio.h> #include <stdlib.h> int main(int argc, char **argv) { int mb; void *p1, *p2;

if (argc != 2) { printf("Ich will ne MB-Zahl als Parameter\n"); return -1; } mb = atoi(argv[1]); printf("Allokiere %d MB: ", mb); if ((p1 = malloc(mb*1024*1024)) == NULL) printf("failed\n"); else printf("ok\n");

printf("Allokiere zusätzlich noch %d MB: ", mb); if ((p2 = malloc(mb*1024*1024)) == NULL) printf("failed\n"); else printf("ok\n"); printf("gebe ggf. alles wieder frei\n"); if (p1 != NULL) free(p1); if (p2 != NULL) free(p2); printf("Allokiere %d MB in einem Stück: ", mb*2); if ((p1 = malloc(mb*1024*1024*2)) == NULL) printf("failed\n"); else printf("ok\n");

printf("gebe ggf. alles wieder frei\n"); if (p1 != NULL) free(p1);

return 0; }

Hi!

On Mon, Feb 26, 2001 at 09:02:42PM +0100, Torsten Werner wrote: [snip Vergleich ComercialOS - Linux]

Das ist ja alles schön und gut, man müßte die Strategie nur eben wählen können. Der von Dir beschriebene "Vorteil" kann in einem anderem Szenario ein Nachteil sein.

Gruß, Eric

On Tue, Feb 27, 2001 at 05:33:36AM +0100, Reinhard Foerster wrote:

...

Mal eine realistisches Beispiel - ein WWW-Server mit Dutzenden Serverprozessen. Dein tolles kommerzielles Unix verbietet das forken

Die Welt besteht nicht nur aus WWW-Servern. Wenn in einer Firma der Datenbankserver einfach mal so abgeschossen wird (der wird oftmal der "böse" sein, da viel Speicherbedarf), oder auch ein beliebiger anderer Prozess, dann hat der Admin ein Problem. Für den Fall, daß auf dem Rechner missionskritische Anwendungen laufen, sollte der Admin lieber ein einfaches (!) Ticket nach Venezuela im Schrank haben.

...

Nun kannst Du mal raten, warum man Linux gerade bei WWW-Servern so gerne einsetzt und dem kommerziellen Kram laengst den Rang abgelaufen hat...

Weil es billig ist?

Super Argument! (Ebenso sinnloses Analogon: Windows auf dem Desktop ist so wahnsinnig verbreitet, weil es technisch so genial ist)

Ist es das denn nicht? Steht so auf der Verpackung. Meinst Du die haben mich beschwindelt?

Mir gehts mehr um die Technik als ums Marketing.

Hype ist auch Marketing, aber nicht immer gutes. Ich habe in der letzten Zeit das Gefühl, daß Linux langsam aber sicher an Featuritis leidet. Man will immer mehr einbauen, ohne das vorhandene auszubauen (Extensivität vs. Intensivität). Wenn die "Gemeinde" da nicht aufpaßt, kann Linux ganz schnell da landen, wo schon viele andere OSs gelandet sind.

...

Darum bitte ich auch. Insbesondere die irrsinnige Behauptung, Linux wuerde beliebige Prozesse killen, sollte doch endlich mal aufhoeren.

Diese Behauptung ist leider wahr. Lies einfach den Code. Lies vor allem erstmal den Code, wie der Speicher rausgegeben wird.

Genau. Ich bin mir recht sicher, daß es möglich wäre eine Programm zu schreiben, welches einen produktiven Server zu Fall bringt, in dem es diverse Prozesse startet, die nach verschiedenen Gesichtspunkten Speicher ausfassen und teilweise auch belegen. Wenn man das geschickt macht, werden ganz schnell die "falschen" Prozesse gekillt.

3. der Kern kann nicht feststellen, wer der böse ist (weil es keine bösen Prozesse gibt. Punkt!!!)

Eben.

Disclaimer: Ich (und sicher auch Reinhard) mag Linux und will es hier nicht runtermachen. Ich finde es nur sinnvoll solche Probleme zur Diskussion zu stellen. Ich finde das sogar enorm wichtig. Bei MS Produkten wird sowas einfach hingenommen. Die Diskussionfähigkeit ist doch gerade ein Vorteil von OSS (und Verwandten).

Gruß, Eric

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.

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?

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.

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.

Reinhard

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

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

On Saturday 03 March 2001 00:44, Reinhard Foerster wrote:

On Fri, Mar 02, 2001 at 06:02:09PM +0100, Konrad Rosenbaum wrote:

...

Wenn Du die Theorie des Software-Engineering meinst wird Dir jeder Programmierer zustimmen, dass soetwas vermeidbar ist und auf keinen Fall guten Stil darstellt.

Die "Theorie des Software-Engineering" ist mir relativ schnuppe. Soll doch jeder wuseln wie er will (solange es nicht mein Geld kostet)

Witzige Einstellung - hat schon sehr interessante Effekte gezeigt ;-)

Mit Theorie waren hier Deine eigenen Forderungen, wie "malloc muss auf NULL geprüft werden" (malloc OOM), SIGSEGV muss korrekt behandelt werden (malloc OOM) oder "fork auf -1 testen" (fork OOM) gemeint.

...

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%).

Mag sein. Dagegen kann man wahrscheinlich wenig tun. Jeder bekommt, was er fabriziert.

Oder was die Firma auf der anderen Seite der Verpackung auf die CD's gepresst hat.

Mein Punkt ist der: Das OS muss so gebaut sein, dass ein *ordentliches Programm* auch ordentlich ablaufen kann. Ein OS, was hier unnötige Kompromisse eingeht, ist Schrott.

Ein Kompromissloses OS gibt es nicht. Nur das Ziel des Kompromisses variiert. In unserem Beispiel: Linux -> die Ressourcen ideal ausnutzen Solaris -> dem Programm keinesfalls mehr versprechen als man halten kann ..."your milage may vary"...

Hast Du mal lineare Optimierung oder ähnlichen Blödsinn gehabt? Die wichtige Lektion war nicht, dass man 3 Anläufe für Mathe-Prüfungen braucht oder jemals den Kram praktisch einsetzt, sondern: Komplexe Systemen bestehen aus wenigen Gegebenheiten (digitales Rechensystem), einigen Zielen (wenige Crashes, Geschwindigkeit, optimale Ressourcen-nutzung, ...) und haufenweise Randbedingungen (Hardware, Fähigkeiten und Zeit der Programmierer, Fehlerwahrscheinlichkeit, ...), die einen zu Kompromissen zwingen. Leider. Ich würde gerne mal mit einer idealen Turing-Maschine arbeiten...

Oder andersrum ausgedrückt: Wenn das Nutzerprogramm Mist macht (z.B. stirbt) sollte es mit nahezu 100%er Sicherheit am Nutzerprogramm liegen und nicht am OS.

Das erreichst Du teilweise mit fork-OOMs. Problem dabei ist: bei gegebenem RAM macht das System eher schlapp, da die OOM-Algorithmen schneller triggern. Gerade Server, die Daten ausliefern, haben die Angewohnheit Megabyte-weise Speicher zu allozieren, den sie erst später nutzen. Ausserdem starten sie haufenweise Kindprozesse, die nur einen Teil der Ressourcen nutzen. Bei einem overcommit-mem-System (malloc-OOM-System) wird das sehr lange gut gehen, da nur ein Teil der allozierten Ressourcen wirklich physisch vorhanden sein muss. Ein fork-OOM-System wird Alarm schlagen, wenn es auch nur den Verdacht eines overcommit hat: also wesentlich eher als ein overcommit-System.

Mit hoher Wahrscheinlichkeit ist ein fork-OOM-System schneller zum (scheinbaren) Stillstand zu bringen als ein overcommit-System, das dann aber spektakulärer crasht. Was für mich (mit meinen begrenzten finanziellen Ressourcen) ein verdammt guter Kompromiss ist.

...

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.

Diese Fehlersituation (bei überlast werden keine neuen Nutzer/Jobs werden mehr angenommen) ist deutlich günstiger, als weiterhin Jobs anzunehmen, die aber auf halbem Weg zum Ziel abgebrochen werden müssen.

Der Effekt für den User ist der selbe: keine Antwort auf Fragen.

Bitte versteh' mich jetzt nicht falsch: rein technisch ist ein fork-OOM-System auf einem kritischen System vorzuziehen, da die Wahrscheinlichkeit eines katastrophalen DB-crashs und halbfertigen Transaktionen geringer ist (ich schätze ca. 20-25%). Rein praktisch habe ich bisher Solaris immer als anfälliger als Linux erlebt (mein subjektiver Eindruck, ich kann ihn nicht mit Daten unterlegen).

Konrad

On Sunday 04 March 2001 02:33, Reinhard Foerster wrote:

On Sat, Mar 03, 2001 at 10:21:17PM +0100, Konrad Rosenbaum wrote:

...

Ein Kompromissloses OS gibt es nicht. Nur das Ziel des Kompromisses variiert.

Klar. Aber es gibt bestimmte Grundsätze, an den man nicht rütteln sollte.

Grundsätze wie in "wir bestehen drauf weils unser Prof. auch tat" oder wie in "Randbedingung, die erfüllt sein muss damit es nicht Schrott a'la M$ wird"?

...

Bitte versteh' mich jetzt nicht falsch: rein technisch ist ein fork-OOM-System auf einem kritischen System vorzuziehen, da die

Aha, das wollte ich hören .... und da du trotzdem das linuxsche Verhalten verteidigst heisst das: Für dich gehören nur unkritische Sachen auf Linuxrechner. Und das ist der Punkt zu sein, an dem unsere Ansichten auseinander laufen.

Nun, eigentlich auch kritische. Aber die Dimensionierung des Systems muss anders gemacht werden (diese Bedingungen würde ich auch an fork-OOM-Systeme stellen): *der Speicher muss auch für unwahrscheinliche Szenarien reichen *genug Rechenpower für extremen Traffic *mehrfache Filterung durch Firewalls (DMZ-Prinzip) *DB läuft auf einem anderen Rechner als der Webserver

IMHO ist der Punkt bei beiden Systemen: sie müssen in kritischen Sektionen so gestaltet sein, dass es bei High-Traffic weder zu CPU-Engpässen, noch zu OOM's kommt. Ausserdem muss eine Notfallstrategie für DDOS-Szenarien existieren. Die Sicherungsmaßnahmen sind natürlich in den Details leicht unterschiedlich.

Mathematisch ausgedrückt: der Punkt des aktuellen Optimums sollte möglichst nie die Randbedingungen berühren müssen.

Konrad

Am Sun den 04 Mar 2001 um 06:19:41PM +0100 schrieb Reinhard Foerster:

Was das Kernthema betrifft, hast du mir ja in deinem letzten Posting bereits zugestimmt. Jetzt muss ich nur noch Torsten bearbeiten :-)

Er konnte sich am vergangenen Mittwoch live an einem Rechner im Pentagon ansehen, wie die Folgen des overcommitings aussehen. (ich hatte noch nicht mal nachgeholfen :-)

andre

Am Mon den 05 Mär 2001 um 07:10:46 +0100 schrieb Torsten Werner:

Mit einem gewaltsamen Exploit bekommt man wahrscheinlich jedes Betriebssystem in Schwierigkeiten. Das hat auch Reinhard bisher nicht

Richtig. Nur braucht es bei Linux nicht ein Exploit zu sein, wie du gesehen hast (jemand anderes hatte vorher an der Kiste rumgespielt - ich bin unschuldig - wie gesagt). Die Diskussion wird langsam absurd. Ich behaupte hier einfach mal, daß ihr einfach noch nicht an der Grenze des Speichers herumgetan habt. Dann kann man auch locker behaupten, daß das bei Linux alles viel hipper ist als beim Rest der Welt. Konrads Forderung, der Server muß dick genug sein, um auch bei extremen load nicht an die Grenze zu kommen, erinnert mich an ein OS, über das jeder bei jeder Gelegenheit ablästert. Auch eine DMZ zu fordern klingt so, als ob man dahinter einen wackeligen NT Server betreiben möchte - das kann nicht euer Ernst sein.

bestritten. Ausserdem ist die Pentacon-Installation alles andere als optimal. (Ich denke nur an die tolle Firewall, die ssh denied!)

Wir kommen mal wieder zu den Meta-Themen. Ich möchte mich hier nicht über ssh auslassen, da ich im Moment nicht genau weis, warum die Ports unterhalb 1000 (neben 22 natürlich) benutzt. Die firewall ist erst mal vernünftig eingestellt, wenn sie das verbietet. Das habe ich auch so gemacht und ähnliche Probleme wie du im Pentacon bekommen. Ein Fehler der Installation ist vielleicht, keinen 2.4 oder gleich FreeBSD zu benutzen da stimme ich dir zu ;-)

andre

On Monday 05 March 2001 19:10, Torsten Werner wrote:

Am Sonntag, dem 04. Maerz 2001 um 21:40:10, schrieb Andre Schulze:

...

Am Sun den 04 Mar 2001 um 06:19:41PM +0100 schrieb Reinhard Foerster:

...

Jetzt muss ich nur noch Torsten bearbeiten :-)

Er konnte sich am vergangenen Mittwoch live an einem Rechner im Pentagon ansehen, wie die Folgen des overcommitings aussehen. (ich hatte noch nicht mal nachgeholfen :-)

Mit einem gewaltsamen Exploit bekommt man wahrscheinlich jedes Betriebssystem in Schwierigkeiten. Das hat auch Reinhard bisher nicht bestritten. Ausserdem ist die Pentacon-Installation alles andere als optimal. (Ich denke nur an die tolle Firewall, die ssh denied!)

Heh, was kann ich daf�r dass SuSE die ssh SUID-root installiert?

Sind Euch noch andere Sachen aufgefallen?

Konrad

On Mon, Mar 05, 2001 at 05:42:55PM +0100, Konrad Rosenbaum wrote:

Wir scheinen hier zwei sehr gegensätzliche Herangehensweise zu haben (wen wunderts): RF: es ist möglich ein korrektes System zu schaffen, dass theoretisch nicht crashen kann

Habe ich nie gesagt. Insbesondere habe ich auch schon eher erkärt, warum das auf Unix-basis unmöglich ist. Um einem solchen System aber *recht nah* zu kommen, sollte man nicht gleich bei jedem Problem eine 50%-Lösung akzeptieren und sie als tollen Kompromiss verkaufen, wenn auch problemlos eine 99%-Lösung möglich ist. (Vor allem dann nicht, wenn die 99%-Lösung schon seit -zig Jahren im Einsatz und allgemein bekannt ist.)

KR: Programmierer sind alles andere als perfekt, also spielen wir hier mit Wahrscheinlichkeiten, die auf unterschiedlichen Wegen verändert werden können.

Es gibt einfach Stellen, an denen man ein Wahrscheinlichkeit von 1 erwarten kann. Nicht überall ist es nötig, Abstiche zu machen. Wiederum frage ich mich aber, was dein Posting mit Speicherverwaltung zu tun hat. Ich würde eine Speicherverwaltung völlig unabhängig davon konstuieren, ob der zukünftige Programmierer nur Mist programmiert oder nicht. Deshalb halte ich deine Ausführungen zur durchschnittlichen Qualitaet von Kode für off topic.

Eben: mein Ansatz ist es die Randbedingungen (Hardwarebeschränkungen) zu beseitigen. Deiner ist es scheinbar ein Optimum auf den Randbedingungen zu finden.

Meinen Ansatz hast du richtig erkannt. So optimiert man nun mal. Dein Ansatz der Beseitigung von Hardwarebeschränkungen ist doch absolut unrealisierbar. Mir sind bisher jedenfalls weder der unendlich grosse Speicher, die unendliche Rechenkapazität noch die unendlich grosse Festplatte über den Weg gelaufen. Wie willst du also die Hardwarebeschränkungen beseitigen? (Falls du eine allgemeine Lösung zur Beseitigung von Randbedingungen in Optimierungsproblemen gefunden hast, schreib mir bitte ne private Mail. Die am häufigsten zuschlagende Randbedingung bei meinen privaten Optimierungsproblemen ist zu knappes Geld. Mit deiner Hilfe werde ich diese Randbedingung dann wohl einfach beseitigen können. *jubel*)

Mathematisch: du willt ein OP mit NBs dadurch lösen, dass du die NBs beseitigst. Das ist völliger Humbug.

Reinhard

On Tue, Mar 06, 2001 at 05:54:37PM +0100, Konrad Rosenbaum wrote:

langsam entwickelt sich das wieder zu einem unserer typischen Kommunikationsprobleme.... ;-)

Genau.

Mein Problem: _Deine_ 99%-Lösung ist eine 40%-Lösung für _mich_ (privat), da ich nicht genug Geld für Speicherriegel für den _Normalfall_ eines fork-OOM-Systems habe (und privat gehe ich nur vom Normalfall aus, da es unkritisch ist, ob mein Privatrechner 10Minuten oder 3 Tage ausfällt). Ein malloc-OOM-System hat den Vorteil, dass es den Speicher effizienter ausnutzt.

Die ganze Diskussion ist schon furchtbar verrannt, deshalb fang ich noch mal von ganz vorne an: (wer mag darf schnell noch mal gähnen)

Das Ausgangsproblem ist doch einfach, daß der Speicher zu knapp ist. Bei !linux wird einfach kein Speicher mehr ausgegeben, bei linux wird der Zähler für den belegten Speicher nur dann hochgezählt, wenn ein pagefault auftritt, d.h. wenn ein Prozess auf eine Seite zugreift, die er zwar angefordert hat, auf die er aber noch nie zugegriffen hat. Daraus entsteht folgendes Problem: Prozesse fassen in der Summe mehr Speicher aus, als wirklich da ist und irgendwann gehen evtl. dem Kern die Seiten aus, weil er mehr ausgegeben hat, als verfügbar sind. Dieses Vorgehen erscheint in gewissen Situation sinnvoll. Aber: In einem sinnvollen System sollten nie auf Dauer wesentlich mehr Seiten _gebraucht_ werden, als tatsächlich physisch (!!) da sind, weil das System vor lauter Swappen nicht mehr zum arbeiten kommt. Ausnahmen sind kurzzeitige Hochlastsituationen. Sagen wir ein System hat x physische Seiten und y*x soviel Swap (in Seiten), wobei y > 2 ist (Swap ist billig). In diesem Fall ist die Gesamtzahl der verfügbaren Seiten (y+1)*x. Wenn wir für y z.B. 5 annehmen, dann haben wir mehr verfügbare Seiten, als sinnvoll ist. Wenn die Seiten nähmlich gar nicht gebraucht werden (siehe "linux-szenario" oben), dann wird der swap auch nicht angefasst, aber die Seiten können zumindest ausgegeben werden. Wenn die Seiten doch gebraucht werden sollen, dann wird eben wild geswapt. Soweit kommt es nach dem "linux-szenario" ja aber nicht (denn selbiges würde killen). Garantiert steht in jeder !linux-Dokumentation "wie dimensioniere ich meinen Server" drin, daß man mindestens 3 mal soviel Swap braucht wie physischen RAM.

Du _kannst_ (im Sinne von "darfst") gerne perfekte Programme erwarten. Es ist Deine Enttäuschung. Meine Erfahrung sagt mir etwas vollkommen anderes über Programme (ja, ich habe auch schon Bugs in ausgetesteten 100-Zeilern gefunden).

Und weil die Programmierer nicht perfekt sind, sollte der Kern die Prozesse voreinander schützen und nicht wahllos killen <PUNKT>

Würde man beim Design des Kernels nicht darauf achten, dass es eine Menge Programmierer gibt, die einfach nur Mist bauen, dann würde das System sehr wacklig dastehen. Das wäre ungefähr so, als würde ein Autofahrer davon ausgehen, dass sich alle anderen korrekt verhalten....

Hä? Der Kern geht davon aus das Prozesse Mist bauen, deshalb sollte es sie voreinander und nicht jeweils vor sich selbst schützen.

du musst nicht unendliche Hardware erfinden, um die Randbedingungen aus dem Weg zu schaffen ("beseitigen" war eigentlich der falsche Begriff) - es reicht die Hardware so zu dimensionieren, dass das System nicht mehr überlastet werden _kann_. Sprich: genug Rechenpower und Speicher, dass der maximale Durchsatz auf der Netzwerkkarte noch nicht die Limits der reagierenden Server erreicht.

Da hast Du recht, so macht man das auch oft, aber nicht immer funktioniert das so. Du hängst Dich zu sehr am Thema Webserver auf.

Also bliebe als Konsequenz: jemand sollte entweder selbst eine Konfiguration für die VM schreiben oder einen Kernel-Entwickler dazu überreden einen weiteren Wert für /proc/sys/vm/overcommit_memory einzuführen: -1. Das Problem daran wird sein, dass dieses Feature viele CPU-Zyklen fressen und den VM-Code komplizieren wird.

Warum nicht zur Compilezeit einstellen, das ich kein Overcommit will, dann frißt das auch keine Zyklen weiter...

Bitte Den langen Text oben zweimal lesen, einen Moment drüber meditieren und dann erst meckern... ;-)

Gruß, Eric

On Tue, Mar 06, 2001 at 08:58:24PM +0100, Konrad Rosenbaum wrote:

Problematisch in OOM-Situationen ist: wie entscheide ich, wer der Böse ist.

Ich dachte wir hätten unter Zustimmung aller erklärt, dass es keine bösen Prozesse im Unix gibt. Ist das jetzt etwa wieder strittig???? Falls ja - klinke ich mich hier aus. Nächstens geht hier die Diskussion wieder los, ob die Erde nun eine Kugel oder eine Scheibe ist. Sorry, aber das geht zu weit.

Reinhard

'nabend/'morgen

...

Moment, meinst Du "Speicherschutz"? Der sorgt dafür, dass Prozess A nicht auf den Speicher von Prozess B kommt. Das löst aber das Problem nicht: der Speicher ist voll.

Ich meine nicht Speicherschutz, sondern ich meine, daß ein Prozeß nicht gekillt werden soll, weil der Speicher alle ist. Wenn ein Prozess läuft und jetzt kommt ein neuer Prozess, der irgend was wildes mit dem Speicher anstellt (ob absichtlich oder nicht spielt keine Rolle), dann besteht die Chance das der erstere Prozess baden geht. Das ist unhaltbar.

...

Problematisch in OOM-Situationen ist: wie entscheide ich, wer der Böse ist.

Was ist ein böser Prozess? Einer der Speicher will? Na so ein schlimmer... ;-)

Du kaufst dir eine 10 Gig SCSI-Festplatte (ein SCSI-Anschluß ist im Gegensatz zu IDE bei teureren Systemen meines Wissens meistens vorhanden). Kosten: So um die 1000,- (großzügig kalkuliet). Für deinen Webserver oder was auch immer hast du allerdings normalerweise soviel Geld ausgegeben, daß dich das bißchen nicht mehr juckt. Dafür hast du aber jetzt 10 Gigabyte Swap zusätzlich zum Einbinden. Wenn dein Server z.B. normalerweise mit 1 Gigabyte RAM läuft, sollte das erstmal für eine Weile reichen.

Genau! Die im Linux anvisierte Situation tritt gar nicht erst ein.

Wesentlich billiger wirds natürlich mit IDE.

Darüber kann man sicher streiten ;-)

...

Das war nur so schön einfach. Jeder andere Server geht auch, nur ist es da meist nicht so schlimm, weil im Intranet kaum jemand mutwillig angreift - der Server muss nicht vollkommen überdimensioniert werden.

Und was ist, wenn bei einem Datenbankserver ein Skript plötzlich durchknallt und einen gigantischen select macht? Speicher alle => schade eigentlich, jetzt darfst du deine Datenbank neu starten. Das war glaub ich auch der Auslöser bei der ersten Diskussion zu diesem thema hier gewesen.

Genau. Außerdem: Speicherlast auf einem Webserver ist nicht proportional zur Netzlast (man "dynamische Inhalte").

...

...

Warum nicht zur Compilezeit einstellen, das ich kein Overcommit will, dann frißt das auch keine Zyklen weiter...

...und wenn der erste Prozess "no overcommit" anfordert fängt der Kern an seine Pages zu zählen...

So hab ich das natürlich nicht gemeint.

...

Kernel-Option ist besser (weil konsistenter und einfacher).

Ich glaub, er hat eine Kerneloption gemeint.

Sondern so.

...

...

Bitte Den langen Text oben zweimal lesen, einen Moment drüber meditieren und dann erst meckern... ;-)

...mecker. ;-)

zurückmecker :)

Ziegenstall?

Gruß, Eric

On Tue, Mar 06, 2001 at 05:54:37PM +0100, Konrad Rosenbaum wrote: Abend!

langsam entwickelt sich das wieder zu einem unserer typischen Kommunikationsprobleme.... ;-)

Ja. Ich versuche allerdings schoh in jedem Posting, alle off topic Dinge zu eliminieren.

[bitte komplett lesen vor dem Antworten]

habe ich

Mein Problem: _Deine_ 99%-Lösung ist eine 40%-Lösung für _mich_ (privat), da ich nicht genug Geld für Speicherriegel für den _Normalfall_ eines fork-OOM-Systems habe (und privat gehe ich nur vom Normalfall aus, da es unkritisch ist, ob mein Privatrechner 10Minuten oder 3 Tage ausfällt). Ein malloc-OOM-System hat den Vorteil, dass es den Speicher effizienter ausnutzt.

Du brauchst nicht mehr Speicher als jetzt. Ich will nochmal kurz zusammenfassen warum: Soviele Seiten, wie innerhalb von kurzer Zeit (sagen wir 10 Sekunden) wirklich genutzt werden, solltest du physisches RAM haben. Anderenfalls gibts nur thrashing. Um ein Zahlenbeispiel zu machen, sage ich jetzt mal, daß das 100MB betrifft.

Bis hierher OK?

Betrachten wir nun den worst case: Die obigen 100 MB gehören alle zu einem Prozess und dieser muss forken. (entweder das Kind will nur HelloWorld ausführen oder aber es will die 100 MB auch nutzen, wir wissen es nicht)

Bis hierher OK?

NichtLinux: um nicht wie Linux zu bescheissen, benötigen wir im Augenblick des forks noch 100 MB mehr für die Kopie des 1. Prozesses. Deshalb rechnet das System beim fork: freierSpeicher=freierSpeicher-100MB falls die 100 MB im swap noch frei sind und erlaubt den fork. (Die Speicherseiten werden natürlich nicht wirklich kopiert). Rechenaufwand quasi 0 Nutzt das Kind seinen Speicher wirklich, gibts pagefault wegden der read-only Seiten und es werden entsprechend Seiten gemappt.

Um ein solches System zu realisieren benötigen wir also (worst case): * soviel RAM, dass die in einer kurzer Zeit aktiven Prozesse alle Platz haben * soviel Swap, dass eine grosser Prozess nochmal darin Platz hat + noch ein bisschen für die vielen schlafenden Prozesse des Systems (getty, sendmail, ...)

Bis hierher OK?

Linux: egal wieviel Platz wir noch haben, der fork wird erlaubt. Vom freien Speicher wird nix abgezogen. Rechenaufwand = 0 Nutz das Kind die Seiten, gibts wie im obigen System Pagefaults und Seiten werden gemappt (falls welche da sind, das wissen wir ja nicht, das wir sie nich reserviert haben wie im obigen System) Bei jeder nei gemappten Seiten wird jetz freierSpeicher=freierSpeicher-eine Seite berechnet. Rechenaufwand quasi null (aber eine Rechnung pro Seite, statt wie oben insgesamt nur eine. Diese Berechnungen spielen aber absolut keine Rolle. Ich nenne sie nur, weil du unten was von "CPU-Zyklen fressen" schreibst und das quatsch ist)

Um ein solches System zu realisieren benötigen wir also (worst case): * soviel RAM, dass die in einer kurzer Zeit aktiven Prozesse alle Platz haben * soviel Swap, dass eine grosser Prozess nochmal darin Platz hat + noch ein bisschen für die vielen schlafenden Prozesse des Systems (getty, sendmail, ...) (wer jetzt den Unterschied zu oben sucht, sucht vergeblich - es gibt keinen)

Soweit OK?

Jetz gehen wir mal vom worst case weg und nehmen an, das der 100MB Prozess nur forkt um ein winziges Progrämmchen zu starten, die 100 MB also selber nicht nutzt. Die Veränderungen gegenüber dem worst case oben sind:

NichtLinux: * keine, ich brauche genausoviel RAM und swap wie im worst case

Linux * keine Änderung beim benötigsten RAM * 100 MB weniger swap werden benötigt

Und genau das wollte ich zeigen. * Ein NichtLinux benötigt die gleiche Menge RAM wie das Linux. * Ein NichtLinux benötigt soviel swap wie Linux im worst case.

Ergebnisse: * Du sparst mit Linux keinen Speicherriegel ein * Wenn du das Linuxsystems ordenlich dimensioniert (d.h. worst case ist als mögliches Szenario erlaubt), benötigst du auch die gleiche Menge swap wie mit dem NichtLinux.

Hinweis: Da der Feld-, Wald- und WiesenPC üblicherweise für die an ihn gestellten Aufgaben völlig überdimensioniert ist, kommst du selten mit deiner Linuxkiste in die worst case Situation. Deshalb haben viele Leute wenig swap mit Linux und es funzt trotzdem. Bewegst du dich Richtung worst case und hast den nötigen swap nicht, werden Prozesse gekillt.

Was lernen wir daraus: Die Linuxspeicherverwaltung bringt mir die Einspaarung von ein paar MB Plattenplatz und kostet mich dafür die Gewissheit, dass meine Prozesse am Leben bleiben dürfen. Die eingesparte Menge Plattenplatz bewegt sich im Bereich von 1-2 x Hauptspeichergröße, also z.B. 2*256 MB = 512 MB und das sind weniger als 10 Deutsche Mark = ca. 2 Bier

Nein, da hab' ich mich etwas falsch ausgedrückt.

Jo, das sehe ich auch so :)

Mathematisch will ich dafür sorgen, dass das Optimum von der einzigen als zuverlässig einstufbaren Komponente bestimmt wird: der Netzwerkkarte (zuverlässig in dem Sinne: wenn sie ausfällt ist das originale Optimierungsproblem eh' uninteressant).

Was interessiert die netzwerkkarte beim design der Speicherverwaltung? Was mache ich, wenn mein Rechner keine Netzwerkkarte hat? Mal wieder off topic. Apropos "zuverlässig einstufbaren Komponente": wenn ich 128 MB RAM im Rechner habe, bin ich mir 100%ig sicher, dass ich 128 MB RAM im Rechner habe. Das ist gaaaaanz zuverlässig und eine gute Basis, um damit rumzurechnen.

Also bliebe als Konsequenz: jemand sollte entweder selbst eine Konfiguration für die VM schreiben

Naja, wer kann das schon. Gescheite fertige Standardalgos benötigt man.

oder einen Kernel-Entwickler dazu überreden einen weiteren Wert für /proc/sys/vm/overcommit_memory einzuführen: -1. Das Problem

gute idee

daran wird sein, dass dieses Feature viele CPU-Zyklen fressen und den VM-Code komplizieren wird.

Nein. Ich habe oben die Unterschiede aufgezeigt. CPU-Zyklen sind kein Thema. FreeBSD ist z.B. keinesfalls langsamer was den Speicher angeht.

Ich glaube das Problem löst sich anders: Da jetzt mehr und mehr Firmen Linux in <buzzword mode> enterprise critical environments </...> einsetzen wollen, werden sie oft genug damit auf die Nase fallen. Wetten, dass man dann den Beschiss in der Speicherverwaltung abstellt oder abstellbar macht.

Reinhard

On Wed Mar 07, 2001 at 18:40:21 +0100, Konrad Rosenbaum wrote:

Hauptsache die geben sich Mühe... (IBM scheint z.B. recht stabil zu arbeiten)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Wo?

Adam

Hi Konrad,

    Konrad (der gerade B.A.f.H. liest)

ich hab den Ausredenkalender von dem Typen. Richtig lustig.

Gruß Tilo

...

...

    Konrad (der gerade B.A.f.H. liest)

TW> ich hab den Ausredenkalender von dem Typen. Richtig lustig.

Auchhabenwill! Wo gibts den? (Man könnte ihn sich natürlich aus den Stories selber rekonstruieren...)

Den konntest Du Dir beim Bastard bestellen. Du hättest nur in der Mailingliste stehen müssen - so wie ich schon seit zwei Jahren. Probiersmal unter http://ausredenkalender.informatik.uni-bremen.de/kalender/ .

Gruß

Tilo

On Wed, Mar 07, 2001 at 07:40:47PM +0100, Adam Lackorzynski wrote:

On Wed Mar 07, 2001 at 18:40:21 +0100, Konrad Rosenbaum wrote:

...

Hauptsache die geben sich Mühe... (IBM scheint z.B. recht stabil zu arbeiten)

                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Wo?

Genial! Auf ein Antwort von dir habe ich bei diesem Satz richtig gelauert :---)

Reinhard

Guten Morgen!

Aha: Mal wieder unser Lieblingsthema. Und wieder kommen die gleichen nicht realisierbaren Ideen wie vor einigen Monaten auf.

On Thu, Feb 22, 2001 at 07:58:16PM +0100, Josef Spillner wrote:

Das mit den beliebigen Prozessen sehe ich mittlerweile auch von dieser Seite her. Rein theoretisch kann man aber hier Abhilfe schaffen, wenn ein root-Daemon (von dem optimistischerweise angenommen wird daß er stabil läuft) alle Prozesse beobachtet und über ihr Verhalten Buch führt. Tanzt einer aus der Reihe wird er gekillt.

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.

Es ist eben gerade der Witz der Sache, das knapper Speicher in unixoiden Systemen ein Problem ist. Du hast nun zwei Möglichkeiten: 1. du schmeisst das komplette Unix-Konzept in die Tonne 2. 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)

1. funktioniert super, verursacht aber einige Probleme an anderen Stellen :) 2. machen alle anderen mir bekannten Unixe außer Linux sehr erfolgreich (ich meine hier Linux bis v2.2, zu v2.4 kann ich mich mangels Ahnung nicht äußern)

Leider ist auch das nicht so einfach:

• Prozessorlast: Dann kann man kein "make" mehr eingeben.
• 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.

Deswegen muß so ein Tool schon im Userspace als Ergänzung laufen, damit man es konfigurieren kann. Meinetwegen erst "allow" und dann "deny", d.h. alles was nicht soll darf auch nicht. Beispiel: order allow,deny allow gimp mem=512M allow gcc1 proc=90% deny the ugly rest

Wie willst du auf einem solchen System in C programmierte Programe sicher ablaufen lassen? Angenommen du rufst eine Funktion auf (return-Adresse und Parameter landen auf dem Stack) wodurch just in diesem Moment eine neue Seite benötigt wird und der Prozess sein mem-Limit überschreitet. Der Prozess würde in dem Moment gekillt ohne daß der Autor des Programms irgendeine Chance hat, diesen Fall abzufangen. => System völlig unbrauchbar

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.

Wenn das Ziel ein *theoretisch sicheres System* sein soll (ich brauche sowas nicht), ist Unix einfach broken by Design. Unix+C wurden aber nicht mit diesem Ziel entwickelt.

Reinhard

On Friday 23 February 2001 09:36, Eric Schaefer wrote:

On Fri, Feb 23, 2001 at 01:01:33AM +0100, Reinhard Foerster wrote:

...

Es ist eben gerade der Witz der Sache, das knapper Speicher in unixoiden Systemen ein Problem ist.

Weiß jemand wie andere Systeme das lösen? (NT, VMS, big iron) Reservespeicher für automatische Heapallok??

NT: AFAIK gar nicht. VMS: nutzt das noch jemand? ;-) big blue iron: die Hauptprozesse (sowas, was auf einem PC Betriebssystem genannt wird) bekommen feste Ressourcen zugewiesen (Partitionen), wie die dann damit umgehen ist ihr Problem. AFAIK nutzen die echten Mainframe-OS's nur so viel Speicher wie vorhanden: einige starten nur Prozesse, die von vornherein beschrieben sind (Programm X wird maximal yMB Speicher verbrauchen).

...

1. funktioniert super, verursacht aber einige Probleme an anderen

Stellen :) 2. machen alle anderen mir bekannten Unixe außer Linux sehr erfolgreich (ich meine hier Linux bis v2.2, zu v2.4 kann ich mich mangels Ahnung nicht äußern)

Wie tun die das? Nur solange Pages ausgeben, wie auch tatsächlich welche das sind? Wenn ja, warum dann "sehr, sehr, sehr selten" und nicht "nie"?

Hat das Problem, dass ein grosses Programm manchmal keine kleinen Programme mehr starten kann: 1. fork() -> schlägt fehl, da nicht genug Speicher für eine komplette Kopie 2. exec() -> hätte den Speicher komplett freigegeben - schade eigentlich.

...

...

Leider ist auch das nicht so einfach:

• Prozessorlast: Dann kann man kein "make" mehr eingeben.

Muß schon ein tollen Makefile sein, damit make selbst echte Last erzeugt.

Wenn das passiert hat man einen Bug in make gefunden. Mir ist es trotz einiger "Exzesse" mit make noch nie gelungen make selbst den Prozessor belasten zu lassen. (Ausnahme: unendlich rekursive Makefiles, aber die belasten eher die Task-Queue als den Prozessor, also bewirken sie eher Last im Kern als im Userspace.)

...

...

• Speicherverbrauch: Dann kann man den gimp keine großen Bilder mehr

öffnen lassen.

So, so, gimp also. Ich glaube, daß sich das Problem am Desktop gar nicht erst stellt, da der Nutzer selbst weiß, was er laufen hat und sich nicht selbst den Speicher unter den Füßen wegziehen lassen wird. Problematisch ist doch eher der Server, auf dem viele, potentiell egoistische, Nutzer drauf rumrödeln.

Hmm, SourceForge funktioniert ganz gut, trotz 16000 Projekten und 125000 Nutzern (offizielle SF-Zahl aus einer Rundmail von heute).

Konrad

On Friday 23 February 2001 20:15, Eric Schaefer wrote:

On Fri, Feb 23, 2001 at 06:41:15PM +0100, Konrad Rosenbaum wrote:

...

Hmm, SourceForge funktioniert ganz gut, trotz 16000 Projekten und 125000 Nutzern (offizielle SF-Zahl aus einer Rundmail von heute).

Was passiert, wenn viele Apachekinder laufen und mehr Speicher ausfassen als da ist und dann plötzlich alle auf Ihre Pages schreiben? Fällt er dann nicht auf die Nase (bzw. beliebige Prozesse)?

da auf solchen Rechnern meist nur Apaches laufen werden sie selbst auf die Nase fallen und unterbrochene Verbindungen haben noch nie eine Katastrophe dargestellt. Auf gut organisierten Sites steht der DB Server übrigens auf einer anderen Kiste als der Webserver...

Außerdem sollte der Admin in solchen Situationen etwas nachforschen: a) es ist eine DOS-Attacke: einzelne Domains am Firewall abblocken, bis es vorbei ist. b) es ist nur etwas stärkerer Betrieb: der Server ist zu klein.

Ein Admin wird normalerweise dafür bezahlt die Unzulänglichkeiten des eingesetzten Systems auszugleichen, also sollte er das auch tun. ;-)

Konrad

On Sat, Feb 24, 2001 at 01:59:00PM +0100, Ulf Lorenz wrote:

...

man copy_on_write man vfork (ich weiß, daß das nicht so schick ist)

In der vfork manpage wird dieser call nicht empfohlen, weil z.B. bei einem Fehlschlagen von exec() das Vehalten undefiniert ist.

Deshalb die Bemerkung in Klammern. Wegen copy-on-write ist fork() aber auch nicht mehr so schlimm. Falls der Childprozess sofort ein exec() macht, ist das recht unteuer (speichertechnisch)...

Gruß, Eric

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:

1. du schmeisst das komplette Unix-Konzept in die Tonne
2. 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

Am Freitag, 23. Februar 2001 01:01 schrieb Reinhard Foerster:

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.

Also verlassen wir mal die Theorie und gehen in die Praxis: ftp://cfml.sourceforge.net/pub/cfml/erwin-0.1pre.tar.gz

So stelle ich mir das vor: Ein Daemon läuft im Hintergrund (der braucht noch nicht mal root-Rechte), und kontrolliert anhand der ihm gegebenen Regeln alle Prozesse, die er unter seinen Fittichen hat. Beispielsweise gibts du ihm HylaFax in die Hand, wenn es mal wieder zuviel Hunger als Speicher hat: Du sagst, 20 MB für das Postscriptgenerierungszeugs, und dann ist Sense. Hält sich Hyla nicht dran, gibt es SIGTERM/SIGKILL zum Nachtisch.

Ein anderes Beispiel wären OpenGL-Programme, die locker (mit <20 Zeilen C realisierbar) das X einfrieren können. Oder ein karchiveur, der sich an bzip2-Dateien verschluckt. Solche Programme haben einen gewissen Bedarf an Speicher, aber man kann auch etwa das Maximum abschätzen.

Sicher hat das nicht unbedingt was mit dem Kernel zu tun, und Programme, die nicht über Erwin gestartet werden betrifft es eh nicht, aber wenn man z.B. /usr/local/memoryleak2.0/bin/memleak als Skript auf .../memleak-bin macht und in das Skript schreibt: #!/bin/sh erwin execute safe mem=10M memleak-bin, dann müßte es klappen.

Den Parser werde ich noch programmieren müssen, aber das Programmskelett ist schon mal da (im Moment ist vieles hart einprogrammiert).

Josef Spillner