Hoe kan je nou een io bottleneck vinden met iostat?

[markg85]

Hey,

Ik probeer nu om erachter te komen of me hdd de bottleneck is. Dit doe ik door een programma uit een plaatjes map thumbnails te laten renderen (2000) van bron plaatjes met het formaat van wallpapers die tussen de 100KB en 2 MB in zitten.

Gedurende 30 seconden is het programma bezig om die wallpapers te genereren met 4 threads. De cpu belasting is dat 70% voor alle 4 de cores (let op! 4 threads is in dit geval toeval met de 4 cores. ik kan ook meer threads kiezen, maar heb gemerkt dat 4 threads het meest effectief is in dit geval. meer maakt het niet sneller).

Dus wat ik nu in linux doe is dit commando vlak voordat ik het renderen van thumbnails aanzet:
iostat -k -x 2 50

En dan krijg ik waardes als dit:

avg-cpu: %user %nice %system %iowait %steal %idle
65.76 0.00 1.85 0.12 0.00 32.27

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda 0.00 29.50 0.00 1.00 0.00 122.00 244.00 0.02 20.00 20.00 2.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

avg-cpu: %user %nice %system %iowait %steal %idle
66.05 0.00 2.11 0.00 0.00 31.85

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

avg-cpu: %user %nice %system %iowait %steal %idle
62.19 0.00 1.85 0.12 0.00 35.84

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda 0.00 28.50 0.00 1.00 0.00 118.00 236.00 0.02 20.00 20.00 2.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

avg-cpu: %user %nice %system %iowait %steal %idle
68.23 0.00 2.46 0.00 0.00 29.31

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

avg-cpu: %user %nice %system %iowait %steal %idle
65.68 0.00 1.73 0.00 0.00 32.59

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

avg-cpu: %user %nice %system %iowait %steal %idle
67.08 0.00 2.10 0.25 0.00 30.58

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda 0.00 28.50 0.00 1.00 0.00 118.00 236.00 0.02 18.50 18.00 1.80
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

avg-cpu: %user %nice %system %iowait %steal %idle
62.38 0.00 1.72 0.00 0.00 35.91

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 5.50 0.00 10.00 0.00 62.00 12.40 0.09 9.00 0.85 0.85
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

avg-cpu: %user %nice %system %iowait %steal %idle
20.27 0.00 0.37 0.50 0.00 78.86

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda 0.00 26.50 0.00 1.00 0.00 110.00 220.00 0.02 16.50 17.00 1.70
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

Hoe moet ik nu aan dit aflezen dat mijn hdd de bottleneck is?
Oke, de cpu cores hebben 30% idle dus ze moeten iniedergeval op iets wachten, maar wat?

Thanx,
Mark.

[magistus]

avg-cpu: %user %nice %system %iowait %steal %idle
66.05 0.00 2.11 0.00 0.00 31.85

Kijk naar de waarde van iowait.

[ Voor 85% gewijzigd door magistus op 29-09-2009 20:25 . Reden: heh, wakker worden, staat er gewoon :p ]

[Wirf]

markg85 schreef op dinsdag 29 september 2009 @ 19:58:
[..]
Hoe moet ik nu aan dit aflezen dat mijn hdd de bottleneck is?
Oke, de cpu cores hebben 30% idle dus ze moeten iniedergeval op iets wachten, maar wat?

Zo te zien aan je percentage wait, is je HDD niet je bottleneck (zie ook de reactie van magistus)

Waar je cores wel op staan te wachten is moeilijk te zeggen, maar het kan goed zijn dat de plaatjes zo klein zijn en zo snel verwerkt worden, dat threads "starvation" ondervinden omdat de aansturende thread niet snel genoeg nieuwe commando's kan aanleveren.

Als er bijvoorbeeld twee threads net tegelijkertijd klaar zijn met het schalen, en dus wachten op een nieuw bestand te verwerken dan heb je dus al "idle" tijd.
Omdat de aansturende thread slechts 1 thread per keer een nieuw commando kan geven, zal er dus ook idle tijd zijn in een systeem met meerdere cores. (in een single core systeem wordt de idle tijd opgeslokt door de aansturende thread)

Het is dus een bug in het programma dat je gebruikt.

[markg85]

Wirf schreef op dinsdag 29 september 2009 @ 20:33:
[...]

Zo te zien aan je percentage wait, is je HDD niet je bottleneck (zie ook de reactie van magistus)

Waar je cores wel op staan te wachten is moeilijk te zeggen, maar het kan goed zijn dat de plaatjes zo klein zijn en zo snel verwerkt worden, dat threads "starvation" ondervinden omdat de aansturende thread niet snel genoeg nieuwe commando's kan aanleveren.

Als er bijvoorbeeld twee threads net tegelijkertijd klaar zijn met het schalen, en dus wachten op een nieuw bestand te verwerken dan heb je dus al "idle" tijd.
Omdat de aansturende thread slechts 1 thread per keer een nieuw commando kan geven, zal er dus ook idle tijd zijn in een systeem met meerdere cores. (in een single core systeem wordt de idle tijd opgeslokt door de aansturende thread)

Het is dus een bug in het programma dat je gebruikt.

Oh, dat is geen verassing ik heb het zelf gemaakt en dit was me eerste threaded poging. Wat ik nu due is:

- Maak een queue aan van alle bestanden die een thumbnail moeten hebben
- Elke thread pakt een item van de queue en wordt alleen tijdens het pakken van de queue gelocked om te voorkomen dat 2 threads exact hetzelfde item gaan thumbnailen.
- En dan thumbnailen maar.

Code (nog van voorbeeldjes dus vandaag de gekke namen en er zitten ook vast mem leaks in..):

static void* say_hello(gpointer data)
{
g_print ("Hello World! It's me, thread #%d using sequence number %d!\n",
GPOINTER_TO_INT (data), give_me_next_number ());

int thread_nr = GPOINTER_TO_INT (data);
int errors = 0;
while (!imageQueue.empty())
{
std::string imageName = imageQueue.front();

// Lock for popping of queue
g_mutex_lock (global_sequence_mutex);
imageQueue.pop();
g_mutex_unlock (global_sequence_mutex);
// unlock

GError *gerror = NULL;
GdkPixbuf *originalpb;

std::string imagePath = "/home/mark/ThumbnailingBenchmarks/2000_Wallpapers-Reanimation/" + imageName;
std::string thumbnailPath = "/home/mark/ThumbnailingBenchmarks/thumbnails/GDK_INTERP_BILINEAR/" + imageName + ".png";

originalpb = gdk_pixbuf_new_from_file_at_scale(imagePath.c_str(), 200, 200, true, &gerror);
if (!originalpb)
{
printf("error message: %s\n", gerror->message);
errors++;
gdk_pixbuf_unref(originalpb);
continue;
//exit(1);
}

gdk_pixbuf_save (originalpb, thumbnailPath.c_str(), "png", &gerror, NULL);

gdk_pixbuf_unref(originalpb);

printf("Thread # %d <> %s\n", thread_nr, imageName.c_str());
}

printf("\n\nThere where %i errors! in thread: %d \n", errors, thread_nr);

g_thread_exit (NULL);
}

edit

zou het misschien beter werken als ik ga batchen in threads? daarmee bedoel ik dat ik elke thread in 1 keer 5 plaatjes geef om te thumbnailen? dat zou thread starvation toch moeten kunnen voorkomen?

[ Voor 3% gewijzigd door markg85 op 29-09-2009 21:09 ]

[Wirf]

markg85 schreef op dinsdag 29 september 2009 @ 21:06:
zou het misschien beter werken als ik ga batchen in threads? daarmee bedoel ik dat ik elke thread in 1 keer 5 plaatjes geef om te thumbnailen? dat zou thread starvation toch moeten kunnen voorkomen?

Ja, dat zou wel helpen. Echt voorkomen wordt het dan niet, maar helpen zal het wel.

Je zou ook je lijst op kunnen splitsen in het (aantal threads) + 1 dat je wil starten, elke thread werkt zijn eigen lijst door, en als ie daar mee klaar is vraagt hij bij de controlerende thread om meer werk en krijgt dan pakketjes van 5 plaatjes per stuk.

Dus stel dat je werkt met 4 threads, dan split je de lijst in 5 delen en geef je elke thread zo'n deel van de lijst.
Het laatste deel hou je om aan het eind nog werk te kunnen verdelen over de threads die al klaar zijn.

_{Move naar PRG misschien?}

[markg85]

Wirf schreef op dinsdag 29 september 2009 @ 21:27:
[...]

Ja, dat zou wel helpen. Echt voorkomen wordt het dan niet, maar helpen zal het wel.

Je zou ook je lijst op kunnen splitsen in het (aantal threads) + 1 dat je wil starten, elke thread werkt zijn eigen lijst door, en als ie daar mee klaar is vraagt hij bij de controlerende thread om meer werk en krijgt dan pakketjes van 5 plaatjes per stuk.

Dus stel dat je werkt met 4 threads, dan split je de lijst in 5 delen en geef je elke thread zo'n deel van de lijst.
Het laatste deel hou je om aan het eind nog werk te kunnen verdelen over de threads die al klaar zijn.

_{Move naar PRG misschien?}

Oke cool ik heb dat nu gedaan en heb nu een duidelijke bottleneck gevonden: mijn CPU i.p.v. mijn hdd.
Ik heb nu met 4 threads 100% cpu verbruik (en razendsnel thumbnails genereren). Tijd voor een 8 core cpu en kijken of daar dan wel een hdd bottleneck zou ontstaan