Discussion:
AW: Ressourcenfresser finden
Lentes, Bernd
2014-05-14 11:19:43 UTC
Permalink
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
�؞.+-y�󹷬��ez{�'$zt�y��xƢ�������ǝ{맲��r��z�^�ˬz��Rg^������vh���kj�+�竭蜅��r���
Tobias Crefeld
2014-05-14 12:45:50 UTC
Permalink
Am Wed, 14 May 2014 13:19:43 +0200 schrieb "Lentes, Bernd"
Post by 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 ?
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: ***@xabber.de
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+***@opensuse.org
Um den Listen Administrator zu erreichen, schicken
Sie eine Mail an: opensuse-de+***@opensuse.org
Markus Heinze
2014-05-14 13:05:34 UTC
Permalink
Moin moin
Post by Lentes, Bernd
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,
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/


lg max
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+***@opensuse.org
Um den Listen Administrator zu erreichen, schicken
Sie eine Mail an: opensuse-de+***@opensuse.org
Lentes, Bernd
2014-05-14 13:43:14 UTC
Permalink
Post by Markus Heinze
Moin moin
Post by Lentes, Bernd
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,
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
�؞.+-y�󹷬��ez{�'$zt�y��xƢ�������ǝ{맲��r��z�^�ˬz��Rg^������vh���kj�+�竭蜅��r���
Joerg Thuemmler
2014-05-14 13:57:42 UTC
Permalink
Post by Lentes, Bernd
Post by Markus Heinze
Moin moin
Post by Lentes, Bernd
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,
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+***@opensuse.org
Um den Listen Administrator zu erreichen, schicken
Sie eine Mail an: opensuse-de+***@opensuse.org
Lentes, Bernd
2014-05-14 15:23:01 UTC
Permalink
Post by Joerg Thuemmler
Post by Markus Heinze
Moin moin
Post by Lentes, Bernd
Am Thu, 8 May 2014 19:06:18 +0200 schrieb "Lentes, Bernd"
...
Post by Joerg Thuemmler
Post by Markus Heinze
Post by 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 ?
...
Post by Joerg Thuemmler
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.
Post by Joerg Thuemmler
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
�؞.+-y�󹷬��ez{�'$zt�y��xƢ�������ǝ{맲��r��z�^�ˬz��Rg^������vh���kj�+�竭蜅��r���
Lentes, Bernd
2014-05-16 12:16:23 UTC
Permalink
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�
Tobias Crefeld
2014-05-16 21:16:44 UTC
Permalink
Am Fri, 16 May 2014 14:16:23 +0200
Post by 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+***@opensuse.org
Um den Listen Administrator zu erreichen, schicken
Sie eine Mail an: opensuse-de+***@opensuse.org
Lentes, Bernd
2014-05-19 13:12:36 UTC
Permalink
Post by Tobias Crefeld
Am Fri, 16 May 2014 14:16:23 +0200
Post by 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".
Post by Tobias Crefeld
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).
Post by Tobias Crefeld
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
�؞.+-y�󹷬��ez{�'$zt�y��xƢ�������ǝ{맲��r��z�^�ˬz��Rg^������vh���kj�+�竭蜅��r���
Lentes, Bernd
2014-05-19 16:07:20 UTC
Permalink
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
&v'���^i��m�-zY^��!���(�z)�1��jz)z{.��^��칻�&ޢ�������ק.+-zp�)���ڶ�����z'!z{�'$z
Joerg Thuemmler
2014-05-20 05:51:40 UTC
Permalink
Post by Lentes, Bernd
Hi,
(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+***@opensuse.org
Um den Listen Administrator zu erreichen, schicken
Sie eine Mail an: opensuse-de+***@opensuse.org
Tobias Crefeld
2014-05-24 22:02:20 UTC
Permalink
Am Tue, 20 May 2014 07:51:40 +0200 schrieb Joerg Thuemmler
Post by 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: ***@xabber.de
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+***@opensuse.org
Um den Listen Administrator zu erreichen, schicken
Sie eine Mail an: opensuse-de+***@opensuse.org
Joerg Thuemmler
2014-05-26 06:30:45 UTC
Permalink
Post by Tobias Crefeld
Am Tue, 20 May 2014 07:51:40 +0200 schrieb Joerg Thuemmler
Post by 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+***@opensuse.org
Um den Listen Administrator zu erreichen, schicken
Sie eine Mail an: opensuse-de+***@opensuse.org
Tobias Crefeld
2014-05-25 09:51:14 UTC
Permalink
Am Mon, 19 May 2014 18:07:20 +0200 schrieb "Lentes, Bernd"
Post by 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.
Post by Lentes, Bernd
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: ***@xabber.de
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+***@opensuse.org
Um den Listen Administrator zu erreichen, schicken
Sie eine Mail an: opensuse-de+***@opensuse.org
Joerg Thuemmler
2014-05-19 05:54:19 UTC
Permalink
Post by Lentes, Bernd
Hi,
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.
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 !
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+***@opensuse.org
Um den Listen Administrator zu erreichen, schicken
Sie eine Mail an: opensuse-de+***@opensuse.org
Loading...