最近、SQL Server 2014 HADR環境で問題が発生し、サーバーの1つでワーカースレッドが不足しました。
メッセージを受け取りました:
AlwaysOn可用性グループのスレッドプールは、利用可能なワーカースレッドが十分にないため、新しいワーカースレッドを開始できませんでした。
問題を分析するのに役立つ(と思った)ステートメントを取得するために、別の質問を既に開いています( どのSPIDがどのスケジューラー(ワーカースレッド)を使用しているかを確認することは可能ですか? )。システムを使用しているスレッドを見つけるためのクエリを取得しましたが、そのサーバーがワーカースレッドを使い果たした理由がわかりません。
私たちの環境は次のとおりです。
したがって、問題が発生したサーバーには次の構成がありました。
MAXDOP = 8
Cost Threshold for Parallelism = 50
この問題を「解決」するために、1つの可用性グループをセカンダリサーバーに手動でフェールオーバーしました。そのサーバーの構成は次のとおりです。
私はこのステートメントで利用可能なスレッドを監視しています:
declare @max int
select @max = max_workers_count from sys.dm_os_sys_info
select
@max as 'TotalThreads',
sum(active_Workers_count) as 'CurrentThreads',
@max - sum(active_Workers_count) as 'AvailableThreads',
sum(runnable_tasks_count) as 'WorkersWaitingForCpu',
sum(work_queue_count) as 'RequestWaitingForThreads' ,
sum(current_workers_count) as 'AssociatedWorkers'
from
sys.dm_os_Schedulers where status='VISIBLE ONLINE'
通常、サーバーは約250〜430のワーカースレッドを使用できますが、問題が発生したとき、ワーカーは残っていませんでした。
今日、どこからともなく、利用可能な労働者は327から50に減少しましたが、1分間だけで、その後約400に戻りました。
私はすでに他の質問( HADRワーカースレッド使用率 )を見ましたが、それは私を助けません。
私たちのシステムは問題なく1年以上安定して動作しました。データベースのディストリビューションにフェイルオーバーやその他の大きな変更はありません。
レプリカ間で「同期コミット」を使用しています。私の理解から、関連する圧縮はありません。ドキュメントの 可用性グループの圧縮の調整 を参照してください。
誰がすべてのワーカースレッドを使用しているのか考えていますか?
編集:正確にそれらの問題に関する多くの情報があるこのページを見つけました http://www.techdevops.com/Article.aspx?CID=24
可用性グループに多数のデータベースがあり、それがスレッドの目的です。圧縮、暗号化、およびトランスポートのコストには多くのことが関係しています。圧縮をオフにしてみてください。これにより、スレッドの使用量が約3分の1になります(レプリカの数によって異なります)。
質問にはSQL Server 2014のタグが付けられており、デフォルトで圧縮が使用されます。 SQL Server 2016では、デフォルトで、同期に圧縮は使用されません。
インスタンスのワーカースレッドを増やす必要がある場合があります。つまり、複数のサーバーで最もアクティブなスレッドと非アクティブなスレッドのバランスをとります。関連するQ&A AlwaysON可用性グループのクエリが非常に遅い を参照してください。
また、リクエストを適切に閉じることができないアプリケーションである場合もあります。これにより、多くの睡眠セッションが発生する可能性があります(これにより、ワーカーが消費されます)。
実際に使用されるスレッドの数は、データベースのアクティブ度によって異なります。 1,000個のデータベースを使用でき、ほとんどが95%の時間アイドル状態であれば、問題は発生しません。データベースがより頻繁にアクティブになり、より多くのスレッドを消費しているようです。それは長くて短いです。