問題は、仮想マシンの内部から仮想ハードディスクの「速度」を測定することは簡単ではないことです。 そもそも何を測定するのか、何を、なぜ測定するのかは不明です。 また、仮想構成の管理者に問題がアプリケーションとMySQL設定にないことを納得させるために、これを行う必要があります。 そして、彼らが言うように、店にマニュアルを読む前に「手を洗う」だけでした。
この記事では、ディストリビューションで利用可能なツールであるsysbenchとiostatを使用して、仮想ハードディスクのパフォーマンスの「転換点」を見つける簡単な手法を説明します。 また、従来のEBSとプロビジョンドIOPS EBS（1000および2000 IOPS）の両方の、制動力で知られるAmazon EBS仮想ディスクの「転換点」を測定します。
理論
地獄へ！ ディメンションと文字が多すぎる-順次読み取り/書き込み、ランダム読み取り/書き込み、上書き、カーネルファイルキャッシュの影響、クエリキューの最適化、オプションとファイルシステムアーキテクチャのオプション...ディスク、またはネットワーク上でディスクの背後に隠されているものがどのように呼吸するかを見てみましょう。
退屈しないように、gnu.orgにちょっとしたロマンスを追加してください:-)
MySQLがディスクをロードする方法
InnoDBの場合、一般的なWebアプリケーションでは、データセットがRAMに収まらない場合（データベースが発明された理由です;-)）、情報は主にディスクからランダムな順序で読み取られます（バッファープールページとクラスター化インデックスが保存されます）ディスク上）、および順次記録されます（トランザクションログとバイナリログ）。
定期的に、RAMのバッファプールがディスクにフラッシュされます-ランダム記録。 仮想ストレージに書き込みキャッシュと「バッテリー」が存在しないことをすぐに除外します。そうしないと、ACIDモードのMySQL（innodb-flush-log-at-trx-commit = 1）が単に後悔で終了します。
ここで、MySQLクライアントリクエストはパラレルスレッドで実行され、ディスクはそれぞれいくつかのスレッドで同時にロードされることを理解することが重要です。
負荷を作成する
シンプルなAmazon EBSドライブから始めましょう。 sysbenchツールを使用して仮想ディスクをロードします（CentOSではパッケージで利用でき、ソースから簡単にアセンブルできます）。
yum install sysbench mkdir -p /mount/disk_ebs/mysql/test_folder cd /mount/disk_ebs/mysql/test_folder sysbench --test=fileio --file-total-size=16G prepare
重要なポイント-仮想マシンのRAM容量の少なくとも2倍を超えるテストファイル（16G）の合計ボリュームを作成します（理由は2倍になります;-)、より良い）。 これは、オペレーティングシステムのファイルキャッシュの影響を軽減するために必要です。テストファイルを再起動するときは、再生成（または複数のテストフォルダーを作成してそれらを切り替える）することをお勧めします。
ここで、N個のスレッドの負荷を作成し、リクエストを実行する〜N個のDBMSサーバークライアントをエミュレートします（はい、DBMS内にいくつかのサービスフローがあることは知っていますが、まだ複雑にしません）。 10個のApacheがデータベースと同時に動作すると予想されるとします。
sysbench --num-threads=10 --test=fileio --file-test-mode=rndrw --max-time=180 --file-rw-ratio='2' --file-total-size=16G --max-requests=1000000 run
何を測定していますか？
今から楽しい部分です。 sysbenchが表示する結果には興味がありません。負荷が発生するだけです。 負荷がかかった状態で仮想ディスクがどのように感じるかを確認します。
iostat –xm 10 Device: rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util xvdm 0.00 0.00 120.50 0.00 2.05 0.00 34.79 10.50 87.47 8.30 100.00
「％util = 100」で示されるように、ディスクはほとんどのプロセッサ時間の要求で「圧倒されます」-ディスクドライバーは要求をキューに蓄積し、デバイスの準備ができたら要求を「フィード」します（もちろん、このインジケーターをディスクへのバス帯域幅と混同します。間違っています）。 ここで明らかなのは、ドライバーがほとんど常に待機することを強制された場合、ディスクが眼球にロードされることです。
単一のsvctm要求の平均処理時間は8.3ミリ秒です。 多すぎますが、Amazonドライブでは正常です。 犯罪者はいません-通常の物理学。
1つの要求「await」を処理するための平均待機時間は87.47ミリ秒で、「avgqu-sz」ディスクドライバーの要求キューの平均長は10.5です。 これは非常に多く、100ミリ秒ほど待ってから1つのリクエストを処理します！ 明らかに、この値の取得方法-ほぼキューのサイズ（avgqu-sz）に1つの要求の処理時間（svctm）が乗算されます。
したがって、任意の読み取り/書き込み（キー--file-test-mode = rndrwおよび--file-rw-ratio = '2'のキー）に対する10の競合要求のみが、仮想ハードディスクの処理を遅くすることがわかります。
はい、1つのリクエストをほぼ100ミリ秒待つ必要があります。 また、Webページが200個のディスクリクエストを作成した場合、構築にはどれくらい時間がかかりますか？ 20秒？
興味深いことに、Amazonディスクがキューを累積し、少なくとも50ミリ秒（より良い、一般的には20ミリ秒未満-主観的に）より速くリクエストを処理し始めるスレッドの数はいくつですか？ 5つのスレッドでそれがわかります。 もちろん、これは弱い指標であり、ソフトウェアレイドなしではできません...
Device: rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util xvdm 0.00 0.00 127.50 0.00 2.05 0.00 32.88 5.10 39.78 7.84 100.00
キューサイズが5.1で、1つのリクエストの実行時間が39.78であることがわかります。
Amazonの「高速」仮想ディスクのテスト
比較的最近、Amazonは保証された数のIOPSを備えた「高速」ディスクを発表しました（IOPS理論-私たちの国と同じくらい広範囲のgoogle、 en.wikipedia.org / wiki / IOPSにアクセスしてください）。 単純な致命的なSATAディスクは100 IOPS（同時読み取りと書き込み）を超えないこと、そして残念ながら、致命的な15k SASディスクは最大200 IOPSを超えないことを知っています。 また、他のテクノロジーのSSDとSANが数百、さらには数千のIOPSを圧倒する可能性があることも知られています。これらがはるかに高価であることは明らかです。
それでは、Amazonの「高速」仮想ディスクが何個の同時スレッドを開始し、キュー内のリクエストを鈍らせて収集するのかを見てみましょう。 ヤギの左脚を折る！
1000 IOPSのEBSディスク
1つのスレッド：
Device: rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util xvdk 0.00 0.00 1084.50 0.00 27.33 0.00 51.61 3.72 3.43 0.91 99.20
仮想ディスク自体による要求の短い処理時間-0.91 msに注意してください。 どうやらアレイはSSD上にあるようです;-)キューサイズは約4で、1つのリクエストの平均時間は3.43ミリ秒です。
20スレッド：
Device: rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util xvdk 0.00 0.00 1059.50 0.00 26.37 0.00 50.98 55.39 51.97 0.94 100.00
スレッド数が20の場合、55個のリクエストがキューイングされるため、リクエストは約50ミリ秒待機する必要があります。
2000 IOPSのEBSディスク
20スレッド：
Device: rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util xvdl 0.00 0.00 1542.50 0.00 36.29 0.00 48.18 33.20 21.29 0.65 100.00
50スレッド：
Device: rrqm/s wrqm/sr/sw/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util xvdl 0.00 0.00 1498.50 0.00 36.63 0.00 50.06 86.17 57.05 0.67 100.00
測定結果
2000 IOPSのEBSディスクは、20ストリームの1000 IOPSと6-7ストリームの通常のEBSディスク（明らかに通常のEBS IOPSディスクでは200以内）と50ストリームでほぼ同じ遅延（〜50ミリ秒）を示すことがわかります-300）。
他に何が起こっていますか
仮想ハードドライブはしばしば驚きをもたらします。 場合によっては、単に構成されていないことがあります。 男を読む時間がありませんでした...
最近、空のMySQLサーバーでマルチスレッドテスト負荷を作成するときに、夜間に0.5〜1ミリ秒、日中に10〜100ミリ秒（svctm）のsvctmが「big-expensive-fast-network」仮想ディスクからジャンプしたときに同様のケースに遭遇しました。私は満月で試してみたかった、待たなかった）。 もちろんMySQL-速度が低下しました。 その理由は、ネットワークストレージを使用し、他のプロジェクトを認識せず、MySQLの設定ではなく、有罪にしようとしたためです;-)
まとめ
即興のツールを使用して、仮想ディスクがキューの蓄積を開始し、50ミリ秒以上にわたってかなり一般的なMySQLクエリを処理し始める競合するマルチスレッドロード制限をすばやく決定しました。 これで、たとえば一定数のクライアントで10〜20ミリ秒の待ち時間を確保するために、RAIDで収集するディスクの数を想定できます。 これらがおおよそのデータであることは明らかですが、特に実際のハードドライブ/レイドのパフォーマンスを測定し、これらの比較データとシャンパン1杯をクラウドホスティング業者に提供している場合は、確かにさらに前進するのに役立ちます;-)
結論として、私は過去の祝日におめでとうございます。高速仮想ディスク、信頼性の高いサーバー、正確な測定をお祈りします！ Bitrix24をご覧ください。 頑張って