Am Mon den 26 Jun 2000 um 01:56:39PM +0200 schrieb Reinhard Foerster:
~$ ulimit -d 10 ~$ ls ls: Memory exhausted ~$
Schon klar. Nur ist das keine Lösung fuer Andres Problem. Du muesstest fuer alle gleichzeitig laufenden Programme ein Limit vergeben und in der Summe der Limits unter Mem+Swap bleiben.
da ich davon ausgehe, dass der mysql server nur bei sinnlosen selects gigantisch wird, ist ein ulimit fuer _diesen_ prozess schon ok, zumal sonst keine speicherfresser auf der kiste am werk sind. gewundert hat mich nur eben das verhalten des kernels, wie ich ein festfahren der kiste letztenendes verhindere (ob kernel oder user level tool) ist mir egal.
OK, als fast hack brauchbar.
bei einem limit von 50mb ist dies schon ein brauchbarer hack.
Ein grober Fehler der ueblichen Distributionen ist es ausserdem, dass ein abgestuerzter Daemon meist nicht automatisch erneut gestartet wird.
Sehe ich völlig anders. Wenn ich ein korrektes Programm (was bei Miniprogrammen möglich sein sollte) starte, will ich davon ausgehen koennen, das dieses so lange laeuft, bis es sich beendet oder auf Wunsch von aussen beendet wird. Der Kernel *darf* es einfach nicht von sich aus killen denke ich. Dann muss ich diesen Fall auch nicht durch start per initab o.ae. behandeln.
das spricht doch dafuer, dass sich ein user level programm um einen mechanismus zur begrenzung der ressourcen kuemmert. dies waehre z.b. ulimit. ein limit fuer die gesamtsumme des speicherverbrauchs dagegen kann der kernel selber am besten verwalten.
Es ist also ein Fehler des Kernels (oder evtl. des Speicherwaltungskonzepts von Unixen), wenn er die Prozesse auf die Art killt, wie Andre geschrieben hat. Komischerweise passiert das bei andern Unixen so selten bis fast nie, das dieser Prozesskilleffekt ausserhalb von Linux eingentlich unbekannt ist. Es geht also auch anders.
nun ja, das muesste man testen. leider ist die bsd kiste (apollo) im moment so ziemlich disfunktional (top kaputt wegen einem VM problem).
Andre: Was fuer ein Kenrel war es bei dir 2.0 oder 2.2 ?
2.2.14
ich versuche heute abend mal mysql auf meiner indigo2 zu kompilieren und dort den fehler reproduzieren. mal sehen was dort passiert.
andre