並列クエリ実行エラーを理解する必要がある
今日、本番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が指摘したように、これはworker thread starvationと呼ばれます。
この状態が発生すると、サーバーにメモリダンプが作成されます。
2008R2 + SP1以降を使用している場合は、sys.dm_server_memory_dumpsは、ダンプファイルの場所も提供します。
さて、問題に戻ってください：
NUMAノードごとに1つのスケジューラーモニタースレッドがあり、2つのNUMAノードがあるため、スケジューラーがスタックしていることを確認しながら、その特定のNUMAノードのすべてのスケジューラーのヘルスチェックを担当する2つのスケジューラーモニタースレッドがあります。ない。
新しい作業要求がスケジューラのワーカーキューからプルされるたびに、work processesカウンタが増分されます。そのため、スケジューラーが作業要求をキューに入れていて、60秒以内に作業要求の1つを処理していない場合、スケジューラーはスタックしていると見なされます。
ランナウェイクエリまたは広範な並列処理により、すべてのスレッドがその単一のランナウェイクエリまたは過度の長時間のブロックによって占有され、問題のプロセスが強制終了しない限り作業を実行できないため、ワーカースレッドが使い果たされ始める状態が発生します。
あなたの最善の策は、最初にMax Degree of Parallelism設定を調整することです。デフォルトの0は、SQL Serverが利用可能なすべてのCPUを並列処理に使用できることを意味し、すべてのワーカースレッドを使い果たします。
ワーカースレッドの枯渇につながる可能性がある多くの理由があります。
- 広範囲にわたる長いブロッキングチェーンにより、SQL Serverでワーカースレッドが不足する
- 広範な並列処理は、ワーカースレッドの枯渇にもつながります
- あらゆるタイプの「ロック」（スピンロック、ラッチ）に対する広範な待機。孤立したスピンロックがその例です。
サーバーインスタンスのMAXDOP値を計算する方法を示す私の回答 こちら を参照してください。
また、データベースサーバーインスタンスに関する待機統計情報の収集を開始することを強くお勧めします。
いくつかの理由が考えられます。おそらくあなたは労働者の外にいたということです。見る - max_worker_threads 。この状態は「労働者の飢餓」と呼ばれます。多くのリクエストをブロックしたり、CLRで愚かなこと（HTTPリクエストなど）を実行したりするなど、ワーカーは複数の手段のいずれかで盗まれる可能性があります（いずれもCPU使用率が高くなります）。
表示される症状は問題の犠牲者であり、原因ではありません。原因がわからない解決策はお勧めできません。詳細については、パフォーマンスカウンター、DMVを収集し、ERRORLOGを確認する必要があります。