SQL ServerのキャッシュフラッシュとディスクI / O

.NET 4.0で開発したOLTPシステムの負荷テストに忙しく、SQL Server 2008 R2を背後で実行しています。システムはSQL Server Service Brokerキューを使用します。これは非常にパフォーマンスが高いキューですが、処理中に独特の傾向が発生しています。

SQL Serverは、1分の猛烈な速度で要求を処理し、その後、約20秒のディスク書き込みアクティビティが増加します。次のグラフは問題を示しています。

Yellow = Transactions per second
Blue   = Total CPU usage
Red    = Sqlsrv Disk Write Bytes/s
Green  = Sqlsrv Disk Read Bytes/s

トラブルシューティング中に、パターンに大きな変更を加えることなく次のことを試みました。

• SQL Serverエージェントを停止しました。
• 実行中の他のほぼすべてのプロセスを強制終了（A / V、SSMS、VS、Windowsエクスプローラーなど）
• 他のすべてのデータベースを削除しました。
• すべての会話タイマーを無効にしました（トリガーは使用しません）。
• メッセージキュー主導のアプローチから、シンプル/粗いテーブルモニタリングデザインに移行しました。
• 軽いものから重いものまで、さまざまな負荷を使用しました。
• すべてのデッドロックを修正しました。

SQL Serverがキャッシュを構築し、特定の時間ベースの間隔でディスクに書き込んでいるように見えますが、この理論をサポートするオンラインのものが見つかりません。

次に、ソリューションを専用のテスト環境に移動して、問題を再現できるかどうかを確認します。暫定的な支援をいただければ幸いです。

Update 1 要求に応じて、チェックポイントページ/秒、ページの平均寿命、およびいくつかのディスク遅延カウンターを含むグラフがここにあります。

チェックポイント（水色の線）が、パフォーマンスの低下（黄色の線）の原因であるように見えます。^

ディスクの待機時間は処理中も比較的一定しており、ページの平均寿命は目立った影響を与えていないようです。SQL Serverで使用できるRAMの量も調整しましたが、これも大きな影響はありませんでした。復旧モデルをからSIMPLEに変更してFULLも、違いはほとんどありませんでした。

Update 2 「回復間隔」を次のように変更することで、チェックポイントが発生する間隔を短縮することができました。

EXEC sp_configure 'show advanced options',1
GO 

RECONFIGURE
GO

EXEC sp_configure 'recovery interval', '30'
GO

RECONFIGURE 
GO

EXEC sp_configure 'show advanced options',0
GO
RECONFIGURE

これが悪い習慣かどうかはわかりませんが？

SQL Serverは更新をメモリ（バッファプール内）に蓄積し、定期的に（チェックポイントで）フラッシュするだけです。提案されている2つのオプション（-kとチェックポイント間隔）は相補的です。

• -kを指定すると、チェックポイントが生成するIO要求が少なくなり、持続時間が長くなります
• 低下の回復間隔は、チェックポイントはより頻繁に起動するようになります

しかし、私はあなたが受け取った素晴らしいコメントを逆流するだけに応答しませんでした:)

表示されているのは、残念ながら、キュー処理の非常に典型的な動作です。Service Brokerキューを使用する場合でも、キューアプローチとしてテーブルを使用する場合でも、システムはこの種の動作をしやすい傾向があります。これは、キューベースの処理が書き込み負荷が高く、OLTP処理よりも書き込み負荷が高いためです。エンキューとデキューの両方のプリミティブは書き込み操作であり、読み取り操作はほとんどありません。簡単に言うと、キュー処理は、OLTP（TPC-Cのようなワークロード）でさえ、他のワークロードと比較して、ほとんどの書き込み（=ほとんどのダーティページとほとんどのログ）を生成します。

非常に重要なこととして、キューのワークロードの書き込みは挿入/削除パターンに従います。挿入されたすべての行は非常に迅速に削除されます。これは、大量の挿入（ETL）ワークロードの追加のみのパターンと区別するために重要です。基本的に、ゴーストクリーンアップタスクに完全な食事を供給しているので、簡単に実行できます。それが何を意味するかについて考えてください：

• エンキューは挿入であり、ダーティーページを作成します
• デキューは削除であり、同じページを再びダーティにします（ラッキーでチェックポイントの前にページをキャッチする可能性があるため、ダブルフラッシュは回避されますが、ラッキーな場合のみ）
• ゴーストクリーンアップはページをクリーンアップし、再びダーティにします

はい、実際には、処理するメッセージごとに、3つの異なるIO要求で、ページをディスクに3回書き込む可能性があります（最悪の場合）。また、ページの書き込みポイントが2つのチェックポイント間で再び移動するヘッドによってアクセスされるため、チェックポイントのランダムIOは実際にランダムになることも意味します（多くのOLTPワークロードと比較すると、いくつかの「ホットスポット」で書き込みがグループ化される傾向があります。キューではありません...）。

したがって、これらの3つの書き込みポイントがあり、同じページを何度もダーティとマークするために競います。そして、それは、ページ分割を検討する前のことです。挿入キーの順序が原因で、キューの処理も起こりやすくなる可能性があります。比較すると、「一般的な」OLTPワークロードの読み取り/書き込み比率ははるかにバランスが取れており、OLTP書き込みは挿入/更新/削除に分散し、多くの場合、更新（「ステータス」の変更）と挿入が大幅に共有されます。キュー処理の書き込みは、定義により、50/50に分割された挿入/削除のみです。

結果は次のとおりです。

• チェックポイントは非常にホットな問題になります（もはや驚きではありません）
• 断片化が激しくなります（断片化自体は、範囲スキャンを実行しないのでそれほど重要ではありませんが、IO効率が低下し、ゴーストクリーンアップの動作が増えるため、さらに遅くなります）。
• MDFストレージのランダムIOスループットがボトルネックになります

私の推奨事項は、S、S、Dの3文字です。MDFを、高速ランダムIOを処理できるストレージに移動します。SSD。お金があればFusion-IO。残念ながら、これはより安価なRAMでは解決できない症状の1つです...

編集：

Markが指摘しているように、1つの物理ディスクによってバックアップされた2つの論理ディスクがあります。おそらく、ベストプラクティスに従ってD：のログとC：のデータを分割しようとしたのですが、残念ながら、CとDは同じディスクです。チェックポイント間でシーケンシャルスループットを達成しますが、チェックポイントが開始するとすぐにディスクヘッドが動き始め、ログスループットが低下し、アプリ全体のスループットが低下します。データIO（別のディスク）の影響を受けないように、必ずDBログを分離してください。