hohe load average woher ?
Hi, ich habe hier ein SLES 11 SP3 System, das ich erst vor kurzem installiert habe: 64bit Kernel 3.0.93-0.8-default, 8 Kerne, 72GB RAM. Auf dem System läuft fast nichts. Trotzdem habe ich eine load average von ca. 9, sie steigt auch langsam an: ================================================================= top - 16:21:39 up 108 days, 22:02, 3 users, load average: 9.18, 9.18, 8.90 Tasks: 219 total, 2 running, 216 sleeping, 0 stopped, 1 zombie Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 99.3%id, 0.7%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 2.7%us, 0.0%sy, 0.0%ni, 97.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 0.0%us, 1.3%sy, 0.0%ni, 96.7%id, 2.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 2.3%us, 0.3%sy, 0.0%ni, 97.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 0.0%us, 0.7%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 72498M total, 72238M used, 260M free, 185M buffers Swap: 2046M total, 84M used, 1962M free, 70689M cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2705 root 20 0 11232 1620 668 S 2 0.0 0:00.07 lsusb 12586 root 20 0 417m 21m 13m S 1 0.0 411:43.62 knotify4 2325 root 20 0 9028 1316 908 R 1 0.0 0:00.16 top 4868 root 20 0 8364 4416 228 S 0 0.0 59:22.23 haveged ... =================================================================== Die Kerne haben nix zu tun und auf IO wird auch nicht gewartet. Lt. iotop passiert auch nix. Wie man sieht, habe ich einen Zombie: ================================================================ sunhb58820:~ # ps aux|grep Z USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 4763 0.0 0.0 4536 556 pts/5 S+ 16:26 0:00 grep Z root 6146 0.0 0.0 0 0 ? Z Jun23 0:10 [kwin] <defunct> =============================================================== Weiß einer was der kwin macht ? Das ist doch ein kernelthread, oder ? Beim googeln habe ich immer nur Treffer auf den Fenstermanager kwin gefunden. Ist das der ? Obwohl mein System im runlevel 3 läuft ? Ich verbinde mich allerdings manchmal mit dem host per X2go und starte dann z.B. den virt-manager. Es läuft aber keine VM im Moment. Was mich auch noch wundert, ist das immer wieder in top der Prozess lsusb auftaucht, mit 1-2% Last. Und es ist immer wieder ein neuer Prozess, der hat jedes Mal eine andere PID. Noch was interessantes: setze ich ein df -h ab (per ssh), bekomme ich von diesem Programm keine Antwort, es hängt einfach. Der Prozess fällt in "uninterruptable sleep", wartet also wohl auf IO. Gleiches mit lsof: ========================================================== sunhb58820:~ # top: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 30711 root 20 0 11100 1164 556 R 2 0.0 0:00.06 lsusb -s 4 28581 root 20 0 9032 1228 828 R 1 0.0 0:00.93 top 979 root 20 0 8616 140 0 D 0 0.0 0:00.00 lsof 6221 root 20 0 28340 1304 1004 D 0 0.0 65:20.76 cmahostd -p 15 -s OK -l /var/log/hp-snmp-agents/cma.log 9222 root 20 0 4324 724 620 D 0 0.0 0:00.00 df -h 11187 root 20 0 11300 1056 844 D 0 0.0 0:00.00 sh -c /usr/lib/x2go/x2golistsessions_sql sunhb58820 2>/dev/null 14938 root 20 0 899m 104m 14m D 0 0.1 761:56.15 python /usr/share/virt-manager/virt-manager.py 19808 root 20 0 4324 716 620 D 0 0.0 0:00.00 df -h 20013 root 20 0 422m 42m 11m D 0 0.1 0:00.62 python /usr/share/virt-manager/virt-manager.py 22803 root 20 0 4324 720 620 D 0 0.0 0:00.00 df -h 23315 root 20 0 4324 720 620 D 0 0.0 0:00.00 df -h 27168 root 20 0 8616 148 0 D 0 0.0 0:00.00 lsof 28497 root 20 0 4324 720 620 D 0 0.0 0:00.00 df -h ========================================================= Prozess 14938 hat eine wahnsinnig hohe Laufzeit. Ich finde weder in dmesg noch in /var/log/messages etwas erhellendes. Was macht der thread kwin ? Wieso wartet "df" auf IO, obwohl da lt. iotop keine Last ist ? Wo kommt die hohe load average her ? Diese ist übrigens beim Schreiben der e-mail schon angestiegen: top - 17:25:37 up 108 days, 23:06, 3 users, load average: 12.76, 12.40, 11.46 Any idea ? Bernd P.S. Ich hatte sowas ähnliches schon einmal vor ein paar Monaten. Ein Reboot hat das Problem scheinbar gelöst, aber es taucht dann wohl wieder auf. Ich wollte eigentlich auf das System demnächst ein paar VM's legen, für den Betrieb :-(. Ich lasse jetzt mal atop mit laufen und logge jede Sekunde. -- Bernd Lentes Systemadministration Institut für Entwicklungsgenetik Gebäude 35.34 - Raum 208 HelmholtzZentrum münchen bernd.lentes@helmholtz-muenchen.de phone: +49 89 3187 1241 fax: +49 89 3187 2294 http://www.helmholtz-muenchen.de/idg Die Freiheit wird nicht durch weniger Freiheit verteidigt Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess, Dr. Nikolaus Blum, Dr. Alfons Enhsen Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 5. September 2014 17:33 schrieb Lentes, Bernd <bernd.lentes@helmholtz-muenchen.de>:
Das ist die Load. Vermutung: Irgendein Dateisystem hängt. https://en.wikipedia.org/wiki/Load_(computing)#Unix-style_load_calculation Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Martin schrieb:
Hallo Martin, das ist ein guter link. Danke. Ich wußte nicht daß die mit State "D" auch dazugerechnet werden. Ich werde jetzt mal nach und nach alles umounten, und dann schauen wir mal. Bernd Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess, Dr. Nikolaus Blum, Dr. Alfons Enhsen Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671
Bernd schrieb:
Hi, ich kann zwei Mounts auf einen CIFS-NAS nicht umounten: sunxxxxx:~ # umount /mnt/idg umount: /mnt/idg: device is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) sunxxxxx:~ # umount /mnt/idg-2 umount: /mnt/idg-2: device is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) Hab ich eine Chance die Prozesse rauszukriegen ? lsof und fuser hängen sich auf. Bernd Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess, Dr. Nikolaus Blum, Dr. Alfons Enhsen Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671
Hallo, Am Fri, 05 Sep 2014, Lentes, Bernd schrieb:
D ist gerade das "uninterruptible sleep", sprich "Warten auf Godot^WI/O". Da der jew. Prozess aber eben "wartet", zählt's als load.
Ist das ne Linux-Kiste (wg. Hostnamen sun*)? Wenn ja, probiere in nem extra xterm/tty (weil sich's vermutlich auch im "D" aufhängt) mal den Holzhammer: ls -l /proc/*/fd/ | grep mnt/idg Helfen tut übrigens generell nur warten bis ein Timeout (hier von CIFS) zuschlägt oder ein reboot (wobei sich das FS auf dem die hängenden Mounts liegen wohl auch nicht sauber umounten lassen wird. Du solltest die Konfig der CIFS-Mounts prüfen und ggfs. auch die FS der sun* Kiste... HTH, -dnh -- Als man ihnen sage, sie hätten schon eine FW auf Linux Basis, sagten sie, das kann man doch nicht machen, das sei doch Open Source, da könnte jeder Hacker sofort einbrechen, weil er ja den die Sourcen kennt... -- Arne-Erik Martin plaudert in suse-linux aus dem Naehkaestchen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
David schrieb:
Hallo David, ich habe das mal ein wenig abgeändert: sunhb58820:~ # find /proc -iname '*3*' -type l -lname '*mnt*' -exec ls -la {} \; lr-x------ 1 root root 64 Sep 7 14:49 /proc/26863/task/26863/fd/3 -> /mnt lr-x------ 1 root root 64 Sep 7 14:47 /proc/26863/fd/3 -> /mnt Was sagt mir das jetzt ? Prozess 26863 ist folgendes: sunhb58820:~ # ps aux|grep -i 26863 root 22360 0.0 0.0 4532 824 pts/14 S+ 15:02 0:00 grep -i 26863 root 26863 0.0 0.0 19492 1052 ? D Sep05 0:00 ls -A -N --color=tty -T 0 -alF /mnt/ Das ist ein ls, das sich aufgehangen hat. Im Zustand "D" kann ich den nicht abschießen. Bernd Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess, Dr. Nikolaus Blum, Dr. Alfons Enhsen Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Sun, 07 Sep 2014, Lentes, Bernd schrieb:
Daß PID 26863 /mnt/ als/mit dem Filedescriptor 3 offen hat (vermutlich via 'int fd = open(...); + DIR *d = fdopendir(fd);').
Jap. Da hilft nur ein Timeout oder ein reboot. Wobei du vorher noch mit 'umount -f' und trennen des Netzes und restart des exportierenden Serverprozesses testen kannst. Ich kenn das aber nur von NFS (z.B. wenn ich "ausversehen" den Fileserver runterfahre ohne die FS vorher am Client zu unmounten ;) Irgendwie[tm] kann man das dazu bekommen sich zu berappeln. Manchmal zumindest. Wie das bei CIFS ist weiß ich nicht (dürfte auch vom Server abhängen). Du mußt letztlich abwägen, was praktikabler ist: auf den Timeout hoffen/warten oder doch rebooten ... Dabei am besten vorher möglichst viel unmounten, / ro remounten, ggfs. per sysrq ... -dnh -- A common mistake that people make, when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -- Douglas Adams - Mostly Harmless -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 5. September 2014 17:33 schrieb Lentes, Bernd <bernd.lentes@helmholtz-muenchen.de>:
Das ist die Load. Vermutung: Irgendein Dateisystem hängt. https://en.wikipedia.org/wiki/Load_(computing)#Unix-style_load_calculation Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Martin schrieb:
Hallo Martin, das ist ein guter link. Danke. Ich wußte nicht daß die mit State "D" auch dazugerechnet werden. Ich werde jetzt mal nach und nach alles umounten, und dann schauen wir mal. Bernd Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess, Dr. Nikolaus Blum, Dr. Alfons Enhsen Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671
Bernd schrieb:
Hi, ich kann zwei Mounts auf einen CIFS-NAS nicht umounten: sunxxxxx:~ # umount /mnt/idg umount: /mnt/idg: device is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) sunxxxxx:~ # umount /mnt/idg-2 umount: /mnt/idg-2: device is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) Hab ich eine Chance die Prozesse rauszukriegen ? lsof und fuser hängen sich auf. Bernd Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess, Dr. Nikolaus Blum, Dr. Alfons Enhsen Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671
Hallo, Am Fri, 05 Sep 2014, Lentes, Bernd schrieb:
D ist gerade das "uninterruptible sleep", sprich "Warten auf Godot^WI/O". Da der jew. Prozess aber eben "wartet", zählt's als load.
Ist das ne Linux-Kiste (wg. Hostnamen sun*)? Wenn ja, probiere in nem extra xterm/tty (weil sich's vermutlich auch im "D" aufhängt) mal den Holzhammer: ls -l /proc/*/fd/ | grep mnt/idg Helfen tut übrigens generell nur warten bis ein Timeout (hier von CIFS) zuschlägt oder ein reboot (wobei sich das FS auf dem die hängenden Mounts liegen wohl auch nicht sauber umounten lassen wird. Du solltest die Konfig der CIFS-Mounts prüfen und ggfs. auch die FS der sun* Kiste... HTH, -dnh -- Als man ihnen sage, sie hätten schon eine FW auf Linux Basis, sagten sie, das kann man doch nicht machen, das sei doch Open Source, da könnte jeder Hacker sofort einbrechen, weil er ja den die Sourcen kennt... -- Arne-Erik Martin plaudert in suse-linux aus dem Naehkaestchen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
David schrieb:
Hallo David, ich habe das mal ein wenig abgeändert: sunhb58820:~ # find /proc -iname '*3*' -type l -lname '*mnt*' -exec ls -la {} \; lr-x------ 1 root root 64 Sep 7 14:49 /proc/26863/task/26863/fd/3 -> /mnt lr-x------ 1 root root 64 Sep 7 14:47 /proc/26863/fd/3 -> /mnt Was sagt mir das jetzt ? Prozess 26863 ist folgendes: sunhb58820:~ # ps aux|grep -i 26863 root 22360 0.0 0.0 4532 824 pts/14 S+ 15:02 0:00 grep -i 26863 root 26863 0.0 0.0 19492 1052 ? D Sep05 0:00 ls -A -N --color=tty -T 0 -alF /mnt/ Das ist ein ls, das sich aufgehangen hat. Im Zustand "D" kann ich den nicht abschießen. Bernd Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess, Dr. Nikolaus Blum, Dr. Alfons Enhsen Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, Am Sun, 07 Sep 2014, Lentes, Bernd schrieb:
Daß PID 26863 /mnt/ als/mit dem Filedescriptor 3 offen hat (vermutlich via 'int fd = open(...); + DIR *d = fdopendir(fd);').
Jap. Da hilft nur ein Timeout oder ein reboot. Wobei du vorher noch mit 'umount -f' und trennen des Netzes und restart des exportierenden Serverprozesses testen kannst. Ich kenn das aber nur von NFS (z.B. wenn ich "ausversehen" den Fileserver runterfahre ohne die FS vorher am Client zu unmounten ;) Irgendwie[tm] kann man das dazu bekommen sich zu berappeln. Manchmal zumindest. Wie das bei CIFS ist weiß ich nicht (dürfte auch vom Server abhängen). Du mußt letztlich abwägen, was praktikabler ist: auf den Timeout hoffen/warten oder doch rebooten ... Dabei am besten vorher möglichst viel unmounten, / ro remounten, ggfs. per sysrq ... -dnh -- A common mistake that people make, when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -- Douglas Adams - Mostly Harmless -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (3)
-
David Haller -
Lentes, Bernd -
Martin Schröder