diskspdを使用してSQL Serverの作業負荷を正確にシミュレーションする
Alwayson可用性グループに新しいノードを構築していて、この新しいサーバーはクラスター内の他のノードとは異なるストレージにありました。これは独立したストレージであるため、パフォーマンスが他のノードと同等であることを確認する必要がありました。ストレージエンジニアは、新しいサーバーはフラッシュストレージ上にあり、HDDを使用していた古いサーバーよりもかなり高速になるはずであると述べました。 dskspdを使用してさまざまなテストを実行し、既存のノードと比較したところ、結果に大きな違いはありませんでした。パフォーマンスを失わなかったので、とにかく先に進むことに決め、ノードを既存のクラスターに追加し、いくつかのレポートをそのサーバーに移動しましたが、驚いたことに、はるかに高速でした。
そこで、簡単なテストを行うことにしました。 200GB前後のテーブルを取り、以下のクエリを実行してクラスター化インデックススキャンを実行しました
select count(*) from Tabletest with (index(1)) option (maxdop 6)
古いサーバーを確認したところ、perfmonカウンターは次のようなものでした 
フラッシュストレージを備えた新しいサーバーでは 
レイテンシが低く、読み取り/秒が高いことがわかり、新しいフラッシュストレージの方が速い理由がわかります。ここで私の質問は、この種の動作を検証するために、diskspdにどのパラメーターを渡すかです。以下のパラメータを使用してdiskspdを実行しました。
diskspd -b8K -d60 -o32 -t8 -Sh -r -w0 -L -c5G G:\MP16\DATA\iotest.dat
新しいノードは、フラッシュストレージを備えたノードです。
さまざまなファイルサイズとさまざまなブロックサイズを試しました。スレッドを80に増やしたとしても、SQL Serverの場合よりも古いディスクのdiskspdを介して、より高いIOをプッシュできます。下の実行での古いストレージのスクリーンショット
diskspd -b64K -d60 -o32 -t80 -Sh -w0 -r -L -c10G G:\MP10\DATA\iotest.dat
それでは、disksdを使用してSQLサーバーのワークロード（クラスター化インデックススキャンなど）を正確にシミュレートするにはどうすればよいですか私が見ているのは、diskspdがテストに使用するファイルと何か関係があり、どういうわけかsanによって圧縮されているのですか？ -Zパラメータについて読みましたが、書き込みテストにのみ適用できるようです。誰かがSAMによって圧縮されにくいファイルを作成する方法を知っているか、diskspdでのテストに実際のSQLサーバーデータファイルを使用する方法はありますか？
ここで私の質問は、この種の動作を検証するために、diskspdにどのパラメーターを渡すかです。
このような仮定を実際に行うには、クラスター化インデックスについて十分に理解していません。たとえば、MaxDOP 6を指定しましたが、MaxDOP 6で実行されましたか？クラスタ化インデックスのデータは、オフローに格納されていますか？先読みはどのくらい使用されましたか？
おおよそのソートディスクの結果が与えられた場合のワークロードですが、せいぜい、この特定のテーブルのクラスター化インデックスをMaxDOP 6でスキャンする場合のワークロードを概算します。これは、読み取り可能なセカンダリレプリカであるため、レポートの処理については、これが全体的なワークロードを示していることを強く疑っています。
DiskSpeedは、ストレージをテストして別のサーバーのDiskSpeedと比較して検証するときに最適であり、レイテンシーと帯域幅の要件を確実に満たすことができます。それはSQL Serverのように動作するように作られておらず、DiskSpeedに存在しない他の複数の影響（ロック、ラッチ、コーディネーター、スピンロックの待機など）により、このような動作をすることはめったにありません。 。
スレッドを80に増やしたとしても、SQL Serverの場合よりも古いディスクのdiskspdを介して、より高いIOをプッシュできます。
上記を参照。 SQL Serverはスケジューリングにおいて協調的に機能します。SQLServerほどのパフォーマンスは得られない（これは良いことでも悪いことでもありません）など、このようなテスト用の専用スレッドを介した場合よりもSQL Serverを介した方がスループットは高くなりません。用途が異なるだけです。）
私が見ているのは、diskspdがテストに使用するファイルと何か関係があり、どういうわけかsanによって圧縮されているのですか？
DiskSpeedも例外ではないベンチマークソフトウェアは、ストレージベンダーのターゲットとなっており、ワークロードを検出して人為的に高速化するアルゴリズムを組み込んでいます。私はそれがあなたが見ているものだと言っているわけではありませんが、ここには複数の要素が関係しています。考慮すべきいくつかのこと：
- SANキャッシュのサイズ
- SAN読み取り専用キャッシュのサイズ
- キューの深さなどのHBA設定
- マルチパス設定
- IOグループのポート統計
- SANの前にあるSVC
- キャッシュされる可能性のある特殊なドライバーとそのキャッシュサイズ
- 完全にランダム、すべてゼロ、繰り返しパターンなどのファイルデータ
- ハイウォーターマークの設定やランダムデータの書き込みなどのファイル初期化
- ディスクリソースのシンまたはシックプロビジョニング
ファイルのキャッシュサイズと初期化タイプ、およびサーバーごとの設定（HBA設定やマルチパス設定など）がわかったら、サーバー/ SAN間の値の違いの調査を開始できます。
このデータはどれもわからないので、せいぜい、フラッシュが明らかに高速であること、またはそれが新しいアレイであり、それに搭載されているシステムが少ないため、負荷が少ないため、純粋に推測にすぎません。主要因子。本当に、SANバックエンドのSAN管理者からの詳細な調査が必要です。たとえば、テストがデバイス全体で実行されている間の平均IOP、最大仕様デバイス、IO負荷に関するグループ/ポート統計など）.
Dskspdを使用してさまざまなテストを実行し、既存のノードと比較したところ、結果に大きな違いはありませんでした。
これは、ワークロードが制限に達しないか、SANの最大値を超えていないか、またはレイテンシ/スループットを人為的に制限しているインフラストラクチャの問題があることを意味します。
さまざまなファイルサイズとさまざまなブロックサイズを試しました。
ファイルサイズは、もちろんそれがテストしたいものでない限り、デバイスの読み取りキャッシュに完全に収まらないほど大きくする必要があります。サイズを確認する必要があります。通常、サイズを2倍から4倍にすると、データをキャッシュできなくなります。
ブロックサイズの変更とスレッドの数によって、遅延またはスループットが決まります。結果からテストしようとしているのは不明です。それぞれのテストには異なる設定があり、一般にレイテンシをテストする場合、512バイトや4kなどの非常に小さなブロックサイズが使用されますが、最近では4kが最も一般的です。これにより、非常に小さいサイズのIOPが最大数になり、スループットが非常に小さくなります。スループットをテストするには、2MB、4MB、8MBの大きなブロックサイズを使用します。レイテンシははるかに高くなる傾向がありますが、最大スループットがテストされるようになりました。
誰かがSAMによって圧縮されにくいファイルを作成する方法を知っているか、diskspdでのテストに実際のSQLサーバーデータファイルを使用する方法はありますか？
DiskSpeedはSQL Serverが何であるかを知らないので、SQL Serverデータファイルを使用できますが、DiskSpeedはSQL Serverのようにそれを使用しません。オフセットとデータを読み取るのは単なるファイルです。