最近、実稼働SQL Serverの累積スレッドプール待機を確認しました。これは、文字通り数日分の待機です。だから私はいくつかの掘削を始めました。
私は32コア、64ビットサーバー(EC2で実行)を使用しています。最大ワーカー数は構成で正しく0に設定されており、次のDMVは予想される正しい数を報告します。
SELECT max_workers_count FROM sys.dm_os_sys_info
Output: 960
私の総労働者数を見ると、300〜400を超える人はめったに見られません。
SELECT count(*) FROM sys.dm_os_workers
Output: 372
それでも、次のDMVを実行すると、alwaysスレッドがリストされます。
SELECT * FROM sys.dm_os_waiting_tasks
WHERE wait_type = 'THREADPOOL'
SELECT dow.state , dow.is_preemptive , dow.is_sick , dow.is_in_polling_io_completion_routine , [Num Workers] = COUNT(1)
FROM sys.dm_os_workers dow
GROUP BY dow.state , dow.is_preemptive , dow.is_sick , dow.is_in_polling_io_completion_routine;
ミリ秒単位の待機は通常かなり短く、一般に20〜200ミリ秒です。待機時間もすぐになくなりますが、全体的な累積スレッドプールの数値に追加されます。また、セッションをブロックすることもありません。
利用可能なワーカーが非常に多いときに、スレッドプールの待機が発生しているのはなぜですか。何百もの利用可能なワーカーがスレッドをスレッドプールに送らずにこれらのリクエストを即座に処理するべきではありませんか?
ここでの入力や指示に感謝します。
SQL Serverバージョン:SQL Server 2016(SP2-CU8)(KB4505830)-13.0.5426.0(X64)Enterprise Edition:(64ビット)on Windows Server 2016 Datacenter 10.0(Build 14393:)(Hypervisor)
max degree of parallelism をゼロ(デフォルト)に設定している場合、並列処理のメリットがあるクエリは32スレッドを消費します。ワーカーの数を960に設定すると、これもセットアップのデフォルトであり、30の同時並列クエリしか実行できません。
max parallel degree of parallelism を8のような正気なものにすすめる.