web-dev-qa-db-ja.com

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

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

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

SQL OLTP System - Performance Counters

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がキャッシュを構築し、特定の時間ベースの間隔でディスクに書き込んでいるように見えますが、この理論をサポートするものをオンラインで見つけることができません。

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

pdate 1要求に応じて、チェックポイントページ/秒を含むグラフ、 Page Life Expectancy、および一部のディスク遅延カウンター。

SQL OLTP System - Performance Counters - Checkpoint

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

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

pdate 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-serverperformanceservice-broker
11
André Hauptfleisch

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

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

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

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

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

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

つまり、これらの3つの書き込みポイントがあり、sameページを何度もダーティとマーク付けするために競います。そして、それは、キューの挿入mayが挿入キーの順序のために発生しやすいページ分割を検討する前です。比較すると、「典型的」OLTPワークロードの読み取り/書き込み比率ははるかにバランスが取れており、OLTP書き込みは挿入/更新/削除に分散し、多くの場合、更新を伴います（ 「ステータス」の変更）と挿入はライオンズのシェアを占めます。キュー処理の書き込みは、定義により、50/50に分割された挿入/削除のみです。

結果は次のとおりです。

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

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

編集：

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

11
Remus Rusanu