Hi Gleb,
Am 15.07.2015 um 13:04 hat Gleb Stepanov geschrieben:
We are testing disk I/O perfomance using fio tool. I've measured
performance on qcow2 image mounted to nb0 device. I run tests and
launch iostat -x 1 command to browse I/O operations. Test consists of
sequential read operations with 1 MB size. I've get following output.
Device: rrqm/s wrqm/s r/s w/srkB/swkB/s
sda 0.00 5.000.00 677.00 0.00 22812.00
sdb 0.00 0.000.00 545.00 0.00 0.00
dm-0 0.00 0.000.00 674.00 0.00 22784.00
dm-1 0.00 0.000.007.00 0.0028.00
dm-2 0.00 0.000.000.00 0.00 0.00
nb0 0.00 0.00 432.00 182.00 55296.00 23296.00
So, reading produce a lot of write operations. What is the reason why
these write operations occured?
Unfortunately you didn't include your qemu command line and didn't
describe in detail what your test setup looked like, so I'll have to
take a guess.
Read requests never cause writes. However, you wrote 55 MB to the image
before running the test. Did you make sure that this data was already
flushed to the disk before starting your benchmark? If it was only
sitting in the kernel page cache, the kernel can decide to write it out
at any point.
How to determina block size that qemu operates , because if i've
writtien 55 mb with 1 mb blocks
i should get 55 operations instead of 432.
If you didn't use O_DIRECT in the benchmark, chances are that the guest
kernel issues requests smaller than 1 MB to qemu.
Be aware that you might get a few metadata reads in the guest
filesystem, the qcow2 and the host filesystem layer, so slightly more
than 55 requests is expected. Each layer may also have to split requests
if the data is stored fragmented.
Also, did you make sure that no processes other than fio access the
disk?
Kevin
