Ressourcenfresser finden

older
Fn-Keys bei Toshiba L350 unter 12.3

Lentes, Bernd

8 May 2014 8 May '14

17:06

Hi, ich habe auf einem System (SLES 11 SP3, 64bit) eine ungewöhnlich hohe Last, ohne den Verursacher zu finden. top: ================================================= top - 16:23:56 up 177 days, 22:57, 4 users, load average: 10.56, 10.46, 10.42 Tasks: 221 total, 1 running, 219 sleeping, 0 stopped, 1 zombie Cpu(s): 1.0%us, 0.5%sy, 0.0%ni, 24.5%id, 74.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 72498M total, 69508M used, 2990M free, 587M buffers Swap: 2046M total, 8M used, 2038M free, 65367M cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5107 root 20 0 422m 8576 4740 S 3 0.0 229:06.40 libvirtd 20115 root 20 0 860m 100m 16m S 3 0.1 60:12.04 python 26563 root 20 0 416m 25m 14m S 2 0.0 51:58.84 knotify4 26351 root 20 0 128m 90m 5556 S 1 0.1 10:44.19 nxagent 5827 root 20 0 260m 15m 13m S 0 0.0 0:01.43 kscreenlocker 6215 root 20 0 28336 2056 1140 S 0 0.0 168:28.88 cmahostd 11835 root 20 0 0 0 0 S 0 0.0 0:05.06 kworker/2:13 15117 nx 20 0 88704 2316 1420 S 0 0.0 1:17.48 sshd 26384 root 20 0 9036 1320 908 R 0 0.0 0:00.04 top 1 root 20 0 10540 748 700 S 0 0.0 2:39.33 init ================================================= Das System hat zwei XEON a 4 Cores ! 25% idle ist nicht wirklich viel. Und die load liegt immerhin bei 10. Aber libvirtd ist mit 3% (auf eine CPU gerechnet) als Spitzenreiter wahrlich kein Ressourcenfresser. 74% wa deutet auf viel IO hin. Also mal iotop angeworfen. iotop kummuliert in zwei Minuten: ================================================= Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s TID PRIO USER DISK READ DISK WRITE> SWAPIN IO COMMAND 531 be/4 root 0.00 B 72.00 K 0.00 % 0.00 % [kjournald] 5075 be/4 root 0.00 B 32.00 K 0.00 % 0.00 % java -Xrs -Xms32m -Xmx64m -Dlog4j.configuration=~apcc.m11.arch.application.Application everything 5115 be/4 root 0.00 B 28.00 K 0.00 % 0.00 % libvirtd --daemon --config /etc/libvirt/libvirtd.conf --listen 5033 be/4 root 0.00 B 16.00 K 0.00 % 0.00 % java -Xrs -Xms32m -Xmx64m -Dlog4j.configuration=~apcc.m11.arch.application.Application everything 5112 be/4 root 0.00 B 12.00 K 0.00 % 0.00 % libvirtd --daemon --config /etc/libvirt/libvirtd.conf --listen 5113 be/4 root 0.00 B 12.00 K 0.00 % 0.00 % libvirtd --daemon --config /etc/libvirt/libvirtd.conf --listen 2232 be/4 root 0.00 B 8.00 K 0.00 % 0.00 % syslog-ng ================================================== Das ist nichts ! Ich habe zwar auf dem Server noch einen Zombie laufen (anderer thread), aber nach http://de.wikipedia.org/wiki/Zombie_%28Informatik%29 braucht ein Zombie keine Ressourcen ausser dem Eintrag in der Prozesstabelle. Habe also hohe CPU- und IO-Last, finde aber keinen Ressourcenfresser. Any ideas ? Bernd -- 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

Show replies by thread

Tobias Crefeld

8 May 8 May

18:58

Am Thu, 8 May 2014 19:06:18 +0200 schrieb "Lentes, Bernd" :

...

================================================= top - 16:23:56 up 177 days, 22:57, 4 users, load average: 10.56, 10.46, 10.42 Tasks: 221 total, 1 running, 219 sleeping, 0 stopped, 1 zombie Cpu(s): 1.0%us, 0.5%sy, 0.0%ni, 24.5%id, 74.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 72498M total, 69508M

Linux-load ist nicht zwangsläufig durch vielbeschäftigte CPUs verursacht. Exzessives Warten hat denselben Effekt. Habe ich eigentlich nur bei hardware-nahen Problemen beobachtet, insbesondere, wenn der Access zum Storage gestört oder defekt war. Einen Hinweis kann top liefern, wenn Du dort die Taste "i" drückst und auf die Prozesse mit state "D" oder "R" achtest. -- Gruß, Tobias. Email: crefeld@gmx.net xmpp: crefeld@xabber.de -- 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

Bernd

9 May 9 May

05:26

Am Thu, 8 May 2014 19:06:18 +0200 schrieb "Lentes, Bernd" :

...

Hi,

ich habe auf einem System (SLES 11 SP3, 64bit) eine ungewöhnlich hohe Last, ohne den Verursacher zu finden.

top:

================================================= top - 16:23:56 up 177 days, 22:57, 4 users, load average: 10.56, 10.46, 10.42 Tasks: 221 total, 1 running, 219 sleeping, 0 stopped, 1 zombie Cpu(s): 1.0%us, 0.5%sy, 0.0%ni, 24.5%id, 74.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 72498M total, 69508M used, 2990M free, 587M buffers wap: 2046M total, 8M used, 2038M free, 65367M cached

(...) Schau mal bei den WaitStaits (wa), 74% ist exorbitant. Da scheint etwas am I/O zu klemmen. Bye Bernd -- 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

Kai Grunau

06:30

On 05/08/2014 08:58 PM, Tobias Crefeld wrote:

