新しいSQLServerインスタンスのハードウェアのベンチマークを支援しており、データファイル用にOSに提示されるボリュームは、SymmetrixSAN上の一連のスピンドルから切り分けられます。サーバーにはまだSQLServerがインストールされていないため、ボックスでの唯一のアクティビティはベンチマークです。
現在、ストレージエンジニアは、このボリュームとそのリソースは新しいサーバー専用であると述べています(実際のSAN config)を表示するためのアクセス権はありませんが、パフォーマンスベンチマークは問題を抱えています。たとえば、数値は突然、ランダムになるまで良好に見えます。IOベンチマークツールの待機時間は100秒、ディスクキューの長さはperfmonで255です。
このSANには8GBのキャッシュがあり、さらにSANを使用する他のアプリケーションがあります。(ボリュームのスピンドルは専用にする必要がありますが)キャッシュがあるかどうか疑問に思います。パフォーマンステスト中に打撃を受けている可能性があります。または、ボリュームがオンになっているスピンドルが実際には専用ではない可能性があります。
ストレージエンジニアから問題の追跡を支援することはあまり得られていないため、このような問題の診断の経験があり、洞察とトラブルシューティングの方法論を共有したい人がいれば、それをいただければ幸いです。
@arcain
どのベンチマークツールを使用していますか?
SQLIOSimやSQLIOなどの多くのツールは、構成方法によっては、ディスクキューの長さが高レベルに達する可能性がありますが、テストの一部であるため問題ありません。問題は、あなたが私に言った待ち時間です。それはディスクの競合を完全に放棄することです。 SANファブリックの飽和が原因でVMが多すぎることを除いて、私の経験では、ディスク(SSDでない場合)が常に最大のボトルネックになっています。それらをアクティブに利用している別のホストと共有されていない限り、待機状態になります。
このような状況では、MSのSQLIOを使用することをお勧めします(つまり、これがすでに使用しているものではない場合)。 Symmetrixには8GBのキャッシュがあるので、16GB以上のテストファイルでテストしてキャッシュをプッシュし、バリエーションがキャッシュではなく、基盤となるディスクが実際に出力しているものであることを確認します。
SQLIOを使用して一連のテスト用のファイルを作成し、それに対して以下を実行できます。
sqlio -kW -t2 -s120 -dE -o4 -fsequential -b64 -BH -LS Testfile.dat
-dパラメータは、ドライブ文字(この場合はE)を参照します。
このテストでは、2分(-s120)の期間にわたって一連の順次書き込みを実行し、タイムスタンプ付きの単純なバッチファイルにまとめて、時刻を追跡し、結果をログファイルにパイプして確認することができます。上記または同様のものを一定期間繰り返し実行するバッチを作成し、結果を確認します。サンプルが大きいほど良いです。
ディスクが実際に専用であり、キャッシュをプッシュしている場合、結果のIO、MB、およびレイテンシーはかなり近いはずです(1〜5%の変動)。それを超えて15%以上になる場合は、ディスクの競合が発生している可能性があります。
もう1つ、テストの日時と、テスト対象のドライブを必ずメモしてください。すべてのSANには、以下をプロファイリングするための何らかのロギングがあります。
これは他のホストと共有されるSAN)であるため、Symmterixのパフォーマンスを測定するためにこの情報を要求できるはずです。
可能であれば、いくつかの結果を投稿してください。レビューさせていただきます。
キャッシュは、ユーザーとアレイ上にある他のサーバーの間で共有されます。スピンドルが他のものと共有されている可能性があります。ストレージ管理者だけが確実に知っているでしょう。
シェルフまたはバックエンドループが容量に達している可能性もあります(可能性は低いですが、可能です)。
すべてが順調に進んでいる場合は、少しの間がらくたになり、その後通常に戻ります。アレイのキャッシュがいっぱいになり、ディスクに直接書き込み始めているように聞こえます。これは、ディスクがすでに100%で実行されています。 LUNの背後にあるスピンドルの数はいくつですか?正常に動作している場合、どのようなパフォーマンスが見られますか?