SQL Serverのディスクスループットがdiskspdよりも遅い
これは少し広い質問ですが、2台のサーバーでのストレージパフォーマンスの動作を理解しようとしています。
私はフォローしていた https://www.brentozar.com/archive/2015/09/getting-started-with-diskspd/
1つのサーバーで、DBと同じディスク上で以下のパラメーターを指定してdskspdを実行しました。
diskspd.exe -b2M -d60 -o32 -h -L -t56 -W -w0 -c10G G:\MP13\Data\test.dat
約1400MB /秒
また、以下のT-SQLクエリを使用して同等のスループットを取得し、読み取り数と時間からスループットを計算することもできました。これは、PluralSightのGlenn Berry SQLコース「ストレージサブシステムのパフォーマンスの向上」から取得しました。
set statistics io on
set statistics time on
checkpoint
dbcc dropcleanbuffers
select count(*) from table1 with(index(1))
ただし、他のサーバーでは、diskioツールから高いスループット数を取得できますが、SQLサーバーの方法を使用すると、スループット数を取得できません。 SQL番号は、プランが並行して実行されている場合でも、単一のスレッドでdiskspdを実行した場合に得られる数値に近くなります。
したがって、SQL ServerのIOが遅い理由、またはSQL Serverがより多くのIOをプッシュできない理由を確認するために何をチェックできるかについて考えていました。
いくつかの概念的な問題を解決する必要があります。 diskspdなどのツールを実行すると、クエリの特定のパフォーマンスプロファイルを保証するものではなく、ストレージの理論上の限界をベンチマークすることになります。さらに、構成されたパターン（2MBブロックサイズ、キューの深さ32、56スレッド、100％読み取り[ランダム？シーケンシャル？]）をのみテストしています。 SQL Serverにはさまざまな読み取り/書き込みパターンがあり、クエリがこのテストパターンに従っている保証はありません。基本的に、diskspdとクエリを使用して2つの異なるものをテストします。
SANを使用している場合、主に次の2つの点が有効です。
さらに、さまざまなストレージツールがさまざまな方法でテストを実行します。 sqlioは、ヌルバイト（0x0）。 diskspdはさまざまなパターンを持っているように見えますが、それでも繰り返されます。
fio ランダムデータのサイズ。私は vdbench を1回だけ使用しましたが、ファイルを埋めるために何を使用するかを正直にチェックしていません。ほとんどのSANは空のスペースと繰り返しパターンを圧縮および重複排除するため、これを取り上げます。したがって、SAN上の同様のサイズのファイル（SQL Serverデータファイルが10GBであると想定）でパフォーマンスをテストしているとは限りません。確かに、データファイルは圧縮および重複排除できますが、diskspdによって生成されたファイルと同じレベルではない可能性があります。
これは私が作りたい最後のポイントにつながります。 SANのキャッシュサイズにもよりますが、通常、10 GBのファイルでは、実際にSANパフォーマンス（IOPSの観点から）をテストすることすらできません）。SANコントローラーはおそらく、このtest.datファイルをコントローラーキャッシュに常駐し、実際にバッキングディスクに触れない程度の適切なサイズに圧縮および重複排除できるでしょう。したがって、テストしているのはSANコントローラとOS。1400MB/ sとして識別されています。
MicrosoftのFast Track Data Warehouse戦略に沿ってハードウェアを展開する同じ演習を行いました。彼らの SQL Server 2012のファストトラックデータウェアハウスリファレンスガイド は、既にバッファープールにあるデータを含むクエリのMCR（最大消費率）やBCR（ベンチマーク消費率）など、発見してテスト済みのトピックをカバーしています。 ）実際のクエリの場合、すべてではないにしても、一部のデータがディスクサブシステムから取得される必要があります。クエリの複雑さも全体的なスループットに影響します（TPC-Hベンチマークデータセットを使用すると、その例では、コアあたり56〜201 MB /秒のスループットレートが示されています）。