qemu virtio-blk data planeとは、virtio-blk デバイスごとに、専用のIO threadを作り、QBL(qemu big lock)の外部で動作させることでlock contentionによる性能劣化を抑える試みです。専用のthreadを作り性能を向上させる試みは、ネットワークではすでにvhost-netを用いて行われていました。
関連コミット:
http://git.qemu.org/?p=qemu.git;a=commit;h=392808b49b6aee066d0c1d200e72fc3dc11c9d0f
簡単に仕組みを説明すると、virtio-blk デバイスごとに作られたIO threadはLinux Native AIOシステムコールを使い、非同期にIOを発行します。ゲストからの通知(ioeventfd)、およびゲストへの割り込み通知(irqfd)もこのIO threadが担当します。従来はqemuが行なっていた作業をglobal mutex外へと分離し、専用のthreadに任せることでScalabilityと性能を向上させることができるわけです。
virtio-blk data planeを用いることで、IOPSが14万から60万に上がったという報告もあります。
http://comments.gmane.org/gmane.comp.emulators.qemu/184821
しかし、現状ではvirtio-blk data plane には以下のような制限があります。
- raw format のみのサポート
- live migration 非サポート
- hot unplug 非サポート
- qemu での IO throttling が効かない
- Host は linux のみサポート(Linux Native AIO syscallを使うため)
使い方
virtio-blk x-data-plane を使うには、まず条件として以下が必要です。
- raw image formatでなければならない
- wce(write cache enable: Guestのwrite cache設定を起動中に on/off 変更する機能) off
- scsi off
「raw image なんてないよ、qcow2(or 3) しかないよ!」という方は以下のコマンドでraw image を作ってVMを新規作成しまししょう。
# qemu-img convert -O raw qcow.img raw.imgqemu を直接起動しても良いのですが、ここでは利便性のためにlibvirtを経由してqemuを扱うことにします。
上記の条件に合うように、libvirt XML file を作りましょう。
例えば、以下のようにします。
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> ... <devices> <emulator>/usr/local/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source file='/home/eiichi/vmimg/fraw.img'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> ... </devices> <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='device.virtio-disk0.config-wce=off'/> <qemu:arg value='-set'/> <qemu:arg value='device.virtio-disk0.scsi=off'/> <qemu:arg value='-set'/> <qemu:arg value='device.virtio-disk0.x-data-plane=on'/> </qemu:commandline> </domain>
diskタイプをraw、AIOはLinux Nativeを指定します。
また、qemuの-setオプションを使うことで、x-data-plane=on オプションを有効にします。
評価
以下の環境で、bonnie++による書き込み性能評価を行いました。
- Host OS: Fedora 18
- Host Memory : 4G
- Host FileSystem : btrfs
- Guest OS: Fedora 18
- Gues VCPU: 2
- Guest Memory : 1G
- Guest FileSystem : btrfs
- Qemu : qemu v1.3.0-rc2
- 測定コマンド : bonnie++
Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP fraw 2G 875 84 74157 13 21666 6 3128 78 50335 6 263.5 15 Latency 31893us 632ms 6507ms 83291us 299ms 728ms Version 1.96 ------Sequential Create------ --------Random Create-------- fraw -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 21634 57 +++++ +++ +++++ +++ 22124 60 +++++ +++ +++++ +++ Latency 241us 593us 443us 108us 30us 138us
Guest data plane on:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP fraw 2G 900 87 61252 12 24206 7 3296 82 91454 12 242.6 15 Latency 54769us 1189ms 5273ms 36272us 275ms 546ms Version 1.96 ------Sequential Create------ --------Random Create-------- fraw -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 6949 18 +++++ +++ +++++ +++ 19625 52 +++++ +++ 32179 21 Latency 1069us 1450us 448us 112us 449us 173us残念ながら、自分の環境だと性能に大きな違いは見受けられないようです。。
高性能なストレージを使ったり、qemu_global_mutex contention が大量に発生する環境で測定すると、また違った結果がでてくると思われます。
参考文献
An Updated Overview of the QEMU Storage Stack
Optimizing the QEMU Storage Stack
[Qemu-devel] [PATCH v2 0/8] virtio: virtio-blk data plane
Features/WriteCacheEnable
0 件のコメント:
コメントを投稿