Hoge Wait CPU belasting

[deepbass909]

Ik ben bezig foto's te importeren in m'n coppermine gallerij, en dat gaat erg traag. Nu zit ik in top te kijken, en blijkt dat convert (dat van elke foto een verkleinde versie en een thumbnail maakt) maar een 3 - 8 % user cpu belasting veroorzaakt.
Maar m'n wait CPU-belasting zit continu op rond de 80%. Ik weet dat de wait-belasting inhoudt dat het een proces staat te wachten op een externe factor, bijvoorbeeld een harddisk.

Omdat m'n wait belasting zo hoog is, wil ik graag weten wat de bottle nek is. Vooral omdat hij het voorheen aanzienlijk sneller deed...

Even een klein overzicht:

code:

user:   +/- 15%
system: +/-  3%
nice:        0%
idle:        0%
wait:   +/- 82%

dat is dus weinig efficiënt te noemen...
systemspecs:

code:

cpu:      Intel Celeron Mendocino 333Mhz
geheugen: 160MB
Swap:     500MB, 390MB vrij

Verder staat de swap op een andere hardeschijf dan waar ik op werk, en betreft het SCSI schijven.

[deepbass909]

Het lijkt inmiddels opgelost...

Ik heb aan m'n hosts file localhost.localdomain toegevoegd, en blijkbaar was dat het hele euvel...

Iets te vroeg gejuicht... het maakt wel iets verschil, maar m'n wait-load is nog steeds erg hoog...

[ Voor 32% gewijzigd door deepbass909 op 25-04-2006 10:35 ]

[xzenor]

Staat er niet heel er iets naar je harddisk weg te schrijven?
Het lijkt me dat als je een lading foto's gaat importeren dat die weggeschreven worden naar je hd..
Dat kan tijd kosten natuurlijk.... Kost waarschijnlijk meer tijd dan een fototje verkleinen.

Ik gok maar wat hoor.. hoe draait de boel als je'm geen foto's laat verkleinen eigenlijk?
Doet het't dan wel normaal?

[Verwijderd]

Zo maar even wat gedachten die in mij opborrelen:
- Welk proces veroorzaakt de vertraging. Convert, het php script van coppermine, mysql, etc?
- Er wordt gewacht op I/O, dit kan bijv. zijn netwerk I/O (wellicht inderdaad een gare DNS configuratie), disk I/O.
- Geheugengebruik / swapping?
- Disk vol?

Indien het disk I/O is, voer eens een dmesg uit of controleer kernel logging. Misschien dat er meldingen betreffende SCSI controllers / disken voorkomen.

probeer sdparm eens uit op je disken om je kijken of je transferrates in orde zijn.

[ShadowLord]

I/O wait is actief wachten op data. Bij netwerken is dit normaal niet van toepassing (een ander proces wordt dan ondertussen uitgevoerd). I/O wait is vooral HDD's of bijvoorbeeld communiceren over de PCI bus. De grote verdachte lijkt me hier dus je harddisk. Dat hij het eerst sneller deed kan een heel 'alledaagse' verklaring hebben: disk fragmentatie. Probeer dus eens een keer te defragmenteren. Wie weet hoe snel ie dan gaat

[Wilke]

Doe eens 'vmstat 1' runnen terwijl je dit doet, en daar de uitvoer van posten?

Disk fragmentatie? Nahhh....tenzij de disk praktisch vol is moet dat echt geen probleem zijn (tenzij het systeem al 15 jaar draait wellicht).

Convert is CPU-intensief, dit is dus wel vrij vaag. Zelf met een super-crappy HD zou ik verwachten dat CPU nog steeds het hoogst zit. Maar wie weet is daar met vmstat wat meer over te zien

[deepbass909]

Netwerk belasting kan het eigenlijk niet zijn, omdat de foto's al op de server staan, en alleen nog converteerd moeten worden.

