☰

専用MySQLサーバーのディスクI/Oの比較を探しています

tag-icon • tag-icon mysql performance performance-tuning
専用MySQLサーバーのディスクI/Oの比較を探しています

私たちは MySQL クラスターの容量を増やすためにコンサルタントを雇いましたが、彼が最初に（ほぼ唯一）行ったことは、サーバーのディスク I/O 速度を測定することでした。

私たちが使用しているシステムと同様のシステムでのディスク I/O の比較に興味があります。

  • 当社のMySQLサーバーは、SCSI SAN（Raid 5）を備えた32ビットVMWare ESX 3.5上で実行される仮想サーバーであり、仮想サーバー自体はDebian EtchとMySQLバージョン5.0.32を実行しています。

MySQL ボックスで次のコマンドを実行すると、次のような結果が得られました (コンサルタントは「非常に遅い」と表現しました)。

time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 71.3347 seconds, 14.7 MB/s
real    1m13.596s
user    0m0.052s
sys 0m56.932s

time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 21.8202 seconds, 48.1 MB/s
real    0m21.902s
user    0m0.012s  
sys 0m7.948s

これらの結果は本当に「非常に遅い」のでしょうか?

他のユーザーが専用の MySQL ボックスでこれらの 2 つのコマンドから得た結果を比較してみたいと思います。特に、32 ビットの仮想マシンの場合です。

答え1

注意すべき点は、dd コマンドは OS のファイルシステム キャッシュをバイパスしないということです。つまり、他の状況に応じて結果が異なり、出力サイズが大きくなると (つまり、fs キャッシュが使い果たされると) パフォーマンスが大幅に変化します。

出力ファイルのファイルシステムキャッシュをバイパスするには、「oflag=direct」を追加します。例:

time dd if=/dev/zero of=OUT.tmp bs=1M count=1000 oflag=direct

iflag=direct を使用すると、読み取り用のファイルシステムキャッシュをバイパスできます。

また、パフォーマンスはブロック サイズによって大きく異なります。1M は連続書き込みのテストにはかなり良いトレードオフですが、アプリケーションが 1M ブロックを書き込まない限り、実際のパフォーマンスを表すものにはなりません。

一般的に言えば、これらのスループットの数値はかなりひどいものです。単一の SATA ドライブ (Seagate ES.2 ドライブなど) は、ドライブの開始時に 105 MB/秒のシーケンシャル書き込みでピークに達し、ドライブ全体で約 60 MB/秒を維持します。

最後に、一般的なデータベースの「ベスト プラクティス」では、パリティ書き込みによって比較的高いオーバーヘッドが発生するため (実際のパリティ計算自体ではなく、ハードウェアでは比較的安価ですが、新しいパリティを書き出すときに余分な読み取りと書き込みを行う必要があるため)、データベースの基盤システムとして RAID5/6 を避けるように言われています。

答え2

これが私の MySQL サーバーからの結果です。これは 64 ビットであり、仮想マシンではないため、実際にどの程度使用されているかはわかりませんが、かなりの違いがあります。

time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 5.72139 s, 183 MB/s
0.00s user 1.55s system 27% cpu 5.725 total

time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.432328 s, 2.4 GB/s
0.00s user 0.45s system 103% cpu 0.436 total

答え3

ほとんどの場合、ランダムIOも比較する必要があります[例：ボニー++] 線形の読み取り/書き込みだけではありません。あるいは、ログを取得してインデックスのない巨大なテーブルに保存する 1 つの大きなデータ シンクでしょうか?

dd 'ベンチマーク' の結果

szcapp1:/mnt/big/tmp# time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 4.26186 s, 246 MB/s

real    0m4.563s
user    0m0.001s
sys     0m2.255s
szcapp1:/mnt/big/tmp# time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.457162 s, 2.3 GB/s

real    0m0.459s
user    0m0.000s
sys     0m0.459s
szcapp1:/mnt/big/tmp#

Dell PowerEdge 2950 上の 64 ビット Linux、5x デスクトップ 500GB SATA ディスク上の perc6 raid 10。16GB の RAM、2x クアッド コア 2.66GHz。でも、これは意味がありません。このデータは RAID コントローラーのキャッシュ メモリの 1/4 に収まり、残りはシステム メモリに収まります。

確かに結果は遅いです。上記の Linux 上で実行されている VM からの結果 [ VMware Server 2.0 の 32 ビット Linux ゲスト ]:

vfeed0:/tmp# time dd if=/dev/zero of=OUT.tmp bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 15.996 s, 65.6 MB/s

real    0m16.043s
user    0m0.016s
sys     0m13.117s
vfeed0:/tmp# time dd if=OUT.tmp of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.49413 s, 2.1 GB/s

real    0m0.505s
user    0m0.000s
sys     0m0.500s
vfeed0:/tmp#

読み取りパフォーマンスは偽物であることに留意してください。読み取りはキャッシュから行われます。ゲストのキャッシュからでない場合は、おそらく VMware ホストのキャッシュから行われます。

答え4

元の質問から少し離れますが、「RAID 5 は遅い」という質問に対する SAN ベンダーの回答は、RAID 1 または RAID 10 に変換することです。また、VMFS アライメント (PDF) がパフォーマンスに重大な影響を与える可能性があります。

関連情報