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

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

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

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 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

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

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

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