max worker threads サーバー構成オプションを構成する

適用対象: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、ロック マネージャーなどのタスクに必要なシステム スレッドは、この制限の外部で生成されます。 可用性グループでは、ワーカー スレッドの制限内で一部のワーカー スレッドが使用されますが、システム スレッドも使用されます (「可用性グループによるスレッドの使用」を参照してください)。構成されているスレッドの数を超えた場合は、次のクエリによって、追加のスレッドを生成したシステム タスクに関する情報を確認できます。

  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)

  ¹ 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 の値を入力するか、または選択します。

ヒント

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

Transact-SQL の使用

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

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

3. 次の例をコピーしてクエリ ウィンドウに貼り付け、 [実行] を選択します。 この例では、 sp_configure を使用して、 max worker threads オプションを 900に設定する方法を示します。

EXEC sp_configure 'show advanced options', 1;
GO

RECONFIGURE;
GO

EXEC sp_configure 'max worker threads', 900;
GO

RECONFIGURE;
GO

RECONFIGURE の実行後、データベース エンジン を再起動しなくても、変更は直ちに有効になります。

関連項目

• サーバー構成オプション (SQL Server)
• RECONFIGURE (Transact-SQL)
• sp_configure (Transact-SQL)
• データベース管理者用の診断接続