SQL Serverベースラインテストの手順の決定的なリスト?


10

SQL Serverを使用するアプリのパフォーマンステスト/ベースラインを実行する前に、インスタンスを再起動せずにインスタンスを「クリーン」な状態に設定できるようにしたいと考えています。私は従う傾向があるステップがありますが、正しい順序であり、冗長なステップがない決定的なリストを作成したいと思います。

この手順の一覧では、SQL Serverを「クリーン」な状態に設定できますか?

シーケンスは論理的/正しいですか?

余分な手順はありますか?

CHECKPOINT              -- Write all dirty pages

DBCC DROPCLEANBUFFERS   -- All should be clean after checkpoint?

DBCC FREEPROCCACHE      -- Clear the plan cache

DBCC FREESYSTEMCACHE    -- Is this necessary after FREEPROCCACHE?

DBCC FREESESSIONCACHE   -- May not be necessary if distributed queries aren't used, but want to catch all scenarios

EXEC SP_UPDATESTATS     -- Refresh stats

'BEGIN TESTING!'

5
参考までに、これDROPCLEANBUFFERSはテストには適していますが、常に正確であるとは限りません。大量のテーブルを参照している場合は、ほとんどの場合、メモリ内にページがあり、IO時間はそのクエリの大きな要因にはなりません。その場合、現実よりもIOに重点を置く可能性があります。
JNK 2012年

本番環境または分離されたテスト環境でのテストについて話していますか?
bopapa_1979 2012年

Prod環境でテストする人は誰でも解雇されるべきです。:)はい、テスト環境。
エリックヒギンズ

回答:


5

まず、一歩下がって、テスト中に収集する予定の測定値を尋ねます。たとえば、クエリで論理読み取りをカウントしている場合、キャッシュを解放する必要はありません。データがキャッシュされているかディスク上にあるかには依存しないため、論理読み取りを使用するのが大好きです。運用環境では、クエリのデータがキャッシュされるかどうかを推測するのは困難です(データベース全体をメモリにキャッシュしない限り)。 。論理読み取りを最小限に抑えるように調整すると、データがキャッシュにあるかどうかに関係なく、アプリはより高速になります。

次に、実行間で何が変わっているのか質問します。たとえば、提案したように各データベースでEXEC SP_UPDATESTATSを実行することにより、更新されたテーブルの統計をリサンプリングします。ただし、フルスキャンで統計を更新しない限り、テーブルからランダムな行が取得されます。これは繰り返しが多すぎないので、本当に実行する必要はないと思います。代わりに、実行のたびにデータベースを復元して、常にまったく同じデータをテストすることをお勧めします。テストで挿入/更新/削除を実行している場合、データベースを復元しないと(データを追加/変更し、さらにデータの統計を変更するため)、実行ごとにパフォーマンスプロファイルが異なる可能性があります。


非常に良い点は、実行間ですべてを同一にすることです。この場合、@ハンドで測定するのは、アプリの特定の関数の実行時間です(x秒でアプリにリストが返され、y秒でキューアイテムが追加されます)。テスト間で変化するのは、SQLオブジェクトではなくアプリコードの一部、アプリコードではなくSQLオブジェクト、またはアプリコードを変更せずに同時実行などのインスタンス/ DBレベルの設定です。各テストの前にゲートから復元を追加するとしたら、その時点での私のリストについて@どう思いますか?何か不足していますか、それともシーケンスにいくつかの作業が必要ですか?
エリックヒギンズ

ブレント、テストでCPUを考慮していますか?
AK

@EricHiggins複数のものを一度にテストするのではなく、個々にテストします。クエリを直接テストして、どのような変更がパフォーマンスに影響するかを確認します。たとえば、アプリで特定の機能を実行しながらSQLトレースを実行し、インデックス/構成を変更しながらそのトレースを繰り返し再生してパフォーマンスを向上させ、トレース内の論理読み取りやCPUメトリックなどを監視します。
ブレントオザー

@AlexKuznetsov実際にテストを行っているのは私ではありません。質問をしたのはEricです。この種の作業を行うときは、サーバー全体だけでなくクエリレベルでもCPUメトリックを調べます。
ブレントオザー

私たちはサードパーティの負荷ジェネレーターを使用しています(そして、負荷テストの開発に専念する専任のスタッフがいます)。したがって、私のテストは、トランザクション、シーケンス、ユーザー数、アプリで実行される正確な手順などすべてに正確です。したがって、必ずしもSQLダッシュボードタイプのメトリックを確認する必要はありません。負荷テストソフトウェアは、アプリモジュールの応答時間をミリ秒まで追跡します。したがって、DB復元を行うことをお勧めします。毎回のテストの前に、求めている「クリーンスレート」の状態を確実に達成できるように、他の手順を検証して確認する必要があります。
エリックヒギンズ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.