Logica belasting cpu?

[sdk1985]

top - 18:27:46 up 21 days, 44 min,  1 user,  load average: 2.14, 2.57, 2.05
Tasks: 171 total,   4 running, 166 sleeping,   0 stopped,   1 zombie
Cpu(s):  6.5%us,  3.3%sy,  3.3%ni, 41.3%id, 45.3%wa,  0.0%hi,  0.0%si,  0.2%st
Mem:   1881136k total,  1861300k used,    19836k free,    77072k buffers
Swap:  2097148k total,   237104k used,  1860044k free,   923712k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 4227 gpi       39  19  4300  772  392 R  6.3  0.0   0:36.51 gzip
 1384 teamspea  20   0 1132m  16m 2592 S  2.0  0.9 436:14.11 ts3server_linux

Hieronder is de cpu load 0.0.

Kan iemand dit logisch interpreteren.

Ik zie dit nu zo:
load 2.14>er is meer load dan de 2 cores aankunnen
41.3%id >Er wordt 41.3 % van de capaciteit niet gebruikt
45.3%wa>Er wordt 45.3% gewacht op de IO
user gpi gebruikt 6.3% van de cpu voor een gzip operatie.

Dit alles samen komt op mij nogal onlogisch over. Waarom is die gzip niet 80%+? Waarom is er 41.1% idle? Is er nu ook nog 45% in de wacht? Dat verklaart dan dat er maar 6% cpu load is... Maar in dat geval is er geen load van 2.11 nodig lijkt me.

Er is vast iemand met een logische verklaring .

[ Voor 9% gewijzigd door sdk1985 op 18-09-2015 18:37 ]

[Hero of Time]