De bronbestanden zijn tussen de 1 en 2 MB groot (5 megapixel jpg foto's), de uitvoer zijn 2 verkleinde versies (thumbnail en verkleinde versie), die enkele 10-tallen KB's groot zijn. Disc IO is onwaarschijnlijk, vooral omdat deze schijf normaal totaal geen problemen geeft... (ik kan van dezelfde schijf downloaden met 100KB/s over het internet).

Uitvoer vmstat 1

code:

andarve 060422 # vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  8 212640   2700   2104  85712    5    3     4     1    4     3 12  4 79  5
 0  9 212440   2828   2084  84540 2032 5544  2688  5556 1227   436  3  5  0 92
 0  9 211764   3304   2164  85492 1888 2380  2480  2392 1260   318  5  6  0 89
 0  9 211000   3888   2172  86448 2192 2032  2548  2036 1293   273  5  6  0 89
 0 10 210456   2304   2196  87644 2196   68  2824    68 1243   369  8  5  0 87
 0  9 209900   2536   2152  87960 2360 6904  3244  6912 1235   428 20 10  0 71
 0 11 206540   2188   2188  91440 2912 1700  3188  1724 1266   337 25  9  0 66
 0  8 204436   2828   2184  93440 2888 2396  3072  2396 1270   354 17  6  0 77
 0 10 202572   2288   2200  95488 2220 1084  2340  1096 1378   356 26  8  0 66
 0 11 201300   2368   2232  97304 1936    0  2568     4 1245   419 44  5  0 51
 0  9 199848   3424   2192  98408 1768 4876  2824  4876 1285   392 29  8  0 63
 6  7 199076   2412   2052 106544 1540  620  1972   652 1209   367 67 18  0 15
 8  7 199256   2480   1968 108192  716  120   852   120 1122   206 84 12  0  4
 0 11 198832   2184   1920 110544  796  232  1092   232 1162   281 85 11  0  4
 2  9 234640   2232   1864  81724  356 7780   680  7784 1352   327 34 36  0 30
 0 12 238496   2424   1868  81484  664 4656   892  4656 1329   281 21 12  0 67
 0 12 244472   2772   1868  81232  816 12124   820 12140 1463   363 23 14  0 63
 2  7 246536   3000   1868  94140  524 7764   784  7764 1315   336 70 22  0  8
 2  8 246380   2992   1880 107040  640 12804   900 12804 1317   450 64 22  0 14
 0 13 255764   2784   1880 107036  832 7984  1296  7996 1270   455 45 31  0 23
 0 15 266256   2428   1884 100312  652 2696   916  2696 1251   283 16 15  0 69
 0 14 276644   2472   1892  92888  792 1612   928  1612 1258   241 17 11  0 72

[deepbass909]

Ok,
blijkbaar is m'n swap vol gelopen... iets wat top niet aangeeft, maar swapon -s wel.

[_JGC_]

Uit je startpost:
Swap: 500MB, 390MB vrij

Wat betekent dat 110MB gebruikt wordt, wat nogal erg veel is als je ook laag aan je geheugen zit. Niet vreemd dat ie gaat hangen met I/O wait, je geheugen moet ook van de harddisk afkomen op deze manier.

[Verwijderd]

als si en so van vmstat in de duizenden lopen duidt dit op een hoge swapactiviteit.

[deepbass909]

het rare is, dat dit eerder niet het geval was... waarschijnlijk is een reboot op z'n plaats om wat hangende processen kwijt te raken (zo werkt op het moment m'n loop device ook niet meer...) en misschien toch maar eens wat extra geheugen op de kop tikken...

[Sir Isaac]

Is er een proces dat erg veel resident (niet-geswapt) memory gebruikt? Op die manier heeft firefox mijn computer wel eens op zijn knieen gekregen.

[Parasietje]

Ik zou in de richting zoeken van:
1) Memory leak. Herinstalleer convert en libjpeg eens.
2) Trage scheduler: misschien eens experimenteren met pre-emptive kernel, of een andere I/O scheduler gebruiken? Het lijkt me sterk dat er 140Mb aan actieve processen zijn die geheugen opslorpen zodat die 20Mb aan foto (5Mpx * 32bpp) er niet meer bijkan...

[deepbass909]

@ Parasietje
optie 1 zou inderdaad kunnen. Ik heb een system update in de tussentijd gedaan. M'n kernel is niet veranderd, dus optie 2 zou het eigenlijk niet kunnen zijn.

@Sir Isaac
Ik zit in m'n process list te kijken (nu draait er even geen zware taak), en de enige die eigenlijk geheugen bruiken dat in %-en loopt, zijn Apache2 en MySQL. En dan praat je bij Apache2 over 5% per process (er draaien er 12) en bij MySQL over 2,7% per process voor 10 processen. Beide overigens in het fysieke geheugen.
Misschien moet ik het aantal Child processen eens verlagen naar 5 per app.

Mijn huidige geheugen gebruik is als volgt:

code:

pandarve ~ # cat /proc/meminfo
MemTotal:       157204 kB
MemFree:          2652 kB
Buffers:          2156 kB
Cached:          91412 kB
SwapCached:       8532 kB
Active:          56472 kB
Inactive:        82456 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       157204 kB
LowFree:          2652 kB
SwapTotal:      504052 kB
SwapFree:       461332 kB
Dirty:               0 kB
Writeback:           0 kB
Mapped:          55220 kB
Slab:            11396 kB
CommitLimit:    582652 kB
Committed_AS:   255936 kB
PageTables:       1104 kB
VmallocTotal:   876504 kB
VmallocUsed:      2104 kB
VmallocChunk:   874332 kB

M'n fysieke geheugen is voor 98.3% gevult, maar dat is eigenlijk normaal bij Linux. M'n swap is op het moment maar voor 8.5% gevuld. Dat zijn iet echt rare waardes...
Maar als ik er zo over nadenk, is het wel zo dat Apache2 en MySQL de grootste geheugen gebruikers zijn, en juist deze 2 actief zijn tijdens het importeren van foto's. Hun geheugen gebruik kan dus niet makkelijk in de swap gezet worden (wat wel voor slapende processen zou kunnen en gedaan wordt).