moin,
kann mir jemand erklären, warum der kernel, wenn er 'out of memory' geht, nicht den prozess killt, der am groessten ist, sondern irgend einen anderen? hintergrund: ich habe einen offensichtlich nicht sehr optimalen sql select an mysql übergeben, von dem es sich nicht mehr erholt hat.
Jun 25 19:10:55 inspiron kernel: VM: killing process rpc.nfsd
die tabelle (67mb) war dabei etwa so gross wie swap (64mb). die kiste hat 32mb physisches ram.
andre
On Sun, Jun 25, 2000 at 08:35:37PM +0200, Andre Schulze wrote:
kann mir jemand erklaeren, warum der kernel, wenn er 'out of memory' geht, nicht den prozess killt, der am groessten ist, sondern irgend einen anderen?
$ help ulimit
Torsten
On Mon, Jun 26, 2000 at 08:34:51AM +0200, Torsten Werner wrote:
On Sun, Jun 25, 2000 at 08:35:37PM +0200, Andre Schulze wrote:
kann mir jemand erklaeren, warum der kernel, wenn er 'out of memory' geht, nicht den prozess killt, der am groessten ist, sondern irgend einen anderen?
$ help ulimit
Davon wird der Speicher auch nicht groesser und die Killstrategie des Kernels nicht beeinflusst.
Reinhard
On Mon, Jun 26, 2000 at 12:20:35PM +0200, Reinhard Foerster wrote:
On Mon, Jun 26, 2000 at 08:34:51AM +0200, Torsten Werner wrote:
$ help ulimit
Davon wird der Speicher auch nicht groesser und die Killstrategie des Kernels nicht beeinflusst.
Ich weiss ja nicht, was Du fuer einen Kernel benutzt, aber meiner macht folgendes:
~$ ulimit -d 10 ~$ ls ls: Memory exhausted ~$
Das ist sicher nicht der Weisheit letzter Schluss, aber in vielen Faellen ausreichend, um beispielsweise wildlaufende netscapes oder aehnliche Sachen im Zaum zu halten und zu verhindern, dass ein wichtiger nfsd abstuerzt. Ein grober Fehler der ueblichen Distributionen ist es ausserdem, dass ein abgestuerzter Daemon meist nicht automatisch erneut gestartet wird. Etwas Rumspielen mit inetd.conf und inittab kann das beheben. Ein genereller Mechanismus waere aber schoener. Dieser koennte auch dafuer sorgen, dass weniger wichtige Speicherfresser beendet werden, bevor der Daemon erneut gestartet wird.
Torsten
On Mon, Jun 26, 2000 at 01:06:23PM +0200, Torsten Werner wrote:
On Mon, Jun 26, 2000 at 12:20:35PM +0200, Reinhard Foerster wrote:
On Mon, Jun 26, 2000 at 08:34:51AM +0200, Torsten Werner wrote:
$ help ulimit
Davon wird der Speicher auch nicht groesser und die Killstrategie des Kernels nicht beeinflusst.
Ich weiss ja nicht, was Du fuer einen Kernel benutzt, aber meiner macht folgendes:
~$ 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.
Das ist sicher nicht der Weisheit letzter Schluss, aber in vielen Faellen ausreichend, um beispielsweise wildlaufende netscapes oder aehnliche Sachen im Zaum zu halten und zu verhindern, dass ein wichtiger nfsd abstuerzt.
OK, als fast hack brauchbar.
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. Es ist also eine 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.
Andre: Was fuer ein Kenrel war es bei dir 2.0 oder 2.2 ?
Reinhard
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
On Mon, Jun 26, 2000 at 02:38:03PM +0200, Andre Schulze wrote:
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.
Finde ich auch.
nun ja, das muesste man testen. leider ist die bsd kiste (apollo) im moment so ziemlich disfunktional (top kaputt wegen einem VM problem).
Ich kenne das Problem unter Linux auch nur auf schwachbruestigen Rechnern (Datenbank und NFS-Server gleichzeitig auf ueberforderter Hardware). Auf Hardware, die der Aufgabe angepasst ist, habe ich unter Linux selbst ohne ulimit bisher keine Sorgen gehabt.
Torsten
On Sun, Jun 25, 2000 at 08:35:37PM +0200, Andre Schulze wrote:
kann mir jemand erklären, warum der kernel, wenn er 'out of memory' geht, nicht den prozess killt, der am groessten ist, sondern irgend einen anderen?
Die Strategie, den groessten abzuschiessen, waere oft genauso doof. Auf einem Server mit einem grossen inn oder squid im Produktionsberieb waere ein gekillter dnetc noch zu verschmerzen, oder :) Es war mal so, dass genau der Prozess gekillt wurde, der den Speicher haben wollte als dieser ausging. Keine Ahnung, welche Strategie aktuelle Kernel da haben. Ware interessant, sich das mal wieder anzuschauen.
hintergrund: ich habe einen offensichtlich nicht sehr optimalen sql select an mysql übergeben, von dem es sich nicht mehr erholt hat.
Jun 25 19:10:55 inspiron kernel: VM: killing process rpc.nfsd
die tabelle (67mb) war dabei etwa so gross wie swap (64mb). die kiste hat 32mb physisches ram.
Wieviel Pfennige haben dich die 64MB Swap gekostet? ... Es scheint noch keine sinnvoll funktionierende Lösung fuer diese Problem zu geben, die nicht massenhaft swap benötigt oder pessimistisch bei jedem fork() schon ein ENOMEM liefert, wenn der doppelte Platz fuer den Prozess nicht da ist.
Reinhard
Hallo!
Das Hauptproblem ist doch, daß vfork abgeschafft wurde. Das war eben für die Fälle verantwortlich, in denen fork() ein exec() folgen soll und hat den Speicher nicht wirklich belegt, wie es fork() heutzutage tut...
Linux man vfork:
BUGS Under Linux, vfork is merely an alias for fork.
Aha.
Gruß, Eric
Das Hauptproblem ist doch, daß vfork abgeschafft wurde. Das war eben für die Fälle verantwortlich, in denen fork() ein exec() folgen soll und hat den Speicher nicht wirklich belegt, wie es fork() heutzutage tut...
Da fork() in Linux nicht den Speicher physisch kopiert, sondern intensiv von Copy-On-Write gebrauch macht, wie es vfork() vorsieht, besteht effektiv kein Unterschied zwischen fork() und vfork(). Daher ist es auch logisch, dass vfork() als Synonym fuer fork() verwendet wird. vfork() war als Kruecke fuer aeltere UN*Xe erfunden worden...
jens
lug-dd@mailman.schlittermann.de
-
Andre Schulze -
Andre Schulze -
Eric Schaefer -
Jens Nerche -
Reinhard Foerster -
Torsten Werner