Hallo Thomas, danke für Deine Hilfe. Thomas Hertweck schrieb:
Günther Zisham wrote:
[...] könnte es sein, dass der Kernel selbst nicht weiß, wer wirklich den Speicher verbraucht und einfach jene Prozesse schießt, von denen er glaubt, dass sie den meisten Speicher verbrauchen?
Der oomkiller basiert auf eine Heuristik. Jedem Prozess wird ein Wert zugeordnet ("badness"), der auf folgenden Kriterien beruht:
a) der beanspruchte virtuelle Speicher sowie der virtuelle Speicher von Child-Prozessen, b) der Task-Prioritaet, c) der gesamten Laufzeit des Prozesses, d) ob es sich bei dem Prozess um einen Superuser-Prozess handelt (das verringert natuerlich den Wert von "badness"), und e) ob es sich bei dem Prozess um eine direkte Hardware-I/O handelt.
Gewisse Prozesse wie swapper oder init sind generell tabu. Der Prozess mit dem hoechsten "badness" Wert gewinnt und wird durch den oomkiller beendet. Im Prinzip bedeutet die Heuristik, dass hpts. kurz laufende Prozesse, die viel Speicher beanspruchen, gekillt werden.
Die Heuristik ist sicherlich nicht perfekt, aber sie erlaubt in kurzer Zeit zu entscheiden, was passieren soll.
Was sagt denn $> /sbin/sysctl -a 2>/dev/null | grep overcommit bei Dir?
# /sbin/sysctl -a 2>/dev/null | grep overcommit vm.overcommit_memory = 0 vm.overcommit_ratio = 50
Fuer den oomkiller ist, wie oben angedeutet, hpts. der gesamte von einem Prozess (und dessen Child-Prozessen) beanspruchte virtuelle Speicher interessant, entsprechend solltest Du Deine Prozessliste danach sortieren. Alle halbe Stunde zu loggen halte ich fuer nicht ausreichend. Wenn ein Prozess Amok laeuft, kann das innerhalb sehr kurzer Zeit passieren.
wie sortiere ich es am besten nach Prozess+Childprozesse (per Command-Line, damit ich es in ein Log bekomme)? so? ps --sort=ppid -eo "%p %P %y %x %z %a" ich verstehe nur nicht, warum es dann wochenlang problemlos funktioniert und dann innerhalb von 2 Stunden mehrmals zu diesem Problem kommt. Bei diesem Server war es 17x Amavis innerhalb von 2 Stunden. Beim anderen Server waren es 10 Tage davor allerhand andere Prozesse (innerhalb von 24 Stunden): mysqld (33 Male), sh (1 Mal), amavisd (81 Male), httpd2-prefork (6 Male), nagios (333 Male)
Ein Problem der Hardware-Kernel Kombination ist auch nicht auszuschliessen.
Wie könnte ich das eingrenzen? Ich verwende den Vanilla-Kernel und außerdem nur noch einen ipmisensors-Patch. An Hardware verwende ich einen Adaptec-SAS-Raid-Controller, 2 HP-Gigabit-Karten, 1 Broadcom NetXtreme-Gigabit-Karte Im Detail: 00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller Hub (rev b1) 00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 2-3 (rev b1) 00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 3 (rev b1) 00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 4-5 (rev b1) 00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 5 (rev b1) 00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 6-7 (rev b1) 00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x4 Port 7 (rev b1) 00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA Engine (rev b1) 00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1) 00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1) 00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB Registers (rev b1) 00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1) 00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1) 00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1) 00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1) 00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09) 00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09) 00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09) 00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09) 00:1d.3 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 (rev 09) 00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9) 00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09) 00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller (rev 09) 00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09) 01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01) 01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01) 02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01) 02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E3 (rev 01) 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01) 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01) 05:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703 Gigabit Ethernet (rev 10) 0b:00.0 PCI bridge: Intel Corporation 80333 Segment-A PCI Express-to-PCI Express Bridge 0b:00.2 PCI bridge: Intel Corporation 80333 Segment-B PCI Express-to-PCI Express Bridge 0c:0e.0 RAID bus controller: Adaptec AAC-RAID 0e:0c.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
Cheers, Th.
Danke für Deine Hilfe, Günther -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org