Hallo Martin, martin@eisengardt.de schrieb:
Hallo,
Hi.
habe momentan gewaltige Probleme mit dem Serversystem. Anscheinend wird irgendwo (RAM/Festplatte????) der Speicher knapp, die Frage ist aber nur, wo?
Kannst du das anscheinend etwas näher erklären? Sprich, wie drückt sich das Problem aus? Wird der Server einfach nur langsam. Schafft die Festplatte irgendwann mal viel zu viel und hört nicht mehr auf? Können Programme irgendwann nicht mehr gestartet werden?
Ansonsten mal ein paar Tips, vielleicht hilft einer der Hinweise zur Fehlersuche.
Festplattenkapazität: "df -h"
# df -h Dateisystem Größe Benut Verf Ben% Eingehängt auf /dev/sda6 20G 11G 8,0G 58% / udev 3,0G 164K 3,0G 1% /dev /dev/sda7 44G 18G 24G 44% /lw/sda7 /dev/sda1 2,0G 7,9M 2,0G 1% /lw/sda1 /dev/sdc1 50G 18G 33G 36% /lw/ocfs1 /dev/sdd1 35G 822M 32G 3% /lw/iscsi1 # mount /dev/sda6 on / type ext3 (rw,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) udev on /dev type tmpfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/sda7 on /lw/sda7 type ext3 (rw,acl,user_xattr) /dev/sda1 on /lw/sda1 type vfat (rw,noexec,nosuid,nodev,gid=100,umask=0002,utf8=true) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) configfs on /sys/kernel/config type configfs (rw) ocfs2_dlmfs on /dlm type ocfs2_dlmfs (rw) /dev/sdc1 on /lw/ocfs1 type ocfs2 (rw,_netdev,heartbeat=local) /dev/sdd1 on /lw/iscsi1 type ext3 (rw)
Speicher: "free -t"
geht jetzt nicht mehr richtig, weil ich den Server inzwischen neugestartet habe. jetzt: # free -t total used free shared buffers cached Mem: 6220296 5503196 717100 0 289408 4662836 -/+ buffers/cache: 550952 5669344 Swap: 2104472 0 2104472 Total: 8324768 5503196 2821572
CPU-Last:
4:25pm up 23 days 10:29, 2 users, load average: 0.31, 0.40, 0.43 4:55pm up 23 days 10:59, 2 users, load average: 0.35, 0.43, 0.46 5:25pm up 23 days 11:29, 2 users, load average: 0.41, 0.53, 0.49 5:55pm up 23 days 11:59, 2 users, load average: 0.37, 0.54, 0.53 6:25pm up 23 days 12:29, 3 users, load average: 0.55, 0.69, 0.61 -> sieht eigentlich unkritisch aus, oder?
Mal mit "top" die auffälligen Prozesse beobachten bzw. beobachten, wie die CPUs prozentual mit was ausgelastet sind. Dort kann man auch die Prozesse mal nach Speicherverbrauch sortieren und gucken, ob da einer ist, der sich auffällig verhält.
habe ich gemacht und weder mit "P" noch mit "M" etwas außergewöhnliches gefunden
May 15 18:25:23 s2 kernel: Out of memory: kill process 20919 (nagios) score 3827 or a child
Faktisch muss das nicht zwangsläufig bedeuten, dass tatsächlich "out of memory" ist. Wenn dem so ist, dürfte man hoffentlich einen Großverbraucher finden. Ich habs sogar mal erlebt, dass eine Swap-Partition kaputt war und das halt nur derart versteckt war in den messages, dass ich es übersehen
swap ist zwar vorhanden, sollte aber eigentlich nicht groß verwendet werden.
hatte. Immer, wenns dann auf die defekten Sektoren im Swap-Laufwerk stieß, verhielt sich der Kernel etwas daneben und hat Speicheranforderungen abgelehnt, obwohl sogar genug physischer RAM da war. Eventuell kann man auch beim Reboot nochmal gezielt darauf schauen, ob da versucht wird, das Swap-Laufwerk zu reaprieren oder zu deaktivieren.
"dmesg|grep -i swap" ergibt nichts. Auch in "/var/log/messages" ist nach dem Reboot nichts darüber zu finden.
Grüße aus Karlsruhe Martin
Grüße aus Oberösterreich, 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
Günther Zisham schrieb:
Hallo Martin,
martin@eisengardt.de schrieb:
Hallo,
Hi.
habe momentan gewaltige Probleme mit dem Serversystem. Anscheinend wird irgendwo (RAM/Festplatte????) der Speicher knapp, die Frage ist aber nur, wo?
Kannst du das anscheinend etwas näher erklären? Sprich, wie drückt sich das Problem aus? Wird der Server einfach nur langsam. Schafft die Festplatte irgendwann mal viel zu viel und hört nicht mehr auf? Können Programme irgendwann nicht mehr gestartet werden?
Ansonsten mal ein paar Tips, vielleicht hilft einer der Hinweise zur Fehlersuche.
Festplattenkapazität: "df -h"
# df -h Dateisystem Größe Benut Verf Ben% Eingehängt auf /dev/sda6 20G 11G 8,0G 58% / udev 3,0G 164K 3,0G 1% /dev /dev/sda7 44G 18G 24G 44% /lw/sda7 /dev/sda1 2,0G 7,9M 2,0G 1% /lw/sda1 /dev/sdc1 50G 18G 33G 36% /lw/ocfs1 /dev/sdd1 35G 822M 32G 3% /lw/iscsi1
# mount /dev/sda6 on / type ext3 (rw,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) udev on /dev type tmpfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/sda7 on /lw/sda7 type ext3 (rw,acl,user_xattr) /dev/sda1 on /lw/sda1 type vfat (rw,noexec,nosuid,nodev,gid=100,umask=0002,utf8=true) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) configfs on /sys/kernel/config type configfs (rw) ocfs2_dlmfs on /dlm type ocfs2_dlmfs (rw) /dev/sdc1 on /lw/ocfs1 type ocfs2 (rw,_netdev,heartbeat=local) /dev/sdd1 on /lw/iscsi1 type ext3 (rw)
Speicher: "free -t"
geht jetzt nicht mehr richtig, weil ich den Server inzwischen neugestartet habe. jetzt: # free -t total used free shared buffers cached Mem: 6220296 5503196 717100 0 289408 4662836 -/+ buffers/cache: 550952 5669344 Swap: 2104472 0 2104472 Total: 8324768 5503196 2821572
CPU-Last:
4:25pm up 23 days 10:29, 2 users, load average: 0.31, 0.40, 0.43 4:55pm up 23 days 10:59, 2 users, load average: 0.35, 0.43, 0.46 5:25pm up 23 days 11:29, 2 users, load average: 0.41, 0.53, 0.49 5:55pm up 23 days 11:59, 2 users, load average: 0.37, 0.54, 0.53 6:25pm up 23 days 12:29, 3 users, load average: 0.55, 0.69, 0.61 -> sieht eigentlich unkritisch aus, oder?
Mal mit "top" die auffälligen Prozesse beobachten bzw. beobachten, wie die CPUs prozentual mit was ausgelastet sind. Dort kann man auch die Prozesse mal nach Speicherverbrauch sortieren und gucken, ob da einer ist, der sich auffällig verhält.
habe ich gemacht und weder mit "P" noch mit "M" etwas außergewöhnliches gefunden
May 15 18:25:23 s2 kernel: Out of memory: kill process 20919 (nagios) score 3827 or a child
Faktisch muss das nicht zwangsläufig bedeuten, dass tatsächlich "out of memory" ist. Wenn dem so ist, dürfte man hoffentlich einen Großverbraucher finden. Ich habs sogar mal erlebt, dass eine Swap-Partition kaputt war und das halt nur derart versteckt war in den messages, dass ich es übersehen
swap ist zwar vorhanden, sollte aber eigentlich nicht groß verwendet werden.
hatte. Immer, wenns dann auf die defekten Sektoren im Swap-Laufwerk stieß, verhielt sich der Kernel etwas daneben und hat Speicheranforderungen abgelehnt, obwohl sogar genug physischer RAM da war. Eventuell kann man auch beim Reboot nochmal gezielt darauf schauen, ob da versucht wird, das Swap-Laufwerk zu reaprieren oder zu deaktivieren.
"dmesg|grep -i swap" ergibt nichts. Auch in "/var/log/messages" ist nach dem Reboot nichts darüber zu finden.
Grüße aus Karlsruhe Martin
Grüße aus Oberösterreich, Günther
... vielleicht mal mit z.B. ps --sort=-vsize -eo "%p %y %x %z %a" | head -n20 in kurzen Abständen über cron die Speicherbelegung aufzeichnen lassen, dann sieht man evtl. welche Prozesse vor einem kill den Speiche belegen ... mfg Bernward Otto -- 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
Bernward Otto - SuSE-Linux-Liste schrieb:
... vielleicht mal mit z.B.
ps --sort=-vsize -eo "%p %y %x %z %a" | head -n20
in kurzen Abständen über cron die Speicherbelegung aufzeichnen lassen, dann sieht man evtl. welche Prozesse vor einem kill den Speiche belegen ...
mfg Bernward Otto
danke, hab es schon in einen Cron-Job übernommen, der 2x pro Stunde läuft und in eine Datei schreibt. Beim nächsten Auftreten habe ich dann wenigstens Infos drüber. Aber warum waren es verschiedenste Prozesse (mysqld (33 Male), sh (1), amavisd (81), httpd2-prefork (6), nagios (333 Male)) und nicht nur ein bestimmter und warum so oft? Könnte es ein Kernel-Problem sein? mfg 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
Günther Zisham schrieb:
Bernward Otto - SuSE-Linux-Liste schrieb:
... vielleicht mal mit z.B.
ps --sort=-vsize -eo "%p %y %x %z %a" | head -n20
in kurzen Abständen über cron die Speicherbelegung aufzeichnen lassen, dann sieht man evtl. welche Prozesse vor einem kill den Speiche belegen ...
mfg Bernward Otto
danke, hab es schon in einen Cron-Job übernommen, der 2x pro Stunde läuft und in eine Datei schreibt. Beim nächsten Auftreten habe ich dann wenigstens Infos drüber.
Inzwischen ist es leider wieder aufgetreten und ich habe mit obigem Befehl folgendes geloggt: (automatischer Neustart um 10:01) *Fri May 25 15:55:01 CEST 2007* PID TTY TIME VSZ COMMAND 15811 ? 05:11:43 72812 /usr/sbin/named -t /var/lib/named -u named 15960 ? 00:00:04 57408 amavisd (ch6-avail) 16189 ? 00:00:01 54736 amavisd (ch5-avail) 4908 ? 00:00:23 52024 amavisd (master) 1457 ? 00:00:03 49732 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 18347 ? 00:00:05 49728 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 18346 ? 00:00:05 49716 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 18343 ? 00:00:06 49672 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 1450 ? 00:00:03 49608 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 1451 ? 00:00:03 49608 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 1452 ? 00:00:03 49604 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 1929 ? 00:00:03 49600 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 22480 ? 00:00:05 49592 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 18345 ? 00:00:05 49336 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 4934 ? 00:00:03 47732 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 19408 ? 2-13:22:08 40584 (squid) -sYD 4656 ? 00:00:00 35560 /usr/lib/AntiVir/antivir --updater-daemon 5057 ? 00:00:11 32684 /usr/bin/python /usr/bin/hb_gui 4694 ? 00:00:01 27352 /usr/sbin/spamd -d -c -L -r /var/run/spamd.pid *Fri May 25 16:25:01 CEST 2007* PID TTY TIME VSZ COMMAND 4279 ? 00:00:26 247892 ./jre/bin/java -Djava.compiler=NONE -cp /usr/StorMan/RaidMan.jar com.ibm.sysmgt.raidmgr.agent.ManagementAgent 12724 ? 00:00:00 53068 amavisd (ch2-12724-02) 12819 ? 00:00:00 53068 amavisd (ch2-12819-02) 6806 ? 00:00:00 52032 amavisd (master) 7242 ? 00:00:00 49244 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 7243 ? 00:00:00 49244 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 7244 ? 00:00:00 49244 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 7245 ? 00:00:00 49244 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 7246 ? 00:00:00 49244 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 12308 ? 00:00:00 48932 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 6903 ? 00:00:00 47468 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 5181 ? 00:00:00 37880 /usr/lib/AntiVir/antivir --updater-daemon 9864 ? 00:00:02 35756 /usr/sbin/named -t /var/lib/named -u named 5652 ? 00:00:00 27360 /usr/sbin/spamd -d -c -L -r /var/run/spamd.pid 6346 ? 00:00:00 27360 spamd child 6350 ? 00:00:00 27360 spamd child 6521 ? 00:00:00 24564 /usr/bin/python /usr/bin/hb_gui 9731 ? 00:00:07 20088 /usr/local/sbin/nacctd 5684 ? 00:00:00 13724 Xvnc :1 -desktop X -httpd /usr/share/vnc/classes -auth /var/lib/hbuser/.Xauthority -geometry 1024x768 -depth 24 -rfbwait Hilft mir das weiter? Ich sehe nur, dass es nicht wirklich einen großen Prozess vor dem Neustart gegeben hat, aber einen viel größeren danach. ?!? Lg, 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
Günther Zisham schrieb:
(automatischer Neustart um 10:01)
*Fri May 25 15:55:01 CEST 2007* ... *Fri May 25 16:25:01 CEST 2007* ...
ich meinte natürlich: automatischer Neustart um 16:01 (war ein Tippfehler) -- 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
Günther Zisham schrieb:
Günther Zisham schrieb:
Bernward Otto - SuSE-Linux-Liste schrieb:
... vielleicht mal mit z.B.
ps --sort=-vsize -eo "%p %y %x %z %a" | head -n20
in kurzen Abständen über cron die Speicherbelegung aufzeichnen lassen, dann sieht man evtl. welche Prozesse vor einem kill den Speiche belegen ...
mfg Bernward Otto
danke, hab es schon in einen Cron-Job übernommen, der 2x pro Stunde läuft und in eine Datei schreibt. Beim nächsten Auftreten habe ich dann wenigstens Infos drüber.
Inzwischen ist es leider wieder aufgetreten und ich habe mit obigem Befehl folgendes geloggt: (automatischer Neustart um 16:01)
*Fri May 25 15:55:01 CEST 2007* PID TTY TIME VSZ COMMAND 15811 ? 05:11:43 72812 /usr/sbin/named -t /var/lib/named -u named 15960 ? 00:00:04 57408 amavisd (ch6-avail) 16189 ? 00:00:01 54736 amavisd (ch5-avail) 4908 ? 00:00:23 52024 amavisd (master) 1457 ? 00:00:03 49732 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 18347 ? 00:00:05 49728 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 18346 ? 00:00:05 49716 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 18343 ? 00:00:06 49672 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 1450 ? 00:00:03 49608 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 1451 ? 00:00:03 49608 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 1452 ? 00:00:03 49604 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 1929 ? 00:00:03 49600 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 22480 ? 00:00:05 49592 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 18345 ? 00:00:05 49336 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 4934 ? 00:00:03 47732 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 19408 ? 2-13:22:08 40584 (squid) -sYD 4656 ? 00:00:00 35560 /usr/lib/AntiVir/antivir --updater-daemon 5057 ? 00:00:11 32684 /usr/bin/python /usr/bin/hb_gui 4694 ? 00:00:01 27352 /usr/sbin/spamd -d -c -L -r /var/run/spamd.pid
*Fri May 25 16:25:01 CEST 2007* PID TTY TIME VSZ COMMAND 4279 ? 00:00:26 247892 ./jre/bin/java -Djava.compiler=NONE -cp /usr/StorMan/RaidMan.jar com.ibm.sysmgt.raidmgr.agent.ManagementAgent 12724 ? 00:00:00 53068 amavisd (ch2-12724-02) 12819 ? 00:00:00 53068 amavisd (ch2-12819-02) 6806 ? 00:00:00 52032 amavisd (master) 7242 ? 00:00:00 49244 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 7243 ? 00:00:00 49244 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 7244 ? 00:00:00 49244 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 7245 ? 00:00:00 49244 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 7246 ? 00:00:00 49244 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 12308 ? 00:00:00 48932 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 6903 ? 00:00:00 47468 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL 5181 ? 00:00:00 37880 /usr/lib/AntiVir/antivir --updater-daemon 9864 ? 00:00:02 35756 /usr/sbin/named -t /var/lib/named -u named 5652 ? 00:00:00 27360 /usr/sbin/spamd -d -c -L -r /var/run/spamd.pid 6346 ? 00:00:00 27360 spamd child 6350 ? 00:00:00 27360 spamd child 6521 ? 00:00:00 24564 /usr/bin/python /usr/bin/hb_gui 9731 ? 00:00:07 20088 /usr/local/sbin/nacctd 5684 ? 00:00:00 13724 Xvnc :1 -desktop X -httpd /usr/share/vnc/classes -auth /var/lib/hbuser/.Xauthority -geometry 1024x768 -depth 24 -rfbwait
Hilft mir das weiter? Ich sehe nur, dass es nicht wirklich einen großen Prozess vor dem Neustart gegeben hat, aber einen viel größeren danach. ?!?
Lg, Günther
Hab da noch etwas gefunden, mit dem ich nicht recht was anzufangen weiß: in /var/log/messages: May 25 15:41:08 s1 kernel: squid invoked oom-killer: gfp_mask=0xd0, order=0, oomkilladj=0 May 25 15:41:08 s1 kernel: [<c0145660>] out_of_memory+0x69/0x185 May 25 15:41:08 s1 kernel: [<c0146b69>] __alloc_pages+0x20a/0x294 May 25 15:41:08 s1 kernel: [<c02674dd>] tcp_snd_test+0x13/0xce May 25 15:41:08 s1 kernel: [<c025f7f6>] tcp_sendmsg+0x4f7/0x9be May 25 15:41:08 s1 kernel: [<c0116bb5>] find_busiest_group+0x1b4/0x4c5 May 25 15:41:08 s1 kernel: [<c0277429>] inet_sendmsg+0x3b/0x45 May 25 15:41:08 s1 kernel: [<c0233f3a>] sock_aio_write+0xf6/0x102 May 25 15:41:08 s1 kernel: [<c015d5d9>] do_sync_write+0xc7/0x10a May 25 15:41:08 s1 kernel: [<c0255de3>] ip_rcv+0x409/0x442 May 25 15:41:08 s1 kernel: [<c01248ec>] lock_timer_base+0x15/0x2f May 25 15:41:08 s1 kernel: [<c012d181>] autoremove_wake_function+0x0/0x35 May 25 15:41:08 s1 kernel: [<c028df6f>] schedule_timeout+0x79/0x8d May 25 15:41:08 s1 kernel: [<c0233bf4>] sock_poll+0xc/0xe May 25 15:41:08 s1 kernel: [<c015de2c>] vfs_write+0xbc/0x154 May 25 15:41:08 s1 kernel: [<c015e425>] sys_write+0x41/0x67 May 25 15:41:08 s1 kernel: [<c0103d68>] syscall_call+0x7/0xb May 25 15:41:08 s1 kernel: ======================= May 25 15:41:08 s1 kernel: Mem-info: May 25 15:41:08 s1 kernel: DMA per-cpu: May 25 15:41:08 s1 kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 May 25 15:41:08 s1 kernel: CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 May 25 15:41:08 s1 kernel: CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 May 25 15:41:08 s1 kernel: CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 May 25 15:41:08 s1 kernel: CPU 4: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 May 25 15:41:08 s1 kernel: CPU 5: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 May 25 15:41:08 s1 kernel: CPU 6: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 May 25 15:41:08 s1 kernel: CPU 7: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 May 25 15:41:08 s1 kernel: Normal per-cpu: May 25 15:41:08 s1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 160 Cold: hi: 62, btch: 15 usd: 57 May 25 15:41:08 s1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 28 Cold: hi: 62, btch: 15 usd: 51 May 25 15:41:08 s1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 145 Cold: hi: 62, btch: 15 usd: 52 May 25 15:41:08 s1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 29 Cold: hi: 62, btch: 15 usd: 48 May 25 15:41:08 s1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 15 Cold: hi: 62, btch: 15 usd: 55 May 25 15:41:08 s1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 180 Cold: hi: 62, btch: 15 usd: 58 May 25 15:41:08 s1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 52 May 25 15:41:08 s1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 44 Cold: hi: 62, btch: 15 usd: 48 May 25 15:41:08 s1 kernel: HighMem per-cpu: May 25 15:41:08 s1 kernel: CPU 0: Hot: hi: 186, btch: 31 usd: 15 Cold: hi: 62, btch: 15 usd: 4 May 25 15:41:08 s1 kernel: CPU 1: Hot: hi: 186, btch: 31 usd: 74 Cold: hi: 62, btch: 15 usd: 0 May 25 15:41:08 s1 kernel: CPU 2: Hot: hi: 186, btch: 31 usd: 169 Cold: hi: 62, btch: 15 usd: 2 May 25 15:41:08 s1 kernel: CPU 3: Hot: hi: 186, btch: 31 usd: 157 Cold: hi: 62, btch: 15 usd: 10 May 25 15:41:08 s1 kernel: CPU 4: Hot: hi: 186, btch: 31 usd: 14 Cold: hi: 62, btch: 15 usd: 9 May 25 15:41:08 s1 kernel: CPU 5: Hot: hi: 186, btch: 31 usd: 169 Cold: hi: 62, btch: 15 usd: 4 May 25 15:41:08 s1 kernel: CPU 6: Hot: hi: 186, btch: 31 usd: 132 Cold: hi: 62, btch: 15 usd: 0 May 25 15:41:08 s1 kernel: CPU 7: Hot: hi: 186, btch: 31 usd: 10 Cold: hi: 62, btch: 15 usd: 3 May 25 15:41:08 s1 kernel: Active:868588 inactive:460160 dirty:3524 writeback:425 unstable:0 free:12031 slab:206797 mapped:8789 pagetables:1072 May 25 15:41:08 s1 kernel: DMA free:3544kB min:68kB low:84kB high:100kB active:60kB inactive:0kB present:16256kB pages_scanned:90 all_unreclaimable? yes May 25 15:41:08 s1 kernel: lowmem_reserve[]: 0 873 7604 May 25 15:41:08 s1 kernel: Normal free:2936kB min:3744kB low:4680kB high:5616kB active:420kB inactive:596kB present:894080kB pages_scanned:1507 all_unreclaimable? yes May 25 15:41:08 s1 kernel: lowmem_reserve[]: 0 0 53848 May 25 15:41:08 s1 kernel: HighMem free:41644kB min:512kB low:7732kB high:14956kB active:3473872kB inactive:1840044kB present:6892544kB pages_scanned:0 all_unreclaimable? no May 25 15:41:08 s1 kernel: lowmem_reserve[]: 0 0 0 May 25 15:41:08 s1 kernel: DMA: 0*4kB 1*8kB 1*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 0*4096kB = 3544kB May 25 15:41:08 s1 kernel: Normal: 62*4kB 0*8kB 4*16kB 2*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 2936kB May 25 15:41:08 s1 kernel: HighMem: 3751*4kB 662*8kB 132*16kB 357*32kB 18*64kB 14*128kB 9*256kB 5*512kB 0*1024kB 0*2048kB 0*4096kB = 41644kB May 25 15:41:08 s1 kernel: Swap cache: add 4834, delete 3865, find 496082/496293, race 0+3 May 25 15:41:09 s1 kernel: Free swap = 2092932kB May 25 15:41:09 s1 kernel: Total swap = 2104472kB May 25 15:41:09 s1 kernel: Free swap: 2092932kB May 25 15:41:09 s1 kernel: 1966080 pages of RAM May 25 15:41:09 s1 kernel: 1736704 pages of HIGHMEM May 25 15:41:09 s1 kernel: 411006 reserved pages May 25 15:41:09 s1 kernel: 174367 pages shared May 25 15:41:09 s1 kernel: 969 pages swap cached May 25 15:41:09 s1 kernel: 1824 pages dirty May 25 15:41:09 s1 kernel: 425 pages writeback May 25 15:41:09 s1 kernel: 8789 pages mapped May 25 15:41:09 s1 kernel: 206797 pages slab May 25 15:41:09 s1 kernel: 1072 pages pagetables May 25 15:41:09 s1 kernel: Out of memory: kill process 11651 (amavisd) score 18401 or a child May 25 15:41:09 s1 kernel: Killed process 12126 (antivir) Momentan ergibt sich folgendes Bild in "top" (geordnet nach M = memory): Mem: 6220240k total, 6055236k used, 165004k free, 498228k buffers Swap: 2104472k total, 0k used, 2104472k free, 4909440k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 16593 vscan 15 0 60056 49m 2836 S 5 0.8 0:03.16 amavisd 7765 vscan 15 0 52024 42m 2596 S 0 0.7 0:01.88 amavisd 20610 vscan 15 0 52928 41m 1712 S 0 0.7 0:00.00 amavisd 5819 root 18 0 37680 32m 448 S 0 0.5 0:00.00 antivir 21314 squid 15 0 33544 28m 2616 S 4 0.5 87:02.53 squid 12593 named 19 0 58356 27m 2116 S 1 0.5 10:17.22 named 7037 root 15 0 27356 24m 2276 S 0 0.4 0:02.83 spamd 7435 hbuser 18 0 31464 23m 10m S 0 0.4 0:07.01 hb_gui 7762 root 18 0 27356 22m 684 S 0 0.4 0:00.09 spamd 7770 root 18 0 27356 22m 572 S 0 0.4 0:00.12 spamd 6051 hbuser 15 0 17280 13m 4248 S 0 0.2 2:04.77 Xvnc 9160 root -2 0 13212 12m 4120 S 0 0.2 0:14.92 heartbeat 30081 wwwrun 15 0 49484 9068 3716 S 0 0.1 0:01.98 httpd2-prefork 30080 wwwrun 21 0 49484 9064 3704 S 0 0.1 0:01.63 httpd2-prefork 30083 wwwrun 16 0 49484 8944 3672 S 0 0.1 0:01.87 httpd2-prefork 2179 wwwrun 18 0 49484 8928 3656 S 0 0.1 0:01.76 httpd2-prefork 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? In diesem Fall wäre das dann zB wieder amavisd, obwohl der Speicherverbrauch nur bei ca. 0,8 % liegt. Wie kann ich draufkommen, wo wirklich der meiste Speicher "verlorengeht"? (Hardwarefehler kann ich ausschließen, da der Fehler bei 2 verschiedenen Servern mit selber Software auftritt) Danke schon mal für Eure 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
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? 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. Ein Problem der Hardware-Kernel Kombination ist auch nicht auszuschliessen. Cheers, Th. -- 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
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
Günther Zisham wrote:
[...] # /sbin/sysctl -a 2>/dev/null | grep overcommit vm.overcommit_memory = 0 vm.overcommit_ratio = 50
OK, overcommit_memory steht auf 0. Zur Erklaerung: genau wie Fluege ueberbucht werden koennen (um eine moeglichst gute Auslastung zu erzielen), unter der Annahme, dass zum eigentlichen Flugtermin nicht alle Passagiere erscheinen, so kann auch der Speicher "ueberbucht" werden, unter der Annahme, dass nicht alle Prozesse gleichzeitig ihren maximal angeforderten Speicher benoetigen (overcommit_memory=2; in dem Falle kommt dann overcommit_ratio ins Spiel, das gibt quasi die Ueberbuchung vor). In gewissen Faellen kann das fuer eine erhebliche Performance-Verbesserung des Systems sorgen. Allerdings funktioniert das nur mit gewissen Programmen, wie man sich leicht selbst ausmalen kann und fuehrt ansonsten zu erheblichen Problemen (aehnlicher Natur wie auf Deinem System).
[...] 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 glaube, automatisch kann man die Dinge nicht addieren. Spontan haette ich jetzt mal etwas wie ps -eo ppid,rss,vsize,pid,state,cputime,ni,comm --sort rss \ --cumulative | tail -15 verwendet, um zu schauen, was sich auf einem System so tut. Das sortiert erst einmal nach Resident Memory Size. Wenn das nicht den gewuenschten Erfolg bringt, muss man wohl ein wenig experimentieren und ppid oder vsize etc. in das Sortieren mit aufnehmen...
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)
Das ist in der Tat etwas seltsam. Es kann sich theoretisch um ein Hardwareproblem handeln (oder um ein Problem vom Kernel mit der Hardware), oder aber um ein Softwareproblem, wo einfach ein Prozess Amok laeuft. Das Problem ist ein wenig tueckisch. Evtl. hilft experimentieren mit einem anderen Kernel, oder der Ausbau von nicht unbedingt benoetigter Hardware zu Testzwecken, oder das Abschalten der verschiedenen Dienste (mysqld, httpd, amavisd, etc.) zu Testzwecken bis das System stabil ist... Hast Du den Speicher getestet (memtest86) und ist er in Ordnung? Wenn natuerlich ein physikalisches Problem mit dem RAM vorliegt, dann kann alles schief laufen... Gruesse, Th. -- 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
@Thomas Hertweck: sorry for die PM. Hier nochmals an die Liste. Thomas Hertweck schrieb:
Günther Zisham wrote:
[...] # /sbin/sysctl -a 2>/dev/null | grep overcommit vm.overcommit_memory = 0 vm.overcommit_ratio = 50
OK, overcommit_memory steht auf 0.
Zur Erklaerung: genau wie Fluege ueberbucht werden koennen (um eine moeglichst gute Auslastung zu erzielen), unter der Annahme, dass zum eigentlichen Flugtermin nicht alle Passagiere erscheinen, so kann auch der Speicher "ueberbucht" werden, unter der Annahme, dass nicht alle Prozesse gleichzeitig ihren maximal angeforderten Speicher benoetigen (overcommit_memory=2; in dem Falle kommt dann overcommit_ratio ins Spiel, das gibt quasi die Ueberbuchung vor). In gewissen Faellen kann das fuer eine erhebliche Performance-Verbesserung des Systems sorgen. Allerdings funktioniert das nur mit gewissen Programmen, wie man sich leicht selbst ausmalen kann und fuehrt ansonsten zu erheblichen Problemen (aehnlicher Natur wie auf Deinem System).
also dann lasse ich es so...
[...] 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 glaube, automatisch kann man die Dinge nicht addieren. Spontan haette ich jetzt mal etwas wie
ps -eo ppid,rss,vsize,pid,state,cputime,ni,comm --sort rss \ --cumulative | tail -15
ok, läuft ebenfalls als Cron-Job, momentan noch 2 Mal pro Stunde, demnächst alle 5 oder 10 Minuten.
verwendet, um zu schauen, was sich auf einem System so tut. Das sortiert erst einmal nach Resident Memory Size. Wenn das nicht den gewuenschten Erfolg bringt, muss man wohl ein wenig experimentieren und ppid oder vsize etc. in das Sortieren mit aufnehmen...
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)
Das ist in der Tat etwas seltsam. Es kann sich theoretisch um ein Hardwareproblem handeln (oder um ein Problem vom Kernel mit der Hardware), oder aber um ein Softwareproblem, wo einfach ein Prozess Amok laeuft. Das Problem ist ein wenig tueckisch. Evtl. hilft experimentieren mit einem anderen Kernel, oder der Ausbau von nicht unbedingt benoetigter Hardware zu Testzwecken, oder das Abschalten der verschiedenen Dienste (mysqld, httpd, amavisd, etc.) zu Testzwecken bis das System stabil ist...
mysqld läuft nur am 2. Server. amavisd+postfix wird eigentlich nur am 1. Server von außen angesprochen und läuft am 2. Server eigentlich im Leerlauf.
Hast Du den Speicher getestet (memtest86) und ist er in Ordnung? Wenn natuerlich ein physikalisches Problem mit dem RAM vorliegt, dann kann alles schief laufen...
Speicher: der müßte dann auf beiden Servern defekt sein (Fehler trat inzwischen je ein Mal auf beiden Servern auf) Habe auch (wie erwähnt) schon von Kernel 2.6.20.4 auf 2.6.21.3 gewechselt, aber mit dem selben einen Patch und mit der selben Kernel-Konfiguration. Werde das auch mal wechseln. Auch den Original-Suse-Kernel habe ich noch drauf. Werde da mal etwas variieren. Ach, bevor ich's vergesse: Damit der Rechner mit den 3 Gigabit-Netzwerkkarten funktioniert, brauche ich als weiteren Start-Parameter: memmap=256M$2560M Sonst fährt er nicht mehr vollständig herunter, kann auch keinen Neustart mehr machen und geht auf "schwerwiegenden Hardwarefehler". Mit diesem Parameter (wurde mir vom Serverhersteller empfohlen) sieht's dann aber normal aus. Könnte der Kernel mit diesem Parameter ein Problem haben? Besten Dank, 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
Günther Zisham wrote:
[...] Ach, bevor ich's vergesse: Damit der Rechner mit den 3 Gigabit-Netzwerkkarten funktioniert, brauche ich als weiteren Start-Parameter: memmap=256M$2560M Sonst fährt er nicht mehr vollständig herunter, kann auch keinen Neustart mehr machen und geht auf "schwerwiegenden Hardwarefehler". Mit diesem Parameter (wurde mir vom Serverhersteller empfohlen) sieht's dann aber normal aus. Könnte der Kernel mit diesem Parameter ein Problem haben?
Oh, der Parameter koennte im Prinzip mit Deinem Problem zu tun haben, schliesslich geht es hier um das Memory Mapping. Der Bereich von 2560MB bis (2560+256)MB wird bei Dir als "reserved" markiert, d.h. er steht der generellen Speicherverwaltung von Linux nicht zur Verfuegung. Ich nehme an, dass dieser Bereich etwas mit Deinen Netzwerkkarten zu tun hat, PCI-Mapping o.ae. Generell muss ich da aber passen, da sollte jemand ran, der sich genau mit Memory Mapping auskennt. Any volunteers? Zu Testzwecken kannst Du aber ja mal mit einer anderen Hardwarekombi booten (sprich: andere Netzwerkkarte) und den Parameter weglassen und dann schauen, wie sich das System verhaelt. Sorry, mehr faellt mir dazu heute Abend glaube ich nicht mehr ein... Cheers, Th. -- 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
Thomas Hertweck schrieb:
Günther Zisham wrote:
[...] Ach, bevor ich's vergesse: Damit der Rechner mit den 3 Gigabit-Netzwerkkarten funktioniert, brauche ich als weiteren Start-Parameter: memmap=256M$2560M Sonst fährt er nicht mehr vollständig herunter, kann auch keinen Neustart mehr machen und geht auf "schwerwiegenden Hardwarefehler". Mit diesem Parameter (wurde mir vom Serverhersteller empfohlen) sieht's dann aber normal aus. Könnte der Kernel mit diesem Parameter ein Problem haben?
Oh, der Parameter koennte im Prinzip mit Deinem Problem zu tun haben, schliesslich geht es hier um das Memory Mapping. Der Bereich von 2560MB bis (2560+256)MB wird bei Dir als "reserved" markiert, d.h. er steht der generellen Speicherverwaltung von Linux nicht zur Verfuegung. Ich nehme an, dass dieser Bereich etwas mit Deinen Netzwerkkarten zu tun hat, PCI-Mapping o.ae. Generell muss ich da aber passen, da sollte jemand ran, der sich genau mit Memory Mapping auskennt. Any volunteers?
Zu Testzwecken kannst Du aber ja mal mit einer anderen Hardwarekombi booten (sprich: andere Netzwerkkarte) und den Parameter weglassen und dann schauen, wie sich das System verhaelt. Sorry, mehr faellt mir dazu heute Abend glaube ich nicht mehr ein...
naja, Netzwerkkarte 1 und 2 sind onboard (HP, e1000-Kernel-Modul). Hatte zuerst als 3. Netzwerkkarte ebenfalls eine HP des selben Typs im Einsatz. Habe es dann geändert (weil ich dachte, die Netzwerkkarte sei daran schuld) und diese Netzwerkkarte (Broadcom Corporation NetXtreme BCM5703, Kernel-Modul tg3) eingebaut. Erst dann habe ich diesen Bootparameter angehängt. Mit 100MBit-Netzwerkkarten brauche ich diesen Parameter nicht. Nur ist dieses Interface halt die Verbindung zum SAN! Grüße, 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
participants (3)
-
Bernward Otto - SuSE-Linux-Liste -
Günther Zisham -
Thomas Hertweck