サーバー構成: ワーカー スレッドの最大数

適用対象:SQL Server

この記事では、SQL Server Management Studio または Transact-SQL を使用して、SQL Server で max worker threads サーバー構成オプションを構成する方法について説明します。 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;

推奨事項

このオプションは高度なオプションであり、経験豊富なデータベースプロフェッショナルのみが変更する必要があります。

パフォーマンスの問題が疑われる場合、それはおそらく使用可能なワーカー スレッドの数の問題ではありません。 この原因は、ワーカー スレッドを占有するアクティビティに関連している可能性が高いので、ワーカー スレッドを解放しないでください。 たとえば、長時間実行されているクエリや、長時間待機するクエリの原因となるシステムのボトルネック(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 ビット コンピューター 64 ビット コンピューター
<= 4 256 512
> 4 256 + ((論理 CPU - 4) * 8) 512 †† + ((論理プロセッサ - 4) * 16)

SQL Server 2016 (13.x) 以降では、SQL Server を 32 ビット オペレーティング システムにインストールできなくなりました。 32 ビット コンピューターの値は、 SQL Server 2014 (12.x) 以前のバージョンを実行しているお客様への参考として一覧表示されています。 32 ビット コンピューター上で動作する SQL Server のインスタンスの場合、ワーカー スレッドの最大数として 1,024 をお勧めします。

†† SQL Server 2017 (14.x) 以降では、メモリが 2 GB 未満のマシンでは 、既定の最大ワーカー 数の値が 2 で除算されます。

SQL Server 2016 (13.x) SP2 および SQL Server 2017 (14.x) 以降の "CPU あたりのワーカー数" は、アーキテクチャとプロセッサの数 (4 から 64 の間か、64 を超えるか) に依存します。

論理CPU数 32 ビット コンピューター 64 ビット コンピューター
<= 4 256 512
> 4 かつ <= 64 256 + ((論理 CPU - 4) * 8) 512 †† + ((論理プロセッサ - 4) * 16)
> 64 256 + ((論理 CPU - 4) * 32) 512 †† + ((論理プロセッサ - 4) * 32)

SQL Server 2016 (13.x) 以降では、SQL Server を 32 ビット オペレーティング システムにインストールできなくなりました。 32 ビット コンピューターの値は、 SQL Server 2014 (12.x) 以前のバージョンを実行しているお客様への参考として一覧表示されています。 32 ビット コンピューター上で動作する SQL Server のインスタンスの場合、ワーカー スレッドの最大数として 1,024 をお勧めします。

†† 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) の使用

  1. オブジェクト エクスプローラーで、サーバーを右クリックし、 [プロパティ] をクリックします。

  2. [プロセッサ] ノードを選択します。

  3. [ワーカー スレッド最大数] ボックスに、128 から 65,535 の値を入力するか、または選択します。

ヒント

max worker threads オプションを使用して、SQL Server プロセスで使用できるワーカー スレッド数を設定できます。 max worker threads の既定の設定は、ほとんどのシステムで最適な設定です。 ただし、システム構成によっては、max worker threads の値を小さくするとパフォーマンスが向上することがあります。 詳細については、この記事の「推奨事項」セクションを参照してください。

Transact-SQL の使用

  1. データベース エンジンに接続します。

  2. 標準バーから、 [新しいクエリ] を選択します。

  3. 次の例をコピーしてクエリ ウィンドウに貼り付け、 [実行] を選択します。 この例では、 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 の実行後、データベース エンジン を再起動しなくても、変更は直ちに有効になります。