次の方法で共有


ディスクのベンチマークの実行

適用対象: ✔️ Linux VM ✔️ Windows VM ✔️ フレキシブル スケール セット ✔️ ユニフォーム スケール セット

ベンチマークとは、アプリケーションで異なるワークロードをシミュレートし、各ワークロードのアプリケーション パフォーマンスを測定するプロセスです。 高パフォーマンスの設計に関する記事で説明されている手順を使用して、アプリケーションのパフォーマンス要件を収集しました。 アプリケーションをホストしている VM でベンチマーク ツールを実行することで、アプリケーションが Premium SSD で実現できるパフォーマンス レベルを決定できます。 この記事では、Azure Premium SSD でプロビジョニングされたStandard_D8ds_v4 VM のベンチマークの例を示します。

Windows 用と Linux 用の一般的なベンチマーク ツール DiskSpd と FIO をそれぞれ使用しました。 これらのツールは、ワークロードなどの運用環境をシミュレートする複数のスレッドを生成し、システムのパフォーマンスを測定します。 ツールを使用して、ブロック サイズやキューの深さなどのパラメーターを構成することもできます。これは通常、アプリケーションに対して変更することはできません。 これにより、さまざまな種類のアプリケーション ワークロードに対して Premium SSD を使用してプロビジョニングされた高スケール VM のパフォーマンスを最大限に高める柔軟性が向上します。 各ベンチマーク ツールの詳細については、 DiskSpdFIO を参照してください。

次の例に従って、Standard_D8ds_v4を作成し、4 つの Premium SSD を VM にアタッチします。 4 つのディスクのうち、ホスト キャッシュを "None" として 3 つ構成し、NoCacheWrites というボリュームにストライプします。 残りのディスクでホスト キャッシュを "ReadOnly" として構成し、このディスクで CacheReads というボリュームを作成します。 このセットアップを使用すると、Standard_D8ds_v4 VM から最大の読み取りと書き込みのパフォーマンスを確認できます。 Premium SSD を使用したStandard_D8ds_v4の作成の詳細な手順については、「 高パフォーマンスの設計」を参照してください。

キャッシュをウォームアップする

ReadOnly ホスト キャッシュを使用するディスクは、ディスクの制限よりも高い IOPS を提供できます。 ホスト キャッシュからこの最大読み取りパフォーマンスを得るには、まず、このディスクのキャッシュをウォームアップする必要があります。 これにより、ベンチマーク ツールが CacheReads ボリューム上でドライブする読み取り IO が、ディスクに直接ヒットせず、実際にキャッシュにヒットします。 キャッシュ ヒットにより、単一のキャッシュが有効なディスクからの IOPS が増えます。

重要

VM が再起動されるたびにベンチマークを実行する前に、キャッシュをウォームアップする必要があります。

DISKSPD

VM で DISKSP ツールをダウンロードします。 DISKSPD は、独自の合成ワークロードを作成するためにカスタマイズできるツールです。 上記と同じセットアップを使用して、ベンチマーク テストを実行します。 仕様を変更して、さまざまなワークロードをテストできます。

この例では、次のベースライン パラメーターのセットを使用します。

  • -c200G: テストで使用されるサンプル ファイルを作成 (または再作成) します。 これは、バイト、KiB、MiB、GiB、またはブロックで設定できます。 この場合、メモリ キャッシュを最小限に抑えるために、200 GiB ターゲット ファイルの大きなファイルが使用されます。
  • -w100: 書き込み要求である操作の割合を指定します (-w0 読み取り% 100 に相当します)。
  • -b4K: ブロック サイズ (バイト、KiB、MiB、または GiB) を示します。 この場合、ランダム I/O テストをシミュレートするために 4K ブロック サイズが使用されます。
  • -F4: 合計 4 つのスレッドを設定します。
  • -r: ランダム I/O テストを示します (-s パラメーターをオーバーライドします)。
  • -o128: スレッドあたりのターゲットあたりの未処理の I/O 要求の数を示します。 これは、キューの深さとも呼ばれます。 この場合、CPU に負荷を加えるために 128 が使用されます。
  • -W7200: 測定が開始されるまでのウォームアップ時間の期間を指定します。
  • -d30: ウォームアップを含まない、テストの期間を指定します。
  • -Sh: ソフトウェアとハードウェアの書き込みキャッシュを無効にします (-Suwと同等)。

