XenでのMythical Disc Brakes

多くの場合、仮想化のさまざまな方法について議論するとき、Virtuozzoのサポーター(通常OpenVZのホスティング業者)は、かつて聞いた声明を思い出します。 この誤acyは、Xen仮想マシンとVirtuzzoコンテナの根本的に異なるディスクキャッシュメカニズムに根ざしています。 その結果、ディスクシステムのパフォーマンス特性は、さまざまな条件下で大きく異なります。 しかし、妄想はしっかりと長い間心に定着します。



「Xenディスクブレーキ」のトピックを閉じて、ブレーキがないことを数字で示すために、unixbench、bonnie ++、および同じディスクパーティション上の同じマシン上のLinuxカーネルソースのパッケージ化の結果を次に示します。





プロセッサー:Intel®Core(TM)2 Quad CPU Q6600 @ 2.40GHz。 ドライブは、SATA Samsungの一種です。



ネイティブ -物理マシン上でフリーズ:1 CPU、256 Mb RAM。 カーネル:2.6.18-164.6.1.el5

Xen PV-準仮想化モードのXen仮想マシンでフリーズ:1 CPU、256 Mb RAM。 DomUカーネル:2.6.18-164.el5xen。 Dom0カーネル:2.6.18-164.el5xen。 仮想マシンのディスクはphyとして提供されます。



Unixbench




特にディスク用の非常に総合的なテストですが、引数でよく使用されます。 ディスクに属するものを切り取る:



ネイティブ


File Copy 1024 bufsize 2000 maxblocks 3960.0 529094.5 1336.1

File Copy 256 bufsize 500 maxblocks 1655.0 153098.5 925.1

File Copy 4096 bufsize 8000 maxblocks 5800.0 1208281.0 2083.2









Xen PV


File Copy 1024 bufsize 2000 maxblocks 3960.0 542862.3 1370.9

File Copy 256 bufsize 500 maxblocks 1655.0 153684.5 928.6

File Copy 4096 bufsize 8000 maxblocks 5800.0 1212533.2 2090.6









太字のテキストは合計を強調表示します-より良い。 物理ハードウェアと仮想マシンでは、仮想マシンの数はほぼ同じであることがわかります。 省エネの法則に違反しているように見えますが、簡単に説明します-負荷のごく一部(約1%)は、仮想マシンの外部のdom0にあり、別のコアで実行されるI / Oサブシステムによって想定されます。



ボニー++




ネイティブ


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

dev.home 1G 575 99 64203 13 29238 5 1726 96 68316 6 144.5 1

Latency 14923us 1197ms 483ms 60674us 16858us 541ms

Version 1.96 ------Sequential Create------ --------Random Create--------

dev.home -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--

files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP

256 47219 67 304464 100 23795 31 51813 73 378017 100 6970 9

Latency 575ms 846us 673ms 416ms 22us 1408ms









Xen PV


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

CentOS_5_4 1G 815 99 65675 4 29532 0 1739 92 68298 0 134.1 0

Latency 10028us 200ms 242ms 122ms 15356us 627ms

Version 1.96 ------Sequential Create------ --------Random Create--------

CentOS_5_4 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--

files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP

256 53015 61 325596 99 25157 23 58020 68 404162 99 6050 5

Latency 605ms 771us 686ms 406ms 49us 2121ms









より汎用性の高い評価ですが、やはり奇妙な結果です-場合によっては、Xen PVの方が高速です。



アーカイブ


そして、通常の実際のタスクの結果を見ることができます。 Linuxカーネルソースのアーカイブ*へのパッキングは、集中的なディスク読み取りを伴うタスクです。 合計サイズは約320 MB、ほぼ2万4,000ファイルです。 パックする前に、vm.drop_cachesを介してディスクキャッシュがクリアされました。



Native

$ time (find linux-2.6.26 | cpio -o > /dev/null)

530862 blocks



real 0m30.247s

user 0m0.605s

sys 0m2.411s









Xen PV

$ time (find linux-2.6.26 | cpio -o > /dev/null)

530862 blocks



real 0m32.396s

user 0m0.052s

sys 0m0.120s









時間差は7%をわずかに下回り、かなり通常の仮想化オーバーヘッドで十分です。 これは、ほとんどのディスクパターンに及ぶパフォーマンスの低下です。 タスクがディスク上にある場合、プラスまたはマイナス7%で状況が大幅に変わることはありません。



* tarは非常にunningなため、/ dev / nullで出力が見つかると、ドライランがオンになり、何もアーカイブされないため、tarの代わりにcpioを使用する必要があります。



All Articles