Magic numbers in linux -load average's nl

Door ameesters op dinsdag 23 augustus 2011 11:56 - Reacties (16)
Categorie: Linux, Views: 4.168

Omdat mensen veelal de load averages in linux fout interpreteren, ga ik hier een beknopte, maar, een vooral duidelijke uitleg te geven(hoop ik).

Iedereen die wel eens in linux komt, kent deze getalletjes wel,


Bash:
1
load average: 0.23, 0.24, 0.25



Zo niet typ in bash:

Bash:
1
uptime



Aangezien er vaak onduidelijkheid bestaat over wat deze getalletjes doen, zal ik het hier proberen uit te leggen.

De getallen representeren het gebruik van de processor. Waarbij de eerste het gebruik van 1 minuut weer geeft, de 2e het gebruik van 5 minuten weer geeft, en de 3e 15 minuten representeerd.

Wat vaak gezegd word is dat het getal het precentage weer geeft wat de processen gebruiken van de processor. Dit is niet waar. Een processor verwerkt een process, of doet niks. Een processor kan niet een bepaald percentage aan een process toewijzen om het uit te voeren. Een processor doet iets, of niets, maar kan dus niet iets een beetje doen.

Wat houd het getalletje dan in? Het getal representeerd de queue, de wachtrij van processen die verwerkt moeten worden. Dus als je 1 single core processor hebt, dan is 1.00 het beste getal dat je kan hebben, er worden geen processen in een queue gestopt maar de processor staat ook niet niks te doen. Lekker productief dus.

Vaak raken mensen in paniek als dat getalletje boven de 1 uit komt. dat is alleen nodig als je 1 core/processor heb.
Dus om een voorbeeldtje van een server op het werk te pakken, met een 2xquadcore's,


Bash:
1
load average: 6.22, 6.12,  6.03



Veel mensen zouden in paniek raken, maar het ideale getal zou op deze server:

Bash:
1
load average: 8.00, 8.00,  8.00


Moeten zijn.

Dus mensen, raak alstublieft niet meteen in paniek als je systeem aangeeft dat hij het "druk" heeft. een productieve server is niks mis mee!

Ik heb dit express beknopt gehouden, "for the sake of simplicity", voor mensen die er meer van willen weten, stel ik voor dat ze de bron vermelding even lezen.

bron: Linux Journal

Volgende: Wat denken tweakers hier van. 10-'13 Wat denken tweakers hier van.
Volgende: Trip down memory lane - Een introductie 08-'11 Trip down memory lane - Een introductie

Reacties


Door Tweakers user woekele, dinsdag 23 augustus 2011 16:18

Moet je bij een cpu met hyperthreading dan ook 2.00 hebben? :)

Door Tweakers user ameesters, dinsdag 23 augustus 2011 16:20

woekele schreef op dinsdag 23 augustus 2011 @ 16:18:
Moet je bij een cpu met hyperthreading dan ook 2.00 hebben? :)
Nee, linux ziet de virtueele cpu ook gewoon als een cpu, maar omdat het virtueel is, loopt alsnog je queue op, in het geval van hyperthreading gaat dit dus niet op.

edit:
sorry, had een brainfart

[Reactie gewijzigd op dinsdag 23 augustus 2011 16:23]


Door Tweakers user AtleX, dinsdag 23 augustus 2011 16:31

Het is niet puur de processorload. ;) Ik kan een IO van <heelhoog> hebben en een CPU usage van praktisch nul en daardoor toch een hoge load. De relatie met het aantal processoren in je systeem klopt dus ook niet. ;)

Daarnaast kan je een heel hoge belasting hebben met een heel lage loadfactor de afgelopen 1/5/15 (de tijdsperiode van die 3 getallen) minuten. Als er maar 1 proces de server bezig houd kom je toch maar op of rond de 1 uit.

[Reactie gewijzigd op dinsdag 23 augustus 2011 16:35]


Door Tweakers user Voxyn, dinsdag 23 augustus 2011 16:38

Haha als ik dit eerder geweten hadI Ik heb wel is een keer ubuntu hierdoor opnieuw ge´nstalleerd toen ik dacht dat hij zelfs bij het zippen maar 1.00% gebruikte.

[Reactie gewijzigd op dinsdag 23 augustus 2011 16:38]


Door Tweakers user ameesters, dinsdag 23 augustus 2011 16:40

AtleX schreef op dinsdag 23 augustus 2011 @ 16:31:
Het is niet puur de processorload. ;) Ik kan een IO van <heelhoog> hebben en een CPU usage van praktisch nul en daardoor toch een hoge load. De relatie met het aantal processoren in je systeem klopt dus ook niet. ;)
Quote van het bron artikel:
In fact, it is precisely the CPU load that is measured, because load averages do not include any processes or threads waiting on I/O, networking, databases or anything else not demanding the CPU.
;)

Door Tweakers user froggie, dinsdag 23 augustus 2011 18:16