パラメーターの完全な一覧については、 GitHub リポジトリを参照してください。

最大書き込み IOPS

書き込み操作を実行するために、キューの深さが 128、ブロック サイズが 8 KB の小さい、4 つのワーカー スレッドを使用します。 書き込みワーカーは、キャッシュが "None" に設定された 3 つのディスクがある "NoCacheWrites" ボリュームでトラフィックを駆動しています。

次のコマンドを 30 秒間のウォームアップと 30 秒の測定で実行します。

diskspd -c200G -w100 -b8K -F4 -r -o128 -W30 -d30 -Sh testfile.dat

結果は、Standard_D8ds_v4 VM が最大書き込み IOPS 制限である 12,800 を提供していることを示しています。

3208642560合計バイト数の場合、最大合計 I/O は 391680 で、合計は 101.97 MiB/秒、合計は 1 秒あたり 13052.65 I/O です。

最大読み取り IOPS

読み取り操作を実行するために、キューの深さが 128、ブロック サイズが 4 KB、ワーカー スレッドが 4 つという高い値を使用します。 読み取りワーカーは、キャッシュが "ReadOnly" に設定された 1 つのディスクがある "CacheReads" ボリュームでトラフィックを駆動しています。

次のコマンドを 2 時間のウォームアップと 30 秒の測定で実行します。

diskspd -c200G -b4K -F4 -r -o128 -W7200 -d30 -Sh testfile.dat

結果は、Standard_D8ds_v4 VM が最大読み取り IOPS 制限 77,000 を提供していることを示しています。

9652785152合計バイト数では、合計 I/O が2356637、合計 MiB/秒が 306.72、I/O が 1 秒あたり合計 78521.23 個でした。

最大スループット

読み取りと書き込みの最大スループットを取得するには、64 KB の大きなブロック サイズに変更できます。

fio

FIO は、Linux VM 上のストレージをベンチマークするための一般的なツールです。 さまざまな IO サイズ、シーケンシャルまたはランダムな読み取りと書き込みを柔軟に選択できます。 ワーカー スレッドまたはプロセスを生成して、指定された I/O 操作を実行します。 各ワーカー スレッドがジョブ ファイルを使用して実行する必要がある I/O 操作の種類を指定できます。 次の例に示すように、シナリオごとに 1 つのジョブ ファイルを作成しました。 これらのジョブ ファイルの仕様を変更して、Premium Storage で実行されているさまざまなワークロードをベンチマークできます。 この例では、 Ubuntu を実行しているStandard_D8ds_v4を使用しています。 ベンチマーク のセクションの冒頭で説明したのと同じセットアップを使用し、ベンチマーク テストを実行する前にキャッシュをウォームアップします。

開始する前に、 FIO をダウンロード して仮想マシンにインストールします。

Ubuntu に対して次のコマンドを実行します。

apt-get install fio

書き込み操作を駆動するために 4 つのワーカー スレッドを使用し、ディスクで読み取り操作を実行するために 4 つのワーカー スレッドを使用します。 書き込みワーカーは、キャッシュが "None" に設定された 3 つのディスクがある "nocache" ボリュームでトラフィックを駆動しています。 読み取りワーカーは、キャッシュが "ReadOnly" に設定された 1 つのディスクがある "readcache" ボリュームでトラフィックを駆動しています。

最大書き込み IOPS

最大書き込み IOPS を取得するには、次の仕様でジョブ ファイルを作成します。 "fiowrite.ini" という名前を付けます。

[global]
size=30g
direct=1
iodepth=256
ioengine=libaio
bs=4k
numjobs=4

[writer1]
rw=randwrite
directory=/mnt/nocache