...

Am Thu, 8 May 2014 19:06:18 +0200 schrieb "Lentes, Bernd" :

...
================================================= top - 16:23:56 up 177 days, 22:57, 4 users, load average: 10.56, 10.46, 10.42 Tasks: 221 total, 1 running, 219 sleeping, 0 stopped, 1 zombie Cpu(s): 1.0%us, 0.5%sy, 0.0%ni, 24.5%id, 74.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 72498M total, 69508M Linux-load ist nicht zwangsläufig durch vielbeschäftigte CPUs verursacht. Exzessives Warten hat denselben Effekt. Habe ich eigentlich nur bei hardware-nahen Problemen beobachtet, insbesondere, wenn der Access zum Storage gestört oder defekt war. Einen Hinweis kann top liefern, wenn Du dort die Taste "i" drückst und auf die Prozesse mit state "D" oder "R" achtest.

das kann ich bestaetigen. Ich hatte vor ein paar Wochen einen Rechner (CentOS) in den Fingern, der das beschrieben Verhalten aufwies. Eine der direct attached RAID5 LUN hatte eine defekte Platte. Der Controller hatte es nicht bemerkt, eine HotSpare sprang nicht ein. Nur durch Schreib-Teste (dd) habe ich herausgefunden welche es war. Hth, Kai -- 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

Lentes, Bernd

14 May 14 May

11:19

New subject: AW: Ressourcenfresser finden

Tobias schrieb:

...

Am Thu, 8 May 2014 19:06:18 +0200 schrieb "Lentes, Bernd" :

...
================================================= top - 16:23:56 up 177 days, 22:57, 4 users, load average: 10.56, 10.46, 10.42 Tasks: 221 total, 1 running, 219 sleeping, 0 stopped, 1 zombie Cpu(s): 1.0%us, 0.5%sy, 0.0%ni, 24.5%id, 74.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 72498M total, 69508M

Linux-load ist nicht zwangsläufig durch vielbeschäftigte CPUs verursacht. Exzessives Warten hat denselben Effekt. Habe ich eigentlich nur bei hardware-nahen Problemen beobachtet, insbesondere, wenn der Access zum Storage gestört oder defekt war. Einen Hinweis kann top liefern, wenn Du dort die Taste "i" drückst und auf die Prozesse mit state "D" oder "R" achtest.

Hi, hab's gemacht, folgendes kam raus: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10630 root 20 0 4212 700 588 D 0 0.0 0:00.02 mingetty 11831 root 20 0 0 0 0 D 0 0.0 0:00.00 kworker/2:9 22202 root 20 0 0 0 0 R 0 0.0 0:18.19 kworker/7:1 25841 root 20 0 0 0 0 D 0 0.0 0:00.00 flush-cifs-3 27817 root 20 0 8920 1208 828 R 0 0.0 0:00.11 top Was sagt mir das jetzt ? 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

Tobias Crefeld

12:45

Am Wed, 14 May 2014 13:19:43 +0200 schrieb "Lentes, Bernd" :

...

hab's gemacht, folgendes kam raus:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10630 root 20 0 4212 700 588 D 0 0.0 0:00.02 mingetty 11831 root 20 0 0 0 0 D 0 0.0 0:00.00 kworker/2:9 22202 root 20 0 0 0 0 R 0 0.0 0:18.19 kworker/7:1 25841 root 20 0 0 0 0 D 0 0.0 0:00.00 flush-cifs-3 27817 root 20 0 8920 1208 828 R 0 0.0 0:00.11 top

Was sagt mir das jetzt ?

Von denen dürfte eigentlich keiner dauerhaft anliegen. Selbst mingetty nicht, wenn sich da nicht ständig jemand an- und abmeldet. Ich würde mich auf den kworker/7 mit dem relativ hohen Time-Budget konzentrieren, aber genauer kenne ich mich damit nicht aus. k steht für kernel, also tippe ich auf was hardware-nahes, IO, IRQ und sowas. Zumindest etwas, für das der Kernel primär zuständig ist, also auch filesystems, etc., die nicht im userspace laufen. iotop, powertop und perf könnten noch Hinweise liefern, produzieren aber selbst einige Last. Manchmal liefert auch ein CPU-backtrace Einträge im Kernellog, die beim Eingrenzen weiterhelfen. Liegt die Last auch an, wenn Du in runlevel 1 oder 2 startest? Falls nein, vielleicht mal sukzessive einige Dienste beenden, die nicht hauptsächlich im userspace laufen. -- Gruß, Tobias. no email, only xmpp: crefeld@xabber.de -- 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

Markus Heinze

13:05

New subject: AW: Ressourcenfresser finden

Moin moin Am 2014-05-14 13:19, schrieb Lentes, Bernd:

...

Tobias schrieb:

...
Am Thu, 8 May 2014 19:06:18 +0200 schrieb "Lentes, Bernd" :

...
================================================= top - 16:23:56 up 177 days, 22:57, 4 users, load average: 10.56, 10.46, 10.42 Tasks: 221 total, 1 running, 219 sleeping, 0 stopped, 1 zombie Cpu(s): 1.0%us, 0.5%sy, 0.0%ni, 24.5%id, 74.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 72498M total, 69508M

Linux-load ist nicht zwangsläufig durch vielbeschäftigte CPUs verursacht. Exzessives Warten hat denselben Effekt. Habe ich eigentlich nur bei hardware-nahen Problemen beobachtet, insbesondere, wenn der Access zum Storage gestört oder defekt war. Einen Hinweis kann top liefern, wenn Du dort die Taste "i" drückst und auf die Prozesse mit state "D" oder "R" achtest.

Hi,

