[geloest] hohe loadavg von 1.00 bei "0" Last

gerdh · Feb 7th 2017

Hallo !

ich habe jetzt mal mit Ubuntu 16.04 meinen "Server" neu aufgesetzt und separat laufen lassen (drin hab ich ein easyraid mit 2x Samung EVO SSD)
Er lief die Ganze Zeit parallel zum alten (und da war alles paletti)
Diese Wochenende hab ich in dann umgesetzt (sprich Platten in den "alten" rechner) und seitdem hat er quasi im Leerlauf ne Hohe Load von 1.00
Ich hab jetzt mal zu Probe die Platte ohne Raid laufen lassen, aber das aendert nichts.
Es gibt vom Probelauf Rechner nur 3 Unterschiede
Testrechner hatte einen i7 "Server hat einen i5
Testrechner hat eine GTX560 "Server" hat eine GT630
Beide haben 16 GB Ram und eine SSD
nur der "Server" hat ein PCIe DD V6 mit 4 Anschlüssen im SCR Modus

Ich hab schon mit iotop und Konsorten alles durch. Wo kann ich noch suchen um rauszufinden woher die grosse Load kommt...

Gruss Gerd

fnu · Feb 7th 2017

1.0 ist kein großer Load, das sagt nur aus das im Mittel ein Prozess auf CPU Zeit wartet, die Gründe dafür können vielfältig sein. Ich würde das als Normalbetrieb bezeichnen, das System tut ja immer irgendwas ...

Ein hoher Load-Wert ist für mich 2-3 pro Core ... also 8-12 bei einer Quad Core CPU.

Regards
fnu

henfri · Feb 8th 2017

Hallo,

ich kenne das Problem (habe das gleiche).
Ich finde es dennoch komisch, bei einer gesamt CPU-Auslastung von 6% wartende Prozesse zu haben...

Gruß,
Hendrik

gerdh · Feb 8th 2017

Hallo !

Genau das meine ich.... der Rechner macht nicht wirklich was idle cpu liegt zwischen 98 und 99,9 % und trotzdem nach load von 1.0 (ich hatte sogar vdr und tvh beendet)

Code

top - 09:40:44 up 11:01,  2 users,  load average: 1,12, 1,10, 1,09
Tasks: 353 gesamt,   1 laufend, 352 schlafend,   0 gestoppt,   0 Zombie
%CPU(s):  0,9 be,  0,3 sy,  0,1 ni, 98,1 un,  0,5 wa,  0,0 hi,  0,1 si,  0,0 st

UNd wie gesagt vorher war es annaehernd der gleiche PC (exakt das selbe Board mit der selben BIOS Version und es hatte ne Load von 0.02 bis 0.2 im idle.
Ich werde mich mal dran machen und heute abend mal die DD PCIe Karte rausmachen... mal schaun ob es dann besser wird.

Wie kann ich rausfinden auf welchen Prozess die CPU grad wartet ?

Gruss Gerd

gda · Feb 8th 2017

Quote from gerdh

Wie kann ich rausfinden auf welchen Prozess die CPU grad wartet ?

Das muss ja kein Prozess sein, der Kernel ist ja auch noch da. Die DD-Karte erzeugt doch ständig Interrupts, ob da nun jemand darauf wartet, oder nicht ist egal. Bei jedem Interrupt wird der Interrupt-Handler des Kernel-Treibers aufgerufen.

Mit

Code

watch cat /proc/interrupts

kannst du sehen was da so passiert.

Gerald

_Martin_ · Feb 8th 2017

Load bedeutet nicht das ein Prozess auf CPU warted. Sondern auf eine Ressource (was natürlich CPU sein kann).
Ein hoher Load bei wenig CPU Auslastung ist in der Regel das warten auf I/O z.B. der Festplatte.

Prüfen kannst du das z.B. mit folgendem Befehl

Code

iostat -x 1

iostat ist unter debian im Paket sysstat

Grüße
Martin

gda · Feb 8th 2017

Quote from _Martin_

Load bedeutet nicht das ein Prozess auf CPU warted. Sondern auf eine Ressource (was natürlich CPU sein kann).
Ein hoher Load bei wenig CPU Auslastung ist in der Regel das warten auf I/O z.B. der Festplatte.

Richtig, aber wenn der Unterschied zwischen System 1 und 2 nur die DD-Karte ist, dann bezweifele ich, dass es am I/O liegt. Die DD-Karte erzeugt ja keinen traffic auf der Platte.

Gerald

fnu · Feb 8th 2017

Quote from henfri

bei einer gesamt CPU-Auslastung von 6% wartende Prozesse zu haben...

Ich nicht, weil immer Prozesse auf einem Server laufen und immer einer auf CPU Zeit wartet und sei es nur 1 Nanosekunde. Und selbstredend kann sich das von Version zu Version ändern, Kernel, cgroups, AppArmor/SELinux, SysV Init/systemd, etc. Stromsparmassnahmen schlagen auch hier durch, ein "gedämpfteres" System reagiert logischerweise auch langsamer auf systemcalls. Wenn früher die Anstiegskurve steiler war, ging der CPU Takt schneller Richtung Zieltakt, als wenn diese heute etwas flacher ausfällt .. nur ein paar Beispiele.

Warum hängt Ihr Euch an so einem statistischen Wert auf? Macht das Problem doch mal konkret fest. Läuft der Server schlechter, langsamer als vorher? Nimmt er mehr Leistung auf? Oder stört Euch nur die Zahl in top?

"htop" ist hier IMHO die bessere Variante, zeigt auch mehr Details.

Regards
fnu

fnu · Feb 8th 2017

Quote from _Martin_

Load bedeutet nicht das ein Prozess auf CPU warted.

Ich habe auch geschrieben "CPU Zeit", das ist ein Himmel-weiter Unterschied, bitte richtig lesen und zitieren! Es geht um Wartezeit im Scheduler des Systems.

Regards
fnu

_Martin_ · Feb 8th 2017

Quote from gda

Richtig, aber wenn der Unterschied zwischen System 1 und 2 nur die DD-Karte ist, dann bezweifele ich, dass es am I/O liegt. Die DD-Karte erzeugt ja keinen traffic auf der Platte.

Ich habe geschrieben z.B. Platte. I/O meine ich eigentlich alles was auf dem BUS läuft, dies kann auch Netzwerk oder eine DD-Karte sein, etc..

Quote from fnu

Ich habe auch geschrieben "CPU Zeit", das ist ein Himmel-weiter Unterschied, bitte richtig lesen und zitieren! Es geht um Wartezeit im Scheduler des Systems.

Dies war nicht auf dich bezogen sondern allgemein. Da viele Nutzer Load mit CPU gleichsetzen was nicht stimmt, also bitte nicht persönlich nehmen (ich hatte ja auch nicht zitiert )

Grüße
Martin

fnu · Feb 8th 2017

_Martin_

Auch I/O geht voll auf/über die CPU, wie generell gar nichts im System ohne den Hauptprozessor geht. Was willst Du also damit sagen, Load hat nichts mit CPU zu tun?

Regards
fnu

_Martin_ · Feb 8th 2017

Hmm vielleicht nicht konkret ausgedrückt. Ich will einfach nur sagen das ein hoher Load Wert nicht mit einer hohen CPU Auslastung gleichzusetzen ist.
Ich habe schon Systeme gehabt die eine CPU Auslastung von 5% hatten aber einen Load von > 40 und mehr.
Bei mir in der Praxis lag dies häufig am Netz, NFS share oder Festplatte.

Dies muss aber von Fall zu Fall untersucht werden.

fnu · Feb 8th 2017

Martin, das hat hier doch auch keiner geschrieben, weder gerdh, henfri noch ich. gerdh schreibt in seinem ersten Posts nichts von CPU Auslastung, es ging um die Erklärung des statistischen Werts "load", welchen er mit "1.0" also hoch bewertet. henfri fragt das gleiche an, ohne etwas über eine hohe CPU Auslastung zu sagen ...

Ich hatte es vereinfacht als wartende Prozesse auf CPU Zeit beschrieben. Etwas komplexer formuliert sind es Systemanfragen die auf ein Fenster im Scheduler des Systems ("mit seinem Gottvater CPU") warten. Das könnte auch ein Treiber sein ...

Im Umkehrschluss hast Du aber schon auch recht, eine "load" von "3.0" heißt nicht zwingend das die CPU großartig belastet sein muss ...

Gruß
Frank

_Martin_ · Feb 8th 2017

Dann belassen wir es jetzt dabei und warten was gerd sagt woran es lag

Grüße
Martin

gerdh · Feb 8th 2017

Hallo !

Nun macht mal wieder etwas langsam
Ich wundere mich nur weil beim Selben System (wie oben erwaehnt) der idle load von einem relativ (üblichen) niedrigen Wert auf 1 gestiegen ist.
(FYI auch die netzwerkanbindung ist identisch nur eben andere IP)
Mich interessiert eben wo das auf einmal herkommt wobei ich ja weiss das HDD und CPU sich langweilen....

Ich werde heute abend mal die DD rausbauen und danach sehe ich ja was passiert.

Gruss Gerd

Code

Alle 2,0s: cat /proc/interrupts                                                                                       	Wed Feb  8 11:19:38 2017


       	CPU0   	CPU1   	CPU2   	CPU3
  0:     	20      	0      	0      	0  IR-IO-APIC   2-edge  	timer
  1:      	2      	0      	0      	0  IR-IO-APIC   1-edge  	i8042
  4:      	3      	0      	1      	0  IR-IO-APIC   4-edge
  5:      	0      	0      	0      	0  IR-IO-APIC   5-edge  	parport0
  8:      	1      	0      	0      	0  IR-IO-APIC   8-edge  	rtc0
  9:      	0      	0      	0      	0  IR-IO-APIC   9-fasteoi   acpi
 12:      	3      	0      	1      	0  IR-IO-APIC  12-edge  	i8042
 16:   	2341   	4701	2876354	7438557  IR-IO-APIC  16-fasteoi   DDBridge
 17:    	539    	318    	112     	88  IR-IO-APIC  17-fasteoi   snd_hda_intel
 19:  	17583  	11131   	5041 	989802  IR-IO-APIC  19-fasteoi   ata_piix, ata_piix
 23:   	1230  	95542  	38532  	36734  IR-IO-APIC  23-fasteoi   ehci_hcd:usb1, ehci_hcd:usb2
 24:      	0      	0      	0      	0  DMAR-MSI   0-edge  	dmar0
 26:  	10644   45723809   	2730   	2452  IR-PCI-MSI 327680-edge  	xhci_hcd
 27:   	2131	1338880    	441    	301  IR-PCI-MSI 1572864-edge  	enp3s0
 28:     	15      	0     	10      	0  IR-PCI-MSI 360448-edge  	mei_me
 29:    	416      	4     	23      	7  IR-PCI-MSI 442368-edge  	snd_hda_intel
 30:    	495    	196	1124031     	95  IR-PCI-MSI 524288-edge  	nvidia
NMI:    	106    	203    	130    	150   Non-maskable interrupts
LOC:   10822210   10987743   10125251   10510126   Local timer interrupts
SPU:      	0      	0      	0      	0   Spurious interrupts
PMI:    	106    	203    	130    	150   Performance monitoring interrupts
IWI:      	0      	1      	0      	0   IRQ work interrupts
RTR:      	0      	0      	0      	0   APIC ICR read retries
RES: 	117074 	156661  	91142 	104377   Rescheduling interrupts
CAL:   	2218   	2292   	1956   	2396   Function call interrupts
TLB: 	115792 	142236 	124973 	107154   TLB shootdowns
TRM:      	0      	0      	0      	0   Thermal event interrupts
THR:      	0      	0      	0      	0   Threshold APIC interrupts
DFR:      	0      	0      	0      	0   Deferred Error APIC interrupts
MCE:      	0      	0      	0      	0   Machine check exceptions
MCP:    	154    	154    	154    	154   Machine check polls
ERR:      	0
MIS:      	0
PIN:      	0      	0      	0      	0   Posted-interrupt notification event
PIW:      	0      	0      	0      	0   Posted-interrupt wakeup event

Display More

fnu · Feb 8th 2017

gerdh

"atop" ist ein ganz hilfreiches Werkzeug für Realtime Monitoring. Benötigt aber das Du Dich etwas einliest ...

Regards
fnu

umaier · Feb 8th 2017

Top zeigt ja schon, dass er waits hat.

Gleichzeitig schlaegt da mit Sicherheit der Energiesparmodus zu und taktet die CPU runter. Dann spendiert die unter Umstaenden tatsaechlich alle verfuegbaren Takte aufs Warten.
Die Ausgabe von cpufreq-info ist in dem Zusammenhang interessant.

Mit load von 1.0 bei minimalem Takt laesst sich hervorragend leben. Das zeigt nur, dass das System optimal reagiert.
Ich persoenlich bin erst beunruhigt, wenn der Load groesser als die Anzahl der Kerne auf der Kiste ist; dann laeuft was schief.

uwe

gda · Feb 8th 2017

Quote from umaier

Mit load von 1.0 bei minimalem Takt laesst sich hervorragend leben. Das zeigt nur, dass das System optimal reagiert.
Ich persoenlich bin erst beunruhigt, wenn der Load groesser als die Anzahl der Kerne auf der Kiste ist; dann laeuft was schief.

Sehe ich genauso, ein System, dass die meiste Zeit gegen 0 load hat ist dramatisch überdimensioniert.

Gerald

ciax · Feb 8th 2017

.. das ist so eine Sache, wie "load" zu interpretieren ist, gell

Ein "System mit 12 Kernen" und einem load von 6 reagiert ziemlich zackig, auch beim Zugriff über's Netz zB. Wenn es dann Richtung load 12+ geht, merkt man's dann aber schon - das halt "gefühlt" (load eben )

Gruß

gerdh · Feb 8th 2017

Hi !

ist ja interessant 12 kerne... da hoffe ich noch auf 6 aus 49
Aber zum Thema DD ist draussen => keine Änderung

cpufreq-info

Code

CPU 0
  momentane Taktik: die Frequenz soll innerhalb 1.60 GHz und 3.30 GHz.
  momentane Taktfrequenz ist 1.64 GHz.
  CPU 1
  momentane Taktik: die Frequenz soll innerhalb 1.60 GHz und 3.30 GHz.
  momentane Taktfrequenz ist 1.60 GHz.
  CPU 2
  momentane Taktik: die Frequenz soll innerhalb 1.60 GHz und 3.30 GHz.
  momentane Taktfrequenz ist 1.60 GHz.
  CPU 3
  momentane Taktik: die Frequenz soll innerhalb 1.60 GHz und 3.30 GHz.
  momentane Taktfrequenz ist 1.60 GHz.

Display More

Ich hab jetzt mal zum Vergleich
das ganz Alte system lief mit 14.04 einem i3-3220T auch so um die 0.4 Loadavg und das hatte als min Frequenz 1800 MHz
das zum testen lief mit einen I7-3570K... hier hab ich jetzt einen i5-3570T

BTW: der scaling governor ist aktuell anscheinend powersave, ich probier mal ondemand

Gruss gerd

[geloest] hohe loadavg von 1.00 bei "0" Last

Participate now!

Share