Hello, Warren. Yes, we use properly filled file on a single splining drive. All tests are done with fio, here is a link on full test report - http://koder-ua.github.io/6.1GA/ephemeral_drive.html. Here is a link on report for same test, executed directly on HDD, used for ephemeral storage - http://koder-ua.github.io/6.1GA/compute_node_HDD.html. We are using QEMU Debian 2.0.0+dfsg-2ubuntu1.13. Your command has following output:
virtio-blk-device.drive=drive virtio-blk-device.logical_block_size=blocksize virtio-blk-device.physical_block_size=blocksize virtio-blk-device.min_io_size=uint16 virtio-blk-device.opt_io_size=uint32 virtio-blk-device.bootindex=int32 virtio-blk-device.discard_granularity=uint32 virtio-blk-device.cyls=uint32 virtio-blk-device.heads=uint32 virtio-blk-device.secs=uint32 virtio-blk-device.serial=str virtio-blk-device.config-wce=on/off virtio-blk-device.scsi=on/off virtio-blk-device.x-iothread=iothread There only one vm on this compute node, and there a lot of free resources. Ballooning driver should not influence performance(FUEL 6.1). Kind regards, Gleb Stepanov. On Fri, Jul 10, 2015 at 11:10 PM, Konstantin Danilov <kdani...@mirantis.com> wrote: >> ...spinning drive based on fio. > splining drive. All tests are done with fio, here is a link on full test > report - http://koder-ua.github.io/6.1GA/ephemeral_drive.html. > Here is a link on report for same test, executed directly on HDD, used for > ephemeral storage - > http://koder-ua.github.io/6.1GA/compute_node_HDD.html. > >> We use following version of QEMU emulator version 2.0.0 (Debian >> 2.0.0+dfsg-2ubuntu1.13). > We are using QEMU Debian 2.0.0+dfsg-2ubuntu1.13. > >> We have not used enviroment fully, so i guess there is not affection of >> balloning. > There only one vm on this compute node, and there a lot of free resources. > Ballooning driver should not influence performance(FUEL 6.1). > > > On Fri, Jul 10, 2015 at 11:00 PM, Gleb Stepanov <gstepa...@mirantis.com> > wrote: >> >> Hello, Warren. >> >> Yes, we use properly filled file on a single spinning drive based on >> fio. We use following version of QEMU emulator version 2.0.0 (Debian >> 2.0.0+dfsg-2ubuntu1.13). >> Your command has following output: >> >> virtio-blk-device.drive=drive >> virtio-blk-device.logical_block_size=blocksize >> virtio-blk-device.physical_block_size=blocksize >> virtio-blk-device.min_io_size=uint16 >> virtio-blk-device.opt_io_size=uint32 >> virtio-blk-device.bootindex=int32 >> virtio-blk-device.discard_granularity=uint32 >> virtio-blk-device.cyls=uint32 >> virtio-blk-device.heads=uint32 >> virtio-blk-device.secs=uint32 >> virtio-blk-device.serial=str >> virtio-blk-device.config-wce=on/off >> virtio-blk-device.scsi=on/off >> virtio-blk-device.x-iothread=iothread >> >> We have not used enviroment fully, so i guess there is not affection >> of balloning. >> >> Kind regards, Gleb Stepanov. >> >> On Fri, Jul 10, 2015 at 6:01 PM, Gleb Stepanov <gstepa...@mirantis.com> >> wrote: >> > ---------- Forwarded message ---------- >> > From: Gleb Stepanov <gstepa...@mirantis.com> >> > Date: Wed, Jul 8, 2015 at 1:58 PM >> > Subject: [nova] disk I/O perfomance >> > To: openstack-operators@lists.openstack.org, >> > openstack-...@lists.openstack.org >> > >> > >> > Hello, all. >> > >> > We have measured disk I/O performance on openstack virtual machines >> > with aid of >> > FIO tool. We've tested performance on root dist drive device, test >> > consists of write operationby 4kb >> > blocks to file with size 90Gb (prefilled in advance). >> > We use qcow2 image for vm, ephemeral drive and virtio driver. >> > All configuration goes in attachment. >> > >> > There are some results: >> > >> > test 1 >> > >> > threads 1, 5, 10, 15, 20, 40 >> > iops 72,58,49,60,94,72 >> > >> > test 2 >> > threads 1, 5, 10, 15, 20, 40 >> > iops 71,60,54,88,52,52 >> > >> > test 3 >> > threads 1, 5, 10, 15, 20, 40 >> > iops 71,49,58,51,128,130 >> > >> > test 4 >> > threads 1, 5, 10, 15, 20, 40 >> > iops 65,49,60,56,52,63 >> > >> > As it is shown performance degraded during increasing amount of >> > threads, also deviation of results on 40 threads is very big. >> > Have you any ideas how to explain performance behaviour? >> > >> > Kind regards, Gleb Stepanov. > > > > > -- > Kostiantyn Danilov aka koder.ua > Principal software engineer, Mirantis > > skype:koder.ua > http://koder-ua.blogspot.com/ > http://mirantis.com _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