hab's gemacht, folgendes kam raus:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10630 root 20 0 4212 700 588 D 0 0.0 0:00.02 mingetty 11831 root 20 0 0 0 0 D 0 0.0 0:00.00 kworker/2:9 22202 root 20 0 0 0 0 R 0 0.0 0:18.19 kworker/7:1 25841 root 20 0 0 0 0 D 0 0.0 0:00.00 flush-cifs-3 27817 root 20 0 8920 1208 828 R 0 0.0 0:00.11 top

Was sagt mir das jetzt ?

Schau mal hier vllt. hilft es, http://souriguha.wordpress.com/2011/03/08/how-to-solve-problem-with-thinkpad... lg max -- 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

Lentes, Bernd

13:43

New subject: AW: AW: Ressourcenfresser finden

Markus schrieb:

...

Moin moin

Am 2014-05-14 13:19, schrieb Lentes, Bernd:

...
Tobias schrieb:

...
Am Thu, 8 May 2014 19:06:18 +0200 schrieb "Lentes, Bernd" :

...
================================================= top - 16:23:56 up 177 days, 22:57, 4 users, load average: 10.56, 10.46, 10.42 Tasks: 221 total, 1 running, 219 sleeping, 0 stopped, 1 zombie Cpu(s): 1.0%us, 0.5%sy, 0.0%ni, 24.5%id, 74.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 72498M total, 69508M

Linux-load ist nicht zwangsläufig durch vielbeschäftigte CPUs verursacht. Exzessives Warten hat denselben Effekt. Habe ich eigentlich nur bei hardware-nahen Problemen beobachtet, insbesondere, wenn der Access zum Storage gestört oder defekt war. Einen Hinweis kann top liefern, wenn Du dort die Taste "i" drückst und auf die Prozesse mit state "D" oder "R" achtest.

Hi,

hab's gemacht, folgendes kam raus:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10630 root 20 0 4212 700 588 D 0 0.0 0:00.02 mingetty 11831 root 20 0 0 0 0 D 0 0.0 0:00.00 kworker/2:9 22202 root 20 0 0 0 0 R 0 0.0 0:18.19 kworker/7:1 25841 root 20 0 0 0 0 D 0 0.0 0:00.00 flush-cifs-3 27817 root 20 0 8920 1208 828 R 0 0.0 0:00.11 top

Was sagt mir das jetzt ?

Schau mal hier vllt. hilft es,

http://souriguha.wordpress.com/2011/03/08/how-to-solve-problem-with- thinkpadkslowd-kworker-on-linux-kernel-2-35-2-36/

Hallo Markus, hat leider nix geholfen. 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

Joerg Thuemmler

13:57

Am 14.05.2014 15:43, schrieb Lentes, Bernd:

...

Markus schrieb:

...
Moin moin

Am 2014-05-14 13:19, schrieb Lentes, Bernd:

...
Tobias schrieb:

...
Am Thu, 8 May 2014 19:06:18 +0200 schrieb "Lentes, Bernd" :

...
================================================= top - 16:23:56 up 177 days, 22:57, 4 users, load average: 10.56, 10.46, 10.42 Tasks: 221 total, 1 running, 219 sleeping, 0 stopped, 1 zombie Cpu(s): 1.0%us, 0.5%sy, 0.0%ni, 24.5%id, 74.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 72498M total, 69508M

Linux-load ist nicht zwangsläufig durch vielbeschäftigte CPUs verursacht. Exzessives Warten hat denselben Effekt. Habe ich eigentlich nur bei hardware-nahen Problemen beobachtet, insbesondere, wenn der Access zum Storage gestört oder defekt war. Einen Hinweis kann top liefern, wenn Du dort die Taste "i" drückst und auf die Prozesse mit state "D" oder "R" achtest.

Hi,

hab's gemacht, folgendes kam raus:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10630 root 20 0 4212 700 588 D 0 0.0 0:00.02 mingetty 11831 root 20 0 0 0 0 D 0 0.0 0:00.00 kworker/2:9 22202 root 20 0 0 0 0 R 0 0.0 0:18.19 kworker/7:1 25841 root 20 0 0 0 0 D 0 0.0 0:00.00 flush-cifs-3 27817 root 20 0 8920 1208 828 R 0 0.0 0:00.11 top

Was sagt mir das jetzt ?

Schau mal hier vllt. hilft es,

http://souriguha.wordpress.com/2011/03/08/how-to-solve-problem-with- thinkpadkslowd-kworker-on-linux-kernel-2-35-2-36/

Hallo Markus,

hat leider nix geholfen.

Bernd

Hi, also "D"-Prozesse sollte man eigentlich nicht haben (="uninterrptable sleep"). Vor allem im Zusammenhang mit Hardware. Ich habe sowas mal bei einem Brenner gehabt, der wegen kaputter CDs in diesen Zustand kam. Da half dann nur Stromkabel ziehen (am Brenner, ging sogar online). In Deinem Falle würde ich mich mal fragen, was "flush.cifs-3" da treibt, das ist doch sicher was von Samba? Netzwerkprobleme? Ein flush sollte doch nur Millisekunden dauern... Einen Apachen mit "D" habe ich allerdings auch noch nie gesehen, meine schlafen zwar auch ("S"), beim Arbeiten ("R") habe ich die noch nie gesehen, wahrhaft freie Indianer eben... aber in den ewigen Jagdgründen waren die IMHO noch nie ;-) cu jth -- www.teddylinx.de -- 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

Lentes, Bernd

15:23

New subject: AW: Ressourcenfresser finden

Jörg schrieb:

...

Am 14.05.2014 15:43, schrieb Lentes, Bernd:

...
Markus schrieb:

...
Moin moin

Am 2014-05-14 13:19, schrieb Lentes, Bernd:

...
Tobias schrieb:

...
Am Thu, 8 May 2014 19:06:18 +0200 schrieb "Lentes, Bernd" :

...

...
...
...
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10630 root 20 0 4212 700 588 D 0 0.0 0:00.02 mingetty 11831 root 20 0 0 0 0 D 0 0.0 0:00.00 kworker/2:9 22202 root 20 0 0 0 0 R 0 0.0 0:18.19 kworker/7:1 25841 root 20 0 0 0 0 D 0 0.0 0:00.00 flush-cifs-3 27817 root 20 0 8920 1208 828 R 0 0.0 0:00.11 top

Was sagt mir das jetzt ?

...

Hi,

also "D"-Prozesse sollte man eigentlich nicht haben (="uninterrptable sleep"). Vor allem im Zusammenhang mit Hardware. Ich habe sowas mal bei einem Brenner gehabt, der wegen kaputter CDs in diesen Zustand kam. Da half dann nur Stromkabel ziehen (am Brenner, ging sogar online).

Stimmt. ich habe mal auf anderen Maschinen geschaut, da ist höchstens einer im "D"-Zustand.

...

In Deinem Falle würde ich mich mal fragen, was "flush.cifs-3" da treibt, das ist doch sicher was von Samba? Netzwerkprobleme? Ein flush sollte doch nur Millisekunden dauern...

Einen Apachen mit "D" habe ich allerdings auch noch nie gesehen, meine schlafen zwar auch ("S"), beim Arbeiten ("R") habe ich die noch nie gesehen, wahrhaft freie Indianer eben... aber in den ewigen Jagdgründen waren die IMHO noch nie ;-)

Hallo Jörg, der flush-cifs-3 hat mich auch gestört. Ich hatte einen mount auf einen NAS, den ich auch nicht umounten konnte, weil angeblich Dateien offen waren. lsof hat mir aber keine auf dem Mountpoint angezeigt. Habe dann mit umount -l getrennt. Der flush-cifs-3 läuft immer noch, und ich habe immer noch hohe Last. Ich habe dann versucht, den flush-cifs-3 zu killen, was aber Unsinn ist, da ja "uninterruptable" bedeutet, das er mittels eines Signals nicht aufgeweckt werden kann. Hier noch mal aktuelle Zahlen: ===================================== top - 17:01:13 up 183 days, 23:35, 4 users, load average: 10.39, 10.31, 10.30 Tasks: 195 total, 1 running, 193 sleeping, 0 stopped, 1 zombie Cpu(s): 0.9%us, 0.4%sy, 0.0%ni, 24.7%id, 74.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 72498M total, 69720M used, 2777M free, 663M buffers Swap: 2046M total, 8M used, 2038M free, 65530M cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5107 root 20 0 426m 8672 4740 S 4 0.0 289:54.87 libvirtd 20115 root 20 0 940m 106m 16m S 3 0.1 111:35.64 python 26563 root 20 0 416m 25m 14m S 2 0.0 197:52.00 knotify4 9259 root 20 0 0 0 0 S 0 0.0 0:00.55 kworker/u:0 26351 root 20 0 130m 92m 5556 S 0 0.1 17:07.92 nxagent 1 root 20 0 10540 748 700 S 0 0.0 2:42.56 init 2 root 20 0 0 0 0 S 0 0.0 0:07.36 kthreadd ====================================== 25% idle ist nicht viel, aber libvirtd ist mit 4% (auf eine CPU gerechnet) der Prozess, der am meisten CPU-Zeit braucht. 74%wa deutet auf viel Warten auf IO hin, iotop bestätigt mir das aber nicht: ====================================== TID PRIO USER DISK READ DISK WRITE> SWAPIN IO COMMAND 531 be/4 root 0.00 B 112.00 K 0.00 % 0.00 % [kjournald] 5112 be/4 root 0.00 B 36.00 K 0.00 % 0.00 % libvirtd --daemon --config /etc/libvirt/libvirtd.conf --listen 5075 be/4 root 0.00 B 32.00 K 0.00 % 0.00 % java -Xrs -Xms32m -Xmx64m -Dlog4j.configuration=~apcc.m11.arch.application.Application everything 5111 be/4 root 0.00 B 28.00 K 0.00 % 0.00 % libvirtd --daemon --config /etc/libvirt/libvirtd.conf --listen 2232 be/4 root 0.00 B 20.00 K 0.00 % 0.00 % syslog-ng 5109 be/4 root 0.00 B 20.00 K 0.00 % 0.00 % libvirtd --daemon --config /etc/libvirt/libvirtd.conf --listen 5033 be/4 root 0.00 B 16.00 K 0.00 % 0.00 % java -Xrs -Xms32m -Xmx64m -Dlog4j.configuration=~apcc.m11.arch.application.Application everything 5110 be/4 root 0.00 B 8.00 K 0.00 % 0.00 % libvirtd --daemon --config /etc/libvirt/libvirtd.conf --listen 31030 be/7 root 0.00 B 4.00 K 0.00 % 0.00 % snmpd -r -A -LF i /var/log/net-snmpd.log -p /var/run/snmpd.pid 5048 be/4 root 0.00 B 4.00 K 0.00 % 0.00 % java -Xrs -Xms32m -Xmx64m -Dlog4j.configuration=~apcc.m11.arch.application.Application everything 5113 be/4 root 0.00 B 4.00 K 0.00 % 0.00 % libvirtd --daemon --config /etc/libvirt/libvirtd.conf --listen 5116 be/4 root 0.00 B 4.00 K 0.00 % 0.00 % libvirtd --daemon --config /etc/libvirt/libvirtd.conf --listen 7259 be/4 root 0.00 B 4.00 K 0.00 % 0.00 % nscd ======================================= wieder auf 2 Minuten kummuliert. In 2 Minuten hat kjournald ganze 112KB geschrieben. Das ist nichts. 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

Lentes, Bernd

16 May 16 May

12:16

New subject: AW: Ressourcenfresser finden

Hi, habe noch was interessantes rausgefunden: top - 14:02:47 up 185 days, 20:36, 4 users, load average: 13.07, 16.20, 16.99 Tasks: 212 total, 1 running, 210 sleeping, 0 stopped, 1 zombie Cpu0 : 1.9%us, 1.9%sy, 0.0%ni, 96.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id,100.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id,100.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id,100.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 0.0%us, 0.0%sy, 0.3%ni, 0.0%id, 99.7%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id,100.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 0.0%us, 0.3%sy, 0.0%ni, 0.0%id, 99.7%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, 32726M used, 39772M free, 249M buffers Swap: 2046M total, 4M used, 2042M free, 28916M cached 6 Kerne scheinen durch Warten auf IO total ausgebremst zu sein. Nur zwei Kerne sind haben nix zu tun. Wenn ich aber nun CPU-intensive Prozesse starte (cat /dev/urandom > /dev/null), dann verschwindet die (scheinbare) IO-Last: top - 14:07:50 up 185 days, 20:41, 4 users, load average: 14.63, 14.13, 15.75 Tasks: 224 total, 9 running, 214 sleeping, 0 stopped, 1 zombie Cpu0 : 3.0%us, 0.3%sy, 0.0%ni, 96.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 0.0%us, 99.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Cpu2 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 2.6%us, 1.3%sy, 0.0%ni, 0.0%id, 96.1%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 0.3%us, 0.3%sy, 0.0%ni, 0.0%id, 99.3%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 72498M total, 32727M used, 39770M free, 249M buffers Swap: 2046M total, 4M used, 2042M free, 28916M cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4515 root 20 0 4304 556 468 R 100 0.0 2:27.30 cat 4973 root 20 0 4304 556 468 R 100 0.0 2:10.26 cat 4978 root 20 0 4304 556 468 R 100 0.0 2:08.83 cat 4979 root 20 0 4304 556 468 R 100 0.0 2:07.63 cat 5783 root 20 0 4304 556 468 R 100 0.0 1:17.52 cat Es laufen 5 cat-Prozesse, jeder nutzt einen Kern zu 100%. Es scheinen aber nur noch zwei Kerne auf IO zu warten (CPU 5 und 6). Vorher waren es 6 Kerne. Wäre da wirklich IO, müsste sich das doch zu dem cat-Befehl addieren, oder ? Es scheint aber zu verschwinden ! Starte ich noch mehr cat-Prozesse (insg. 7), "verschwindet" immer mehr IO-Last: top - 14:12:47 up 185 days, 20:46, 4 users, load average: 16.14, 15.10, 15.71 Tasks: 224 total, 9 running, 214 sleeping, 0 stopped, 1 zombie Cpu0 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 3.3%us, 1.3%sy, 0.0%ni, 0.0%id, 95.4%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 0.3%us, 99.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 72498M total, 32728M used, 39770M free, 249M buffers Swap: 2046M total, 4M used, 2042M free, 28916M cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4978 root 20 0 4304 556 468 R 100 0.0 7:05.05 cat 4515 root 20 0 4304 556 468 R 100 0.0 7:23.26 cat 4973 root 20 0 4304 556 468 R 100 0.0 7:06.54 cat 4979 root 20 0 4304 556 468 R 100 0.0 7:03.89 cat 5783 root 20 0 4304 556 468 R 100 0.0 6:13.65 cat 11380 root 20 0 4304 556 468 R 100 0.0 0:36.48 cat 11379 root 20 0 4304 556 468 R 100 0.0 0:38.37 cat Nur noch ein Kern (CPU 1) scheint mit Warten auf IO beschäftigt zu sein. !?! 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 Rgbx��޲ץ��r��҉碝��V��uﮞ˛��m�)z{.��+�I�zr�ק٢�+-��h�;��r��brG�J'��w�j)Z��^�ˬy׾� ޮ�^�ˬz��

Tobias Crefeld

21:16

Am Fri, 16 May 2014 14:16:23 +0200 schrieb "Lentes, Bernd" :

...

Mem: 72498M total, 32726M used, 39772M free, 249M buffers

Was mich ehrlich gesagt noch viel mehr wundert, sind die Massen ungenutzten RAM bei gleichzeitig minimal eingerichteten buffers - und das nach 180 Tagen uptime... Normalerweise wird der meiste, nicht für Applikationen als heap, etc. genutzte RAM vom Kernel für buffers verwendet. Bei wenig storage-Verwendung ist unmittelbar nach dem Booten für ein paar Minuten bis Stunden der Bedarf an buffers noch so gering, dass mehr als 10 % frei sind, aber nach 180 Tagen?!? Vielleicht solltest Du mal skizzieren, welche storages wie verwendet werden. Arbeitet Ihr mit VM, die ihre Images auf Samba-shares haben? Habt Ihr storage, für den der Kernel aus irgendeinem Grund keine buffers verwenden darf? Speziell konfigurierte Kernel? Ich habe gute Erfahrungen mit VM gemacht, die ihre Images auf direct attached storage, drbd-devices oder im SAN (typischerweise via iscsi) haben. Mit NFS-mounts wurde es gelegentlich instabil, insbesondere, wenn hard-mounts konfiguriert waren. Einmal ist ein solcher Host dank hard-mounts gegen die Wand gefahren (load > 40). War zwar Oracle und nicht Virtualisierung, aber der Vorfall hat recht nachdrücklich vorgeführt, was bei gestorbenen, aber noch gemounteten NFS-mounts passiert, wenn sie hard-mounted sind. Auf samba-mounts (alias cifs-mounts) habe ich es noch nie probiert, aber so ganz subjektiv und ohne jede Begründung würde ich NAS-devices nie niemals nicht als storage für VM-images verwenden. Aber ich bin selber schon mit "Cloud"-Providern kollidiert, die recht hemmungslos Oracle Tablespaces (inkl. logs) auf NAS-mounts mit transparentem write-behind-cache eingerichten und ganz stolz sind, dass sie trotz Transaktionskontrolle superschnell sind... naja, lassen wir das. Gruß, Tobias. -- 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

Joerg Thuemmler

19 May 19 May

05:54

Am 16.05.2014 14:16, schrieb Lentes, Bernd:

...

Hi,

habe noch was interessantes rausgefunden:

top - 14:02:47 up 185 days, 20:36, 4 users, load average: 13.07, 16.20, 16.99 Tasks: 212 total, 1 running, 210 sleeping, 0 stopped, 1 zombie Cpu0 : 1.9%us, 1.9%sy, 0.0%ni, 96.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id,100.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id,100.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id,100.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 0.0%us, 0.0%sy, 0.3%ni, 0.0%id, 99.7%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id,100.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 0.0%us, 0.3%sy, 0.0%ni, 0.0%id, 99.7%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, 32726M used, 39772M free, 249M buffers Swap: 2046M total, 4M used, 2042M free, 28916M cached

6 Kerne scheinen durch Warten auf IO total ausgebremst zu sein. Nur zwei Kerne sind haben nix zu tun. Wenn ich aber nun CPU-intensive Prozesse starte (cat /dev/urandom > /dev/null), dann verschwindet die (scheinbare) IO-Last:

top - 14:07:50 up 185 days, 20:41, 4 users, load average: 14.63, 14.13, 15.75 Tasks: 224 total, 9 running, 214 sleeping, 0 stopped, 1 zombie Cpu0 : 3.0%us, 0.3%sy, 0.0%ni, 96.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 0.0%us, 99.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Cpu2 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 2.6%us, 1.3%sy, 0.0%ni, 0.0%id, 96.1%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 0.3%us, 0.3%sy, 0.0%ni, 0.0%id, 99.3%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 72498M total, 32727M used, 39770M free, 249M buffers Swap: 2046M total, 4M used, 2042M free, 28916M cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4515 root 20 0 4304 556 468 R 100 0.0 2:27.30 cat 4973 root 20 0 4304 556 468 R 100 0.0 2:10.26 cat 4978 root 20 0 4304 556 468 R 100 0.0 2:08.83 cat 4979 root 20 0 4304 556 468 R 100 0.0 2:07.63 cat 5783 root 20 0 4304 556 468 R 100 0.0 1:17.52 cat

Es laufen 5 cat-Prozesse, jeder nutzt einen Kern zu 100%. Es scheinen aber nur noch zwei Kerne auf IO zu warten (CPU 5 und 6). Vorher waren es 6 Kerne. Wäre da wirklich IO, müsste sich das doch zu dem cat-Befehl addieren, oder ? Es scheint aber zu verschwinden !

Starte ich noch mehr cat-Prozesse (insg. 7), "verschwindet" immer mehr IO-Last:

top - 14:12:47 up 185 days, 20:46, 4 users, load average: 16.14, 15.10, 15.71 Tasks: 224 total, 9 running, 214 sleeping, 0 stopped, 1 zombie Cpu0 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 3.3%us, 1.3%sy, 0.0%ni, 0.0%id, 95.4%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 0.3%us, 99.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 72498M total, 32728M used, 39770M free, 249M buffers Swap: 2046M total, 4M used, 2042M free, 28916M cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4978 root 20 0 4304 556 468 R 100 0.0 7:05.05 cat 4515 root 20 0 4304 556 468 R 100 0.0 7:23.26 cat 4973 root 20 0 4304 556 468 R 100 0.0 7:06.54 cat 4979 root 20 0 4304 556 468 R 100 0.0 7:03.89 cat 5783 root 20 0 4304 556 468 R 100 0.0 6:13.65 cat 11380 root 20 0 4304 556 468 R 100 0.0 0:36.48 cat 11379 root 20 0 4304 556 468 R 100 0.0 0:38.37 cat

Nur noch ein Kern (CPU 1) scheint mit Warten auf IO beschäftigt zu sein.

!?!

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 Rgbx��޲ץ��r��҉碝��V��uﮞ˛��m�)z{.��+�I�zr�ק٢�+-��h�;��r��brG�J'��w�j)Z��^�ˬy׾� ޮ�^�ˬz�

Hi, ich kenn so ein Verhalten von meiner Datenbanksoftware (dataflex): wenn 4 user damit arbeiten, sind alle 4 Kerne erstmal voll ausgelastet und zwar mit Warten auf IO (klassischer Keyboard-input). Wenn es 8 sind, kriegt jeder 50%, wenn es 12 sind eben 33%, naja, es teilt sich natürlich nicht immer so linear auf... In der Praxis ist die Last allerdings nicht spürbar, d.h. weder die Nutzer der DB noch andere Programme leiden. Ich habe die Vermutung, dass sich durch die immer schnelleren CPUs die Interrupt-Abfragen für die Tastatur (beim Warten auf eine Eingabe) so beschleunigt haben, dass sie viel schneller nacheinander kommen und das diese Last verursacht. Ich habe im Menü der DB-Software eine Uhr mitlaufen und früher war es kein Problem einen Zyklus Zeitabfrage-Tastaturabfrage-Zeitabfrage-Tast... aufzubauen. Später (etwa seit AMD Athlon) musste ich eine Verzögerung einbauen, sonst geht die Prozessorlast (und nach einer Weile auch die Temperatur) hübsch hoch... Ich könnte mir vorstellen, dass auch andere interrup-basierte Dinge so ähnlich reagieren. cu jth -- www.teddylinx.de -- 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

Lentes, Bernd

13:12

New subject: AW: Ressourcenfresser finden

Tobias schrieb:

...

Am Fri, 16 May 2014 14:16:23 +0200 schrieb "Lentes, Bernd" :

...
Mem: 72498M total, 32726M used, 39772M free, 249M buffers

Was mich ehrlich gesagt noch viel mehr wundert, sind die Massen ungenutzten RAM bei gleichzeitig minimal eingerichteten buffers - und das nach 180 Tagen uptime...

Die haben mich auch überrascht. Schließlich heißt es: "free memory is wasted memory".

...

Vielleicht solltest Du mal skizzieren, welche storages wie verwendet werden. Arbeitet Ihr mit VM, die ihre Images auf Samba-shares haben? Habt Ihr storage, für den der Kernel aus irgendeinem Grund keine buffers verwenden darf? Speziell konfigurierte Kernel?

Der Server ist ein HP ML 350 G6. Angeschlossen ist ein HP FC SAN (P2000 G3) über zwei Emulex LPe12000 in einer Multipathkonfiguration. Der SAN beherbergt ein RAID5, das zwar gemountet ist, aber auf dem nichts abgespeichert ist. Außerdem haben wir einen HP RAID-Controller (HP410i) mit einem angeschlossenen RAID5, da drauf liegt das OS in einem LV. Der Kernel ist der Standardkernel von SLES 11 SP3 (3.0.93-0.8-default, 64bit).

...

Auf samba-mounts (alias cifs-mounts) habe ich es noch nie probiert, aber so ganz subjektiv und ohne jede Begründung würde ich NAS-devices nie niemals nicht als storage für VM-images verwenden. Aber ich bin selber schon mit "Cloud"-Providern kollidiert, die recht hemmungslos Oracle Tablespaces (inkl. logs) auf NAS-mounts mit transparentem write-behind- cache eingerichten und ganz stolz sind, dass sie trotz Transaktionskontrolle superschnell sind... naja, lassen wir das.

Du hast Recht. Wir hatten ein VM-Image auf einem cifs-share liegen. CIFS-Shares sind nicht 100%ig stabil, die sind uns in anderen Konstellationen (Rechnen auf einem HPC) schon um die Ohren geflogen. Ich werde das ändern. Allerdings läuft diese VM im Moment nicht, habe aber trotzdem die hohe Last. Scheint also kein Zusammenhang zu sein. 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

Lentes, Bernd

16:07

New subject: AW: Ressourcenfresser finden

Hi, mir ist noch was aufgefallen. Ich habe jetzt mehrere Prozesse/Threads im Zustand uninterruptable_sleep: (diese Webseite war sehr hilfreich: http://blog.kevac.org/2013/02/uninterruptible-sleep-d-state.html ) sunhb58820:/mnt/idg-2 # ps -eo ppid,pid,user,stat,pcpu,comm,wchan:32|grep D PPID PID USER STAT %CPU COMMAND WCHAN 1 10630 root Ds+ 0.0 mingetty sleep_on_page 2 11831 root D 0.0 kworker/2:9 lock_page 18711 25139 root D+ 0.0 shutdown writeback_inodes_sb_nr 2 25841 root D 0.0 flush-cifs-3 lock_page 1 29392 root Ds 0.0 shutdown writeback_inodes_sb_nr (ps zeigt auf diese Weise an, in welchem kernelthread die Prozesse hängen) Das riecht alles nach IO. Ich habe gestern den Rechner runterfahren wollen, er meckerte jedoch sinngemäß "mingetty hangs" (oder so ähnlich). Ich habe daraufhin den shutdown mit shutdown -c abgebrochen. So langsam fängt das aber an, Sinn zu machen. Wenn mehrere Prozesse im Zustand "uninterruptable sleep" sind, also auf IO warten, schlägt sich das auch in top nieder. Das System hat aber gar keine hohe IO-Last (was iotop bestätigt). Also stimmt was mit den Prozessen nicht. Und da habe ich auch etwas rausgefunden. Der mingetty kommt von einem login auf den Server via HP-ILO, der beim Abmelden hängen geblieben ist. Und dem flush-cifs-3 habe ich eventl. unterm Hintern den Mount weggenommen. Ich werde jetzt noch mal versuchen, den Rechner runterzufahren. Wenn das nicht geht, wird er hart ausgeschaltet, ist kein Produktivsystem. Und dann werde ich das System in nächster Zeit ein wenig beobachten. 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

Joerg Thuemmler

20 May 20 May

05:51

Am 19.05.2014 18:07, schrieb Lentes, Bernd:

...

Hi,

mir ist noch was aufgefallen. Ich habe jetzt mehrere Prozesse/Threads im Zustand uninterruptable_sleep: (diese Webseite war sehr hilfreich: http://blog.kevac.org/2013/02/uninterruptible-sleep-d-state.html )

sunhb58820:/mnt/idg-2 # ps -eo ppid,pid,user,stat,pcpu,comm,wchan:32|grep D PPID PID USER STAT %CPU COMMAND WCHAN 1 10630 root Ds+ 0.0 mingetty sleep_on_page 2 11831 root D 0.0 kworker/2:9 lock_page 18711 25139 root D+ 0.0 shutdown writeback_inodes_sb_nr 2 25841 root D 0.0 flush-cifs-3 lock_page 1 29392 root Ds 0.0 shutdown writeback_inodes_sb_nr (ps zeigt auf diese Weise an, in welchem kernelthread die Prozesse hängen)

Das riecht alles nach IO. Ich habe gestern den Rechner runterfahren wollen, er meckerte jedoch sinngemäß "mingetty hangs" (oder so ähnlich). Ich habe daraufhin den shutdown mit shutdown -c abgebrochen. So langsam fängt das aber an, Sinn zu machen. Wenn mehrere Prozesse im Zustand "uninterruptable sleep" sind, also auf IO warten, schlägt sich das auch in top nieder. Das System hat aber gar keine hohe IO-Last (was iotop bestätigt). Also stimmt was mit den Prozessen nicht. Und da habe ich auch etwas rausgefunden. Der mingetty kommt von einem login auf den Server via HP-ILO, der beim Abmelden hängen geblieben ist. Und dem flush-cifs-3 habe ich eventl. unterm Hintern den Mount weggenommen. Ich werde jetzt noch mal versuchen, den Rechner runterzufahren. Wenn das nicht geht, wird er hart ausgeschaltet, ist kein Produktivsystem. Und dann werde ich das System in nächster Zeit ein wenig beobachten.

Bernd

Hi, flush ohne Gerät ... ja das passt... und wer "uninterruptable" schläft, kann eben keine IO-Last mehr produzieren... mingetty sollte mit sowas eigentlich klarkommen? möglicherweise geht ein shutdown -n , das feature ist aber als [DEPRECATED] eingestuft... will es gerade auch nicht ausprobieren hier ;-) oder halt Affengriff, wenn der auch nicht funzt, bleibt eben nur Powerknopf ein paar Sekunden halten :-( Wenn Du nicht irgendwo einen Config-Fehler hast, wird das wohl eher eine Episode sein. Ich lasse ehrlich gesagt meinen Server hier jede Nacht rebooten, Sch... auf die uptime. Da verschwindet sowas dann von alleine. Aber das geht natürlich nicht mit jedem Server. Bei uns gibts allenfalls im Drucksaal mal eine Nachtschicht - oder bei mir selbst ;-) cu jth -- www.teddylinx.de -- 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

Tobias Crefeld

24 May 24 May

22:02

Am Tue, 20 May 2014 07:51:40 +0200 schrieb Joerg Thuemmler :

...

Ich lasse ehrlich gesagt meinen Server hier jede Nacht rebooten, Sch... auf die uptime. Da verschwindet sowas dann von alleine.

Lass mich raten: Zu lange Microsoft administriert? =:) -- Gruß, Tobias. no email, only xmpp: crefeld@xabber.de -- 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

Tobias Crefeld

25 May 25 May

09:51

Am Mon, 19 May 2014 18:07:20 +0200 schrieb "Lentes, Bernd" :

...

Der mingetty kommt von einem login auf den Server via HP-ILO, der beim Abmelden hängen geblieben ist.

Mit HP-hardware fehlt mir die nötige Erfahrung. Ich pflege mein Vorurteil, dass HP und Dell in die Microsoft-Welt gehören. :) Ich bringe die Details nicht mehr zusammen, aber ich habe in seltenen Fällen auf Sun-Hardware (x86) Störungen mit hoher Last von Prozessen im IPMI-Umfeld bis hin zur Kernel-panic gehabt. Blockierte Remote-Konsolzugriffe kenne ich eher von Supermicro-Derivaten. Die kommen allerdings mit verschiedenen 3rd-party-Lösungen von recht unterschiedlicher Qualität daher. Das geht soweit, dass da notfalls ein externe KVM-Fernsteuerung angebaut und das eingebaute Interface nur noch zum Ein- und Ausschalten verwendet wird.

...

Und dem flush-cifs-3 habe ich eventl. unterm Hintern den Mount weggenommen.

Kaum Erfahrung mit cifs, aber bei hard gemounteten nfs-exports ist es mir schon passiert, dass die Last wegen Ausfall des nfs-Serverzugriffs nach oben ging und sich das System auch nach remount nicht mehr erholt hat. Wenn das bei cifs genauso ist, dann wäre das eine Erklärung, könnte mir aber vorstellen, dass das Verhalten ebenso wie bei nfs konfigurierbar ist. -- Gruß, Tobias. no email, only xmpp: crefeld@xabber.de -- 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

Joerg Thuemmler

26 May 26 May

06:30

Am 25.05.2014 00:02, schrieb Tobias Crefeld:

...

Am Tue, 20 May 2014 07:51:40 +0200 schrieb Joerg Thuemmler :

...
Ich lasse ehrlich gesagt meinen Server hier jede Nacht rebooten, Sch... auf die uptime. Da verschwindet sowas dann von alleine.

Lass mich raten: Zu lange Microsoft administriert? =:)

nein, eigentlich nie (von ein paar fat clients mal abgesehen). Aber es gab immer mal ein paar Probleme, die man damit vergessen darf: ein (älteres kommerzielles) Datenbanksystem, welches manchmal Nutzer nicht korrekt aus dem Lizenzzähler nahm, ein Brenner der zum Zombie wurde, wenn mal eine SicherungsCD abstarb, heute eher Kernel-updates, für die ich nicht während der Arbeitszeit rebooten muss (klar, könnte ich natürlich auch gezielt so veranlassen)... außerdem lasse ich alle Sicherungen erst nach dem reboot starten, dann weiß ich, dass da was gesichert wird, was auch bootet und auch sicher konsistent ist... Kann man gern anders handhaben, ist meine Methode seit UnixSysVR4... cu jth -- www.teddylinx.de -- 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

3644

Age (days ago)

3662

Last active (days ago)

List overview

Download

18 comments

6 participants

participants (6)

Bernd
Joerg Thuemmler
Kai Grunau
Lentes, Bernd
Markus Heinze
Tobias Crefeld