Load is niet alleen CPU belasting, het is ook I/O dat meegeteld wordt. Je load van 2 komt door hevig gebruik van de harde schijf. En je hebt 1 zombie proces, dat voegt nog eens 1.00 toe aan de load (als ik 't goed heb).

Je kan met Google heel veel informatie vinden over hoe de load bepaald wordt. Wat heb je er zelf van gevonden en wat snap je daar niet van?

[sdk1985]

Ik heb me van de week in load verdiept. Zie: http://blog.scoutapp.com/...derstanding-load-averages

Dat verhaal matched dus niet met hetgeen jij nu noemt.

Verder lees ik top uit op basis van : http://linuxaria.com/howt...-the-top-command-on-linux

Ik kijk hierna omdat het voor mij onlogisch is dat ik op de server status gigantische load pieken ze en dan bij de processen kijk en dan een zippertje 6% zie doen. Ondertussen is de server wel onwijs traag. Het duurt me ook allemaal veel te lang. (Die server gaat er dus ook uit, maar uitlezen wat er überhaupt is lijkt me erg prettig).

Maar als ik het dus goed begrijp is de cpu load van de zipper zo laag omdat 45% op de hdd zit te wachten en de overige 41% lekker idle is omdat de queue toch al te hoog is. Dit wordt vervolgens toch als load 2.x weergeven omdat load dus niet de cpu aangeeft. Right?

[ Voor 7% gewijzigd door sdk1985 op 18-09-2015 20:47 ]

[Thralas]

Ja, dat klopt volgens mij wel ongeveer. Je hebt een I/O issue.

Als je dit verder debugged met bv. iostat dan zie je als het goed is een constante 100% util van je disk.

[Hero of Time]

Een andere pagina (howtogeek) heeft het ook over disk read en write. Als je een gzip uitvoert van een grote hoeveelheid data die je laat inpakken op diezelfde schijf, dat ook je root file system huisvest, dan is het niet vreemd dat je systeem niet vooruit te branden is. De schijf staat enorm uit z'n plaat te gaan. Dat is ook de reden waarom sommige systemen met een load van <1.00 traag als stroop kunnen zijn, terwijl anderen een load van >10.00 hebben en nog even smooth aanvoelen.

[CAPSLOCK2000]

load 2 = er zijn twee processen die de CPU willen gebruiken, dat zegt niks over of ze dat ook doen. Ze willen het, maar misschien moeten ze wel wachten, bv op IO.

Je hebt twee cores, iedere core is dus 50%. Ik denk dat de verwarring ontstaat omdat niet duidelijk is dat die percentages voor beide cores samen zijn maar dat ZIP slechts 1 core gebruikt. In het meest ideale geval, waarin de die core nooit op de HD hoeft te wachten, zou ZIP maximaal 50% CPU gebruiken omdat die andere core idel blijft.

ZIP gebruikt dus 1 core, de andere core staat (bijna) niks te doen. Die 41.3% idle is voor rekening van de core die bijna niks staat te doen. De 45.3% IO-wait is de andere core, die wil ZIP draaien maar staat op de HD te wachten, vandaar dat er slechts 6.3% CPU door ZIP wordt gebruikt.

[gekkie]

Als je machine er semi onbruikbaar door wordt zou je kunnen overwegen om de prioriteit van het proces wat naar beneden te schroeven met "ionice" van (van best-effort naar idle). Het zippen zal afhankelijk van hoeveel je er naast gaat doen wel wat langzamer gaan, maar de handel blijft wel wat meer responsive.

[ Voor 27% gewijzigd door gekkie op 18-09-2015 22:59 ]

[sdk1985]

CAPSLOCK2000 schreef op vrijdag 18 september 2015 @ 22:16:
load 2 = er zijn twee processen die de CPU willen gebruiken, dat zegt niks over of ze dat ook doen. Ze willen het, maar misschien moeten ze wel wachten, bv op IO.

Je hebt twee cores, iedere core is dus 50%. Ik denk dat de verwarring ontstaat omdat niet duidelijk is dat die percentages voor beide cores samen zijn maar dat ZIP slechts 1 core gebruikt. In het meest ideale geval, waarin de die core nooit op de HD hoeft te wachten, zou ZIP maximaal 50% CPU gebruiken omdat die andere core idel blijft.

ZIP gebruikt dus 1 core, de andere core staat (bijna) niks te doen. Die 41.3% idle is voor rekening van de core die bijna niks staat te doen. De 45.3% IO-wait is de andere core, die wil ZIP draaien maar staat op de HD te wachten, vandaar dat er slechts 6.3% CPU door ZIP wordt gebruikt.

Oké daar had ik nog niet aan gedacht (dat gzip single core is ) . Dan is de puzzel onderhand wel compleet.

Hero of Time schreef op vrijdag 18 september 2015 @ 21:48:
Een andere pagina (howtogeek) heeft het ook over disk read en write. Als je een gzip uitvoert van een grote hoeveelheid data die je laat inpakken op diezelfde schijf, dat ook je root file system huisvest, dan is het niet vreemd dat je systeem niet vooruit te branden is. De schijf staat enorm uit z'n plaat te gaan. Dat is ook de reden waarom sommige systemen met een load van <1.00 traag als stroop kunnen zijn, terwijl anderen een load van >10.00 hebben en nog even smooth aanvoelen.

Betreft hier een VPS. In het verleden piekte de storage laag hier op 20k-30K iops, momenteel bleef zelfs een delete (van veel files) steken op 800 a 1700 iops.

Overigens apart dat die gzip niet standaard nice is. Daar zal ik me toch nog eens in moeten verdiepen.

Ik ben ondertussen in ieder geval gemigreerd naar een SSD gebaseerde machine (dit was een HDD cluster met SSD caching) .

top - 01:58:19 up 2 days, 12:02,  1 user,  load average: 0.44, 0.16, 0.09
Tasks: 174 total,   2 running, 172 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  1.9%sy, 42.6%ni, 45.9%id,  0.0%wa,  0.0%hi,  0.2%si,  9.5%st
Mem:   1922192k total,  1846544k used,    75648k free,    38460k buffers
Swap:  1047548k total,    20464k used,  1027084k free,  1013852k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
21210 gpi    39  19  4300  736  392 R 100.0  0.0   0:15.57 gzip
20891 root      20   0 15024 1324  944 R  7.0  0.1   0:01.48 top

[ Voor 15% gewijzigd door sdk1985 op 19-09-2015 01:59 ]

[CAPSLOCK2000]

(Bijna) niks is standaard nice. Het OS gaat dat niet voor jouw beslissen.

IO is het zwakke punt van alle VPSen en daar heb je zelf maar weinig invloed op. Als het onderliggende systeemn niet genoeg IOPS kan leveren dan houdt het vrij snel op.
20-30k iops vind ik overigens extreem veel. 800-1700 iops vind ik eigenlijk al ontzettend veel voor een VPS.

[sdk1985]

Tja dat zijn de pieken die op de interface te zien zijn. Dat kunnen natuurlijk ook cached iops zijn.

Ze zijn overigens wel hardware reserved, ik zocht juist een vps met meer iops dan een (betaalbare) dedicated server mij kon bieden.

Het oude platform is in ieder geval niet meer wat het is geweest. Ik heb ondertussen ook een box draaien op het nieuwe platform. Aanzienlijke verschillen:

Oud:
IOPing I/O: 10 requests completed in 9198.8 ms, 51 iops, 0.2 mb/s
IOPing seek rate:149 requests completed in 3180.7 ms, 47 iops, 0.2 mb/s
IOPing sequential:1745 requests completed in 3000.2 ms, 643 iops, 160.8 mb/s
IOPing cached:23986 requests completed in 3000.1 ms, 191031 iops, 746.2 mb/s

Oud in februari:
IOPing I/O: 10 requests completed in 9007.5 ms, 1783 iops, 7.0 mb/s
IOPing seek rate:5414 requests completed in 3001.0 ms, 2943 iops, 11.5 mb/s
IOPing sequential:2931 requests completed in 3000.8 ms, 1227 iops, 306.9 mb/s
IOPing cached:17614 requests completed in 3000.0 ms, 213307 iops, 833.2 mb/s

Dat ding is dus gigantisch onderuit gezakt. Zie ook nieuw platform zelfde leverancier:
IOPing I/O: 10 requests completed in 9002.8 ms, 5467 iops, 21.4 mb/s
IOPing seek rate:11217 requests completed in 3000.4 ms, 6483 iops, 25.3 mb/s
IOPing sequential:4373 requests completed in 3000.4 ms, 1774 iops, 443.5 mb/s
IOPing cached:27294 requests completed in 3000.0 ms, 419372 iops, 1638.2 mb/s

Ik vermoed dat dit platform SSD gebaseerd is want die scores zijn hoger dan wat ik met mijn ssd gebaseerde machines haal...

[ Voor 40% gewijzigd door sdk1985 op 20-09-2015 00:55 ]