In het kort geven deze getallen het aan hoeveel processen er gemiddeld in de runnable queue staan over een periode van 1, 5 en 15 minuten. Runnable processen zijn in dit geval processen die CPU cycles nodig hebben om verder te komen (en dus niet suspended zijn omdat ze bijvoorbeeld wachten op IO).
Het is geen enkel probleem dat de load boven de N uit komt (voor N CPU's), dit betekent alleen dat er wachtende processen zijn en de hoeveelheid beschikbare CPU cycles de bottleneck vormt voor je prestaties. Voor een 1 minute average is dit nog niet zo'n probleem, maar is de 15 minute average constant boven N dan is het verstandig meer CPU's toe te voegen om de workload sneller te kunnen verwerken.

[Reactie gewijzigd op dinsdag 23 augustus 2011 18:23]


Door Tweakers user A_K, dinsdag 23 augustus 2011 20:53

Dus als je 1 single core processor hebt, dan is 1.00 het beste getal dat je kan hebben, er worden geen processen in een queue gestopt maar de processor staat ook niet niks te doen. Lekker productief dus.
Het gemiddelde is 1.
Het kan dus dat driekwart de cpu niks staat te doen, er een kwart van de tijd 3 processen staan te wachten. Over het algemeen: hoe lager, hoe beter.

Door Tweakers user 0siris, dinsdag 23 augustus 2011 21:17

Hoe lager, hoe beter is natuurlijk een mooi uitgangspunt, maar als er dit staat:

code:
1
load average: 0.00, 0.00, 0.00


dan mag je toch aan je baas gaan uitleggen waarom je niet een wat lichtere machine hebt aan laten rukken :P

Door Tweakers user IStealYourGun, woensdag 24 augustus 2011 09:16

ameesters schreef op dinsdag 23 augustus 2011 @ 16:40:
[...]


Quote van het bron artikel:

[...]


;)
En toch heeft AtleX een punt omdat het afhankelijk is van veel factoren.
Als je HDD zeer druk bezig is dan kan de load ook de lucht inschieten zonder dat je CPU iets aan het doen is. Dat komt dan door iowait doordat je HDD niet kan volgen.

Door Tweakers user ameesters, woensdag 24 augustus 2011 10:13

IStealYourGun schreef op woensdag 24 augustus 2011 @ 09:16:
[...]


En toch heeft AtleX een punt omdat het afhankelijk is van veel factoren.
Als je HDD zeer druk bezig is dan kan de load ook de lucht inschieten zonder dat je CPU iets aan het doen is. Dat komt dan door iowait doordat je HDD niet kan volgen.
Maar dit artikel gaat over cpu, niet disk io of netwerk io. Die worden niet mee genomen in de load averages, dus niet relevant op dit artikel. Je load kan 0.00 zijn en toch super traag omdat je netwerk verbinding het niet aan kan.

Ik denk dat ik het artikel toch even ga uitbreiden om dat wat duidelijker te krijgen.

[Reactie gewijzigd op woensdag 24 augustus 2011 10:14]


Door Tweakers user IStealYourGun, woensdag 24 augustus 2011 11:49

ameesters schreef op woensdag 24 augustus 2011 @ 10:13:
[...]


Maar dit artikel gaat over cpu, niet disk io of netwerk io. Die worden niet mee genomen in de load averages, dus niet relevant op dit artikel. Je load kan 0.00 zijn en toch super traag omdat je netwerk verbinding het niet aan kan.

Ik denk dat ik het artikel toch even ga uitbreiden om dat wat duidelijker te krijgen.
Daar maak je juist de fout. Bij Unix is de load enkel gelinkt aan de actieve processen, maar onder Linux word er rekening gehouden met het hele systeem inclusief de wachtende processen. De fout die iemand zou kunnen maken is door een hoge load te linken aan een te "trage" CPU of een CPU die niet meekan. Maar het kan heel goed zijn dat je HDD gewoon veel I/O fouten geeft en bijna stuk is. Of je RAM te weinig is waardoor er veel moet worden geswaped.
However, Linux also includes processes in uninterruptible sleep states (usually waiting for disk activity), which can lead to markedly different results if many processes remain blocked in I/O due to a busy or stalled I/O system. This, for example, includes processes blocking due to an NFS server failure or to slow media (e.g., USB 1.x storage devices). Such circumstances can result in an elevated load average, which does not reflect an actual increase in CPU use (but still gives an idea on how long users have to wait).
https://secure.wikimedia....ix-style_load_calculation

[Reactie gewijzigd op woensdag 24 augustus 2011 11:51]


Door Tweakers user Paradox, woensdag 24 augustus 2011 12:32

Mijn synology NAS heeft dit nu, load average: 0.40, 0.19, 0.05

ik neem aan dat de processor flink druk kan krijgen...

Door Tweakers user mrc4nl, woensdag 24 augustus 2011 12:36

dit vraag ik me idd al een tijdje af, want ik kan ook een systeemmonitor applet gebruiken, en na het opstarten is de hele balk rood, terwijl de systeembelasting "slechts" 15 is..

Door Tweakers user SKiLLa, woensdag 24 augustus 2011 16:41

Voxyn schreef op dinsdag 23 augustus 2011 @ 16:38:
Haha als ik dit eerder geweten hadI Ik heb wel is een keer ubuntu hierdoor opnieuw ge´nstalleerd toen ik dacht dat hij zelfs bij het zippen maar 1.00% gebruikte.
OMGWTF, daar heb je toch Google voor ... je gaat toch niet zomaar een bak opnieuw installeren zonder een beetje onderzoek :? 8)7

Door Tweakers user _JGC_, donderdag 25 augustus 2011 12:34

Op linux wordt juist wel alles meegenomen in de load. Stel je hebt een NFS mount met "hard" optie gemount, je zet de NFS server uit en je doet een "ls" op de NFS mount. Die "ls" hangt zichzelf op omdat de NFS server niet meer te bereiken is, de load stijgt naar 1.00, maar de rest van het systeem heeft totaal geen last van die "hoge" load.
Vervolgens start je nog 10x "ls" op die NFS share, gevolg is dat je load naar 11.00 schiet, maar behalve dat getalletje en 11 draaiende ls processen die hangen omdat er geen NFS server is, merk je helemaal niks aan het systeem.

Door Tweakers user jediah, vrijdag 7 oktober 2011 19:17

Want kinderen, een luie server kun je beter uit het rek halen. Want dat is zonde!

Reactie formulier
(verplicht)
(verplicht, maar wordt niet getoond)
(optioneel)

Voer de code van onderstaand anti-spam plaatje in: