並列クエリ実行エラーを理解する必要がある

今日、実稼働SQLサーバーのパフォーマンスが低下しました。これが発生した間、いくつかの"The query processor could not start the necessary thread resources for parallel query execution"エラーを記録しました。私が読んだことは、これが複雑なクエリを実行するときに使用するCPUの数に関係していることを示唆しています。しかし、私は停電たちの中にチェックするときCPU Utilization was only at 7%。私がまだ出くわしていない、これが参照している可能性のある他の何かがありますか？これはパフォーマンス低下の原因である可能性がありますか、それともニシンを追いかけていますか？

これに対する私のsp_configure値は次のとおりです。

name                                minimum maximum config_value run_value
cost threshold for parallelism      0       32767   5            5

数か月前、MAXDOP設定がデフォルトであり、暴走クエリがすべてのワーカースレッドを使い果たしたという同様の状況に直面しました。

Remusが指摘したように、これはワーカースレッドの飢vと呼ばれます。

この状態が発生すると、サーバー上にメモリダンプが作成されます。

2008R2 + SP1以降を使用しsys.dm_server_memory_dumpsている場合は、ダンプファイルの場所も表示されます。

問題に戻りましょう。

NUMAノードごとに1つのスケジューラモニタースレッドがあり、2つのNUMAノードがあるため、スケジューラがスタックしていることを確認しながら、特定のNUMAノードの60秒ごとにすべてのスケジューラーのヘルスチェックを行う2つのスケジューラモニタースレッドがありますありません。

スケジューラのワーカーキューから新しい作業要求がプルされるたびに、作業プロセスカウンターがインクリメントされます。そのため、スケジューラが作業要求をキューに入れており、60秒以内に作業要求の1つを処理していない場合、スケジューラはスタックしていると見なされます。

暴走クエリまたは大規模な並列処理により、すべてのスレッドが単一の暴走クエリまたは過度の長時間のブロッキングによって占有され、問題のプロセスが強制終了されない限り作業を実行できないため、ワーカースレッドが使い果たされるという状態が発生します。

最善の策は、最初にMax Degree of Parallelism設定を調整することです。デフォルトで0 は、SQL Serverはすべてのワーカースレッドを使い果たすことにより、並列処理に使用可能なすべてのCPUを使用できます。

ワーカースレッドの枯渇につながる多くの理由があります。

• SQL Serverがワーカースレッドを使い果たす原因となる広範な長いブロッキングチェーン
• ワーカースレッドの枯渇につながる広範な並列処理
• あらゆるタイプの「ロック」を待つ-スピンロック、ラッチ。孤立したスピンロックがその一例です。

私の答えを参照してくださいここにあなたがあなたのサーバーインスタンスに対してMAXDOP値を計算することができる方法を紹介します。

また、データベースサーバーインスタンスに関する待機統計情報の収集を開始することを強くお勧めします。

いくつかの理由が考えられます。最も可能性が高いのは、あなたが労働者を失ったことです。をご覧くださいmax_worker_threads。この状態は「労働者の搾取」と呼ばれます。ワーカーは、多くの要求がブロックされたり、CLRで愚かなこと（HTTP要求など）を行ったりするなど、複数の手段（いずれもCPU使用率が高くなることはありません）のいずれかによって盗まれる可能性があります。

表示される症状は問題の犠牲者であり、原因ではありません。原因がわからないソリューションを推奨することはできません。パフォーマンスカウンター、DMVを収集し、ERRORLOGで詳細を確認する必要があります。