Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Martin Steigerwald <Martin@lichtvoll.de>
To: fio@vger.kernel.org, Jens Axboe <axboe@kernel.dk>
Subject: Measuring IOPS
Date: Fri, 29 Jul 2011 17:37:40 +0200	[thread overview]
Message-ID: <201107291737.40463.Martin@lichtvoll.de> (raw)

Hi!

I am currently writing an article about fio for a german print magazine 
after having packaged it for Debian and using it in performance analysis & 
tuning trainings.

After introducting into the concepts of fio with some basic job files I´d 
like how to do meaningful IOPS measurements that also work with SSDs that 
compress.

For some first tests I came up with:

martin@merkaba:~[…]> cat iops.job 
[global]
size=2G
bsrange=2-16k
filename=iops1
numjobs=1
iodepth=1
# Zufällige Daten für SSDs, die komprimieren
refill_buffers=1

[zufälligschreiben]
rw=randwrite
stonewall
[sequentiellschreiben]
rw=write
stonewall

[zufälliglesen]
rw=randread
stonewall
[sequentielllesen]
rw=read

(small german dictionary:
- zufällig => random
- lesen => read
- schreiben => write;)

This takes the following into account:
- It is recommended to just use one process. Why actually? Why not just 
filling the device with as much requests as possible and see what it can 
handle?

- I do instruct fio first to write random data by even refilling the buffer 
with different random data for each write - thats for compressing SSDs, 
those with newer sandforce chips

- I let it do sync I/O cause I want to measure the device, not the cache 
speed. I considered direct I/O, but at least with sync I/O engine it does 
not work on Linux 3.0 with Ext4 on an LVM: invalid request. This may or 
may not be expected. I wondering whether direct I/O is for complete 
devices, not for filesystems.


Things I didn´t consider:
- I do not use the complete device. For obvious reasons here: I tested on 
a SSD that I use for production work as well ;).
  - Thus for a harddisk this might not be realistic enough, cause a 
harddisk has different speeds at different cylinders. I think for 2-16 KB 
request it shouldn´t matter tough.
  - I am considering a read test on the complete device

- The test does not go directly to the device, so there might be some Ext4 
/ LVM overhead. On the ThinkPad T520 with Intel i5 Sandybridge Dual Core 
CPU I think this is negligible.

- 2 GB might not be enough for reliable measurements


Do you think the above job file could give realistic results? Any 
suggestions?


I got these results:

martin@merkaba:~[…]> ./fio iops.job 
zufälligschreiben: (g=0): rw=randwrite, bs=2-16K/2-16K, ioengine=sync, 
iodepth=1
sequentiellschreiben: (g=1): rw=write, bs=2-16K/2-16K, ioengine=sync, 
iodepth=1
zufälliglesen: (g=2): rw=randread, bs=2-16K/2-16K, ioengine=sync, 
iodepth=1
sequentielllesen: (g=2): rw=read, bs=2-16K/2-16K, ioengine=sync, iodepth=1
fio 1.57
Starting 4 processes
Jobs: 1 (f=1): [__r_] [100.0% done] [561.9M/0K /s] [339K/0  iops] [eta 
00m:00s]                  
zufälligschreiben: (groupid=0, jobs=1): err= 0: pid=23221
  write: io=2048.0MB, bw=16971KB/s, iops=5190 , runt=123573msec
    clat (usec): min=0 , max=275675 , avg=183.76, stdev=989.34
     lat (usec): min=0 , max=275675 , avg=184.02, stdev=989.36
    bw (KB/s) : min=  353, max=94417, per=99.87%, avg=16947.64, 
stdev=11562.05
  cpu          : usr=5.39%, sys=14.47%, ctx=344861, majf=0, minf=30
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, 
>=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.0%
     issued r/w/d: total=0/641383/0, short=0/0/0
     lat (usec): 2=4.48%, 4=23.03%, 10=27.46%, 20=5.22%, 50=2.17%
     lat (usec): 100=0.08%, 250=10.16%, 500=21.35%, 750=4.79%, 1000=0.06%
     lat (msec): 2=0.13%, 4=0.64%, 10=0.40%, 20=0.01%, 50=0.01%
     lat (msec): 100=0.01%, 250=0.01%, 500=0.01%
sequentiellschreiben: (groupid=1, jobs=1): err= 0: pid=23227
  write: io=2048.0MB, bw=49431KB/s, iops=6172 , runt= 42426msec
    clat (usec): min=0 , max=83105 , avg=134.18, stdev=1286.14
     lat (usec): min=0 , max=83105 , avg=134.53, stdev=1286.14
    bw (KB/s) : min=    0, max=73767, per=109.57%, avg=54162.16, 
