サーバー構成: ワーカー スレッドの最大数
適用対象: 
SQL Server
この記事では、SQL Server Management Studio または Transact-SQL を max worker threads 使用して SQL Server のサーバー構成オプションを構成する方法について説明します。 このオプションは max worker threads 、クエリ要求、ログイン、ログアウト、および同様のアプリケーション要求を処理するために SQL Server 全体で使用できるワーカー スレッドの数を構成します。
SQL Server は、オペレーティング システムのネイティブ スレッド サービスを使用して、次の条件を確認します。
- 1 つ以上のスレッドが、SQL Server がサポートする各ネットワークを同時にサポートします。
- 1 つのスレッドがデータベース チェックポイントを処理します。
- スレッドのプールがすべてのユーザーを処理します。
max worker threads の既定値は 0 です。 この場合、ワーカー スレッドの数が、 SQL Server によって起動時に自動で構成されます。 既定の設定は、ほとんどのシステムで最適な設定です。 ただし、システム構成によっては、特定の値に設定 max worker threads するとパフォーマンスが向上することがあります。
制限事項
クエリ要求の実際の数は、 max worker threads 設定された値を超える可能性があります。この場合、SQL Server は、次に使用可能なワーカー スレッドが要求を処理できるようにワーカー スレッドをプールします。 ワーカー スレッドはアクティブな要求にのみ割り当てられ、要求が処理されると解放されます。 これは、要求が行われたユーザー セッション/接続が開いたままになっている場合でも発生します。
max worker threadsサーバー構成オプションでは、エンジン内で生成される可能性のあるすべてのスレッドが制限されるわけではありません。 レイジーライター、チェックポイント、ログ ライター、Service Broker、ロック マネージャーなどのタスクに必要なシステム スレッドは、この制限の外部で生成されます。 可用性グループは、ワーカー スレッドの一部を内部max worker thread limitから使用しますが、システム スレッドも使用します (可用性グループ別のスレッド使用量を参照)。 構成されているスレッドの数を超えている場合、次のクエリは、追加のスレッドを生成したシステム タスクに関する情報を提供します。
SELECT s.session_id,
r.command,
r.status,
r.wait_type,
r.scheduler_id,
w.worker_address,
w.is_preemptive,
w.state,
t.task_state,
t.session_id,
t.exec_context_id,
t.request_id
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_exec_requests AS r
ON s.session_id = r.session_id
INNER JOIN sys.dm_os_tasks AS t
ON r.task_address = t.task_address
INNER JOIN sys.dm_os_workers AS w
ON t.worker_address = w.worker_address
WHERE s.is_user_process = 0;
推奨事項
このオプションは詳細設定オプションであるため、熟練したデータベース管理者または認定された SQL Server プロフェッショナルだけが変更するようにしてください。 パフォーマンスの問題があると思われる場合は、おそらくワーカー スレッドの可用性ではありません。 この原因は、ワーカー スレッドを占有するアクティビティに関連している可能性が高いので、ワーカー スレッドを解放しないでください。 たとえば、長時間実行しているクエリやシステム上のボトルネック (I/O、ブロッキング、ラッチ待機、ネットワーク待機) などがあります。 最大ワーカー スレッドの設定を変更する前に、パフォーマンスの問題の根本原因を見つけることをお勧めします。 パフォーマンスの評価の詳細については、「パフォーマンスの監視とチューニング」を参照してください。
スレッド プールは、多数のクライアントがサーバーに接続する場合のパフォーマンスの最適化に役立ちます。 通常、クエリ要求ごとに個別のオペレーティング システム スレッドが作成されます。 ただし、サーバーへの接続が数百にもなる場合、クエリ要求ごとに 1 つのスレッドを使用すると大量のシステム リソースが消費されることがあります。 この max worker threads オプションを使用すると、SQL Server は、より多くのクエリ要求にサービスを提供するワーカー スレッドのプールを作成できるため、パフォーマンスが向上します。
次の表では、論理 CPU、コンピューターのアーキテクチャ、SQL Server のバージョンのさまざまな組み合わせに対して、自動的に構成されるワーカー スレッドの最大数 (値を 0 に設定した場合) を示します。"既定の最大ワーカー数" + (("論理 CPU 数" - 4) * "CPU あたりのワーカー数") という式が使用されています。
| 論理 CPU 数 | 32 ビット コンピューター (SQL Server 2014 (12.x) 以前) | 64 ビット コンピューター (SQL Server 2016 (13.x) SP1 以前) | 64 ビット コンピューター (SQL Server 2016 (13.x) SP2 および SQL Server 2017 (14.x) 以降) |
|---|---|---|---|
| <= 4 | 256 | 512 | 512 |
| 8 | 288 | 576 | 576 |
| 16 | 352 | 704 | 704 |
| 32 | 480 | 960 | 960 |
| 64 | 736 | 1472 | 1472 |
| 128 | 1248 | 2496 | 4480 |
| 256 | 2272 | 4544 | 8576 |
SQL Server 2016 (13.x) (Service Pack 1 適用済み) 以前の "CPU あたりのワーカー数" は、アーキテクチャ (32 ビットまたは 64 ビット) にのみ依存します。
| 論理 CPU 数 | 32 ビット コンピューター 1 | 64 ビット コンピューター |
|---|---|---|
| <= 4 | 256 | 512 |
| > 4 | 256 + ((論理 CPU - 4) * 8) | 512 2 + ((論理 CPU - 4) * 16) |
SQL Server 2016 (13.x) SP2 および SQL Server 2017 (14.x) 以降の "CPU あたりのワーカー数" は、アーキテクチャとプロセッサの数 (4 から 64 の間か、64 を超えるか) に依存します。
| 論理 CPU 数 | 32 ビット コンピューター 1 | 64 ビット コンピューター |
|---|---|---|
| <= 4 | 256 | 512 |
| > 4 かつ <= 64 | 256 + ((論理 CPU - 4) * 8) | 512 2 + ((論理 CPU - 4) * 16) |
| > 64 | 256 + ((論理 CPU - 4) * 32) | 512 2 + ((論理 CPU - 4) * 32) |
1 SQL Server 2016 (13.x) 以降の SQL Server は、32 ビットのオペレーティング システムにインストールすることはできません。 32 ビット コンピューターの値は、 SQL Server 2014 (12.x) 以前のバージョンを実行しているお客様への参考として一覧表示されています。 32 ビット コンピューター上で動作する SQL Server のインスタンスの場合、ワーカー スレッドの最大数として 1,024 をお勧めします。
2 SQL Server 2017 (14.x) 以降の "既定の最大ワーカー数" の値は、メモリが 2 GB 未満のコンピューターの場合は 2 で除算されます。
ヒント
64 個を超える論理 CPU を使用する場合の詳細については、「64 個を超える CPU を搭載したコンピューター上で SQL Server を実行する場合のベスト プラクティス」を参照してください。
クエリの実行が長時間にわたり、すべてのスレッドがアクティブになっている場合、いずれかのワーカー スレッドが処理を完了し使用できるようになるまで、 SQL Server が応答していないように見えることがあります。 この動作は欠陥ではありませんが、望ましくない場合があります。 プロセスが応答せず新しいクエリを処理できない場合は、専用管理者接続 (DAC) を使用して SQL Server に接続し、プロセスを終了します。 このような状態を回避するには、ワーカー スレッド数を増やします。
アクセス許可
パラメーターなしで、または最初のパラメーターだけを指定して sp_configure を実行する権限は、既定ですべてのユーザーに付与されます。 両方のパラメーターを指定して sp_configure を実行し構成オプションを変更したり RECONFIGURE ステートメントを実行したりするには、ALTER SETTINGS サーバーレベル権限がユーザーに付与されている必要があります。 ALTER SETTINGS 権限は、sysadmin 固定サーバー ロールと serveradmin 固定サーバー ロールでは暗黙のうちに付与されています。
SQL Server Management Studio (SSMS) の使用
オブジェクト エクスプローラーで、サーバーを右クリックし、 [プロパティ] をクリックします。
[プロセッサ] ノードを選択します。
[ワーカー スレッド最大数] ボックスに、128 から 65,535 の値を入力するか、または選択します。
ヒント
オプションを max worker threads 使用して、SQL Server プロセスで使用できるワーカー スレッドの数を構成します。 既定の設定 max worker threads は、ほとんどのシステムに最適です。
ただし、システム構成によっては、値を小さく設定 max worker threads するとパフォーマンスが向上することがあります。
詳細については、この記事の「推奨事項」セクションを参照してください。
Transact-SQL の使用
データベース エンジンに接続します。
標準バーから、 [新しいクエリ] を選択します。
次の例をコピーしてクエリ ウィンドウに貼り付け、 [実行] を選択します。 この例では、 sp_configure を使用して、
max worker threadsオプションを900に設定する方法を示します。USE master; GO EXECUTE sp_configure 'show advanced options', 1; GO RECONFIGURE; GO EXECUTE sp_configure 'max worker threads', 900; GO RECONFIGURE; GO EXECUTE sp_configure 'show advanced options', 0; GO RECONFIGURE; GO
RECONFIGURE の実行後、データベース エンジン を再起動しなくても、変更は直ちに有効になります。