前のセクションで説明した設計ガイドラインに沿った次の重要な点に注意してください。 これらの仕様は、最大 IOPS を駆動するために不可欠です。

  • キュー深度が256と高い。
  • 4 KB の小さなブロック。
  • ランダムな書き込みを実行する複数のスレッド。

次のコマンドを実行して、FIO テストを 30 秒間開始します。

sudo fio --runtime 30 fiowrite.ini

テストの実行中に、VM と Premium ディスクが提供している書き込み IOPS の数を確認できます。 次のサンプルに示すように、Standard_D8ds_v4 VM は最大書き込み IOPS 制限である 12,800 IOPS を提供しています。
VM と Premium SSD が配信している書き込み IOPS の数は、書き込みが 13.1k IOPS であることを示しています。

最大読み取り IOPS

最大読み取り IOPS を取得するには、次の仕様でジョブ ファイルを作成します。 "fioread.ini" という名前を付けます。

[global]
size=30g
direct=1
iodepth=256
ioengine=libaio
bs=4k
numjobs=4

[reader1]
rw=randread
directory=/mnt/readcache

前のセクションで説明した設計ガイドラインに沿った次の重要な点に注意してください。 これらの仕様は、最大 IOPS を駆動するために不可欠です。

  • キューの深さは256と高いです。
  • 小さな 4 KB ブロックサイズ。
  • ランダムな書き込みを実行する複数のスレッド。

次のコマンドを実行して、FIO テストを 30 秒間開始します。

sudo fio --runtime 30 fioread.ini

テストの実行中に、VM と Premium ディスクが提供している読み取り IOPS の数を確認できます。 次のサンプルに示すように、Standard_D8ds_v4 VM は 77,000 を超える読み取り IOPS を提供しています。 これは、ディスクとキャッシュのパフォーマンスの組み合わせです。
書き込み IOPS VM と Premium SSD が配信している数のスクリーンショット。読み取りは 78.6k であることを示しています。

読み取りと書き込みの最大 IOPS

読み取りと書き込みの IOPS の組み合わせの最大値を取得するには、次の仕様でジョブ ファイルを作成します。 "fioreadwrite.ini" という名前を付けます。

[global]
size=30g
direct=1
iodepth=128
ioengine=libaio
bs=4k
numjobs=4

[reader1]
rw=randread
directory=/mnt/readcache

[writer1]
rw=randwrite
directory=/mnt/nocache
rate_iops=3200

前のセクションで説明した設計ガイドラインに沿った次の重要な点に注意してください。 これらの仕様は、最大 IOPS を駆動するために不可欠です。

  • 128 の大きなキューの深さ。
  • 小さな 4 KB のブロックサイズ。
  • ランダムな読み取りと書き込みを実行する複数のスレッド。

次のコマンドを実行して、FIO テストを 30 秒間開始します。

sudo fio --runtime 30 fioreadwrite.ini

テストの実行中に、VM と Premium ディスクが提供している読み取りと書き込みの合計 IOPS の数を確認できます。 次のサンプルに示すように、Standard_D8ds_v4 VM は 90,000 を超える読み取りと書き込みの IOPS を提供しています。 これは、ディスクとキャッシュのパフォーマンスの組み合わせです。
読み取りと書き込みの IOPS の組み合わせにより、読み取りは 78.3k、書き込みは 12.6,600 IOPS であることを示します。

合計スループットの最大値

読み取りと書き込みの最大スループットを取得するには、読み取りと書き込みを実行する複数のスレッドで、より大きなブロック サイズと大きなキューの深さを使用します。 ブロック サイズは 64 KB、キューの深さは 128 を使用できます。

次のステップ

高パフォーマンスのための設計に関する記事に進みます。

この記事では、プロトタイプの既存のアプリケーションと同様のチェックリストを作成します。 ベンチマーク ツールを使用すると、ワークロードをシミュレートし、プロトタイプ アプリケーションのパフォーマンスを測定できます。 これにより、アプリケーションのパフォーマンス要件に一致するディスク オファリングまたは上回るディスク オファリングを決定できます。 その後、運用アプリケーションに対して同じガイドラインを実装できます。