stdev=22989.92
  cpu          : usr=10.29%, sys=22.17%, ctx=232818, majf=0, minf=33
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, 
>=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.0%
     issued r/w/d: total=0/261869/0, short=0/0/0
     lat (usec): 2=0.10%, 4=1.16%, 10=9.97%, 20=1.14%, 50=0.09%
     lat (usec): 100=27.31%, 250=59.37%, 500=0.61%, 750=0.04%, 1000=0.02%
     lat (msec): 2=0.04%, 4=0.06%, 10=0.01%, 20=0.06%, 50=0.01%
     lat (msec): 100=0.03%
zufälliglesen: (groupid=2, jobs=1): err= 0: pid=23564
  read : io=2048.0MB, bw=198312KB/s, iops=60635 , runt= 10575msec
    clat (usec): min=0 , max=103758 , avg=14.46, stdev=1058.66
     lat (usec): min=0 , max=103758 , avg=14.50, stdev=1058.66
    bw (KB/s) : min=   98, max=1996998, per=54.76%, avg=217197.79, 
stdev=563543.94
  cpu          : usr=11.20%, sys=8.25%, ctx=513, majf=0, minf=28
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, 
>=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.0%
     issued r/w/d: total=641220/0/0, short=0/0/0
     lat (usec): 2=77.54%, 4=21.11%, 10=1.19%, 20=0.09%, 50=0.01%
     lat (usec): 100=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
     lat (msec): 2=0.01%, 4=0.03%, 10=0.01%, 20=0.01%, 50=0.01%
     lat (msec): 100=0.01%, 250=0.01%
sequentielllesen: (groupid=2, jobs=1): err= 0: pid=23565
  read : io=2048.0MB, bw=235953KB/s, iops=29458 , runt=  8888msec
    clat (usec): min=0 , max=71904 , avg=30.61, stdev=278.25
     lat (usec): min=0 , max=71904 , avg=30.71, stdev=278.25
    bw (KB/s) : min=    2, max=266240, per=59.04%, avg=234162.53, 
stdev=63283.64
  cpu          : usr=3.42%, sys=16.70%, ctx=8326, majf=0, minf=28
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, 
>=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, 
>=64=0.0%
     issued r/w/d: total=261826/0/0, short=0/0/0
     lat (usec): 2=28.95%, 4=46.75%, 10=19.20%, 20=1.80%, 50=0.17%
     lat (usec): 100=0.11%, 250=0.05%, 500=0.05%, 750=0.24%, 1000=2.44%
     lat (msec): 2=0.15%, 4=0.08%, 10=0.01%, 20=0.01%, 100=0.01%

Run status group 0 (all jobs):
  WRITE: io=2048.0MB, aggrb=16970KB/s, minb=17378KB/s, maxb=17378KB/s, 
mint=123573msec, maxt=123573msec

Run status group 1 (all jobs):
  WRITE: io=2048.0MB, aggrb=49430KB/s, minb=50617KB/s, maxb=50617KB/s, 
mint=42426msec, maxt=42426msec

Run status group 2 (all jobs):
   READ: io=4096.0MB, aggrb=396624KB/s, minb=203071KB/s, maxb=241616KB/s, 
mint=8888msec, maxt=10575msec

Disk stats (read/write):
  dm-2: ios=577687/390944, merge=0/0, ticks=141180/6046100, 
in_queue=6187964, util=76.63%, aggrios=577469/390258, aggrmerge=216/761, 
aggrticks=140576/6004336, aggrin_queue=6144016, aggrutil=76.38%
    sda: ios=577469/390258, merge=216/761, ticks=140576/6004336, 
in_queue=6144016, util=76.38%

Which looks quite fine, I believe ;). I didn´t yet run this test on a 
harddisk.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


             reply	other threads:[~2011-07-29 15:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-29 15:37 Martin Steigerwald [this message]
2011-07-29 16:14 ` Measuring IOPS Martin Steigerwald
2011-08-02 14:32   ` Measuring IOPS (solved, I think) Martin Steigerwald
2011-08-02 19:48     ` Jens Axboe
2011-08-02 21:28       ` Martin Steigerwald
2011-08-03  7:17         ` Jens Axboe
2011-08-03  9:03           ` Martin Steigerwald
2011-08-03 10:34             ` Jens Axboe
2011-08-03 19:31 ` Measuring IOPS Martin Steigerwald
2011-08-03 20:22   ` Jeff Moyer
2011-08-03 20:33     ` Martin Steigerwald
2011-08-04  7:50       ` Jens Axboe
2011-08-03 20:42     ` Martin Steigerwald
2011-08-03 20:50       ` Martin Steigerwald
2011-08-04  8:51         ` Martin Steigerwald
2011-08-04  8:58           ` Jens Axboe
2011-08-04  9:34             ` Martin Steigerwald
2011-08-04 10:02               ` Jens Axboe
2011-08-04 10:23                 ` Martin Steigerwald
2011-08-05  7:28                   ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201107291737.40463.Martin@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=axboe@kernel.dk \
    --cc=fio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox