Resultatet av min elevator-test

Resultaten jämförs med elevator cfg som “baseline”. Jag kommer inte att presentera de faktiska siffrorna, vilket är relativ ointressanta i min test, det intressant är jämförelsen mot defaultvärdet cfg. Uppsättningen av testmiljön kan du läsa om här.

Så, för att förklara: I samtliga diagram så utgår jag från vad testen med “elevator cfg” levererade. De övriga elevetor inställningarna jämförs mot denna och presenteras med en procentsatts. Så om CPU är 80% så innebär inte detta att CPU gick på 80%, utan att CPU i denna konfiguration var 80% mer än vad CPU med “elevator cfg” hade i samma test.

Resultaten delar jag upp i tre fyra sektioner: putc/getc, random read/write, sequantial read/write och seek.

character- och block-baserad IO

getc / get_block

Läsa “chars” och läsa block, en del applikationer använder dessa blockbaserade I/O mot filsystem.

Här levererade cfg mest, ingen tvekan. Det var dessutom med stor marginal. anticipatory levereade nästan 30% färre I/O per sekund vid blockbaserade läsningar.

putc / put_block

character baserad I/O är det cfg som har bäst prestanda, men blockbaserat så får vi fler på både anticipatory och deadline. Bara noop har färre I/O på både jämfört med cfg.

random read/write

random create

Deadline var den enda om levererade färre random create än vad cfg gjorde.

random delete

Förvånansvärt många fler IOPS för anticipatory, men även här så vår vi 15-20% mer prestanda på noop.

sequantial read/write

sequential create

samtliga övriga elevator val levererar fler IOPS i testmiljön än vad cfg gör, intressan är att deadline levererar fler IOPS med 8% mindre CPU utnyttjande

sequential delete

Staplarna talar sitt tydliga språk.. finns inte mycket att tillägga….

Seek

Här ser man tydligt hur “långsamt” anticipatory är i denna konfiguration. Både deadline och noop har byde fler sökningar per sekund samtidigt som de har en lägre CPU-belastning.

Skall väl skriva ett inlägg över de iakttagelser jag gjort också, men det kommer senare.