HADRワーカースレッドの使用率が高い

HADRプール内の可用性グループのワーカースレッド数が、「通常、レプリカあたり3〜10個の共有スレッドがある」という最小使用量を大幅に超えるのはなぜですか？

1つのケースでは、3つの可用性グループと合計10のデータベースで300以上のスレッドの使用を観察しました。SQL Server 2014 SP1。

私たちのリードは、セカンダリレプリカのバックアップ、プライマリレプリカの高アクティビティ、セカンダリレプリカのレポートです。

AGはVMwareのデータセンターにあります。合計16のスケジューラー、通常のワーカースレッドは200未満の範囲です。サーバーのmax_dopは2です。

3 AG、10 DB、各4レプリカ-プライマリ、2読み取り専用、1読み取り不可。
セカンダリ1つは同期、2つは非同期
大規模なマルチホストクラスター上の物理32コア上の16 vcore。
過剰プロビジョニングはありません。
他の小さいVM 4-8コアは同じ場所に配置されますが、CPUを圧迫しません

ワーカースレッドのスパイクが原因でサービス拒否が発生したことが確認されました。AGへのワーカースレッドの帰属は、それらのワーカースレッドのみが制限を超えることができるため、私たちの仮定です。

以下のSQL Server Premier Field Engineerブログからのリンクは、コンテキストで読んでも完全な答えにはなりません。

— アレクサンダータラスル
ソース

あなたが見ているもののスクリーンショットの例を投稿できますか？特にAGスレッドではなく、一般的にワーカースレッドをクエリしているように、何かがここではうまくいかないようです。（そして、AGスレッドだけでなく、他のワーカースレッドも制限を超えることができます。）

— ブレントオザー

私は同様の問題を探しています。MaxDopの問題にまで釘付けにしたことを確認してください。IndexMaintenanceにOla Hallengreensスクリプトを使用していて、MaxDOP設定がNULLに設定されていました。ポイントは、あなたのMaxDOP 2を上書きするクエリを受け取ることができるかどうかです。

— Kasper Brandenburg

これに対する解決策はありましたか？

— トルシャ

-1

DCがVM上にあるため、ディスクパフォーマンスが低下していると思われます。ディスクのパフォーマンスが低いと、セカンダリでのログ書き込み時間が遅くなり、セカンダリレプリカからプライマリレプリカへの確認応答が遅くなる可能性があります（ワーカースレッドを使い果たす）。

セカンダリレプリカのディスク遅延により、HADR同期コミットプロセスが増加し、セカンダリがトランザクションを確認するのを待つ間、プライマリがオープンスレッドを保持する可能性があります。

デッドロックスケジューラのエラーログを確認し、PerfMonからいくつかのIOメトリックを収集して、ディスク遅延とディスクキューの長さを確認してください。

— ロドリゴ・ナセンテス
ソース