次の方法で共有

リソース ガバナー リソース プール

  • [アーティクル]

適用対象: SQL Server Azure SQL Managed Instance

SQL Server のリソース ガバナーでは、リソース プールは、データベース エンジン インスタンスの物理リソースのサブセットを表します。 リソース ガバナーを使用すると、受信するアプリケーション要求がリソース プール内で使用できる CPU、物理 IO、およびメモリの量に制限を指定できます。 各リソース プールは、1 つまたは複数のワークロード グループを含めることができます。 セッションの起動時に、リソース ガバナーの分類子によって、セッションは指定されたワークロード グループに割り当てられます。セッションの実行にはワークロード グループに割り当てられたリソースを使用する必要があります。

リソース プールの概念

リソース プール (プール) は、サーバーの物理リソースを表します。 プールは、SQL Server インスタンス内部の仮想 SQL Server インスタンスと考えることができます。 プールは 2 つの部分で構成されます。 1 つは他のプールと重複しない部分であり、最小限のリソース予約をサポートします。 もう 1 つは他のプールと共有される部分であり、最大限のリソース消費をサポートします。 プール リソースを定義するには、各リソース (CPU、メモリ、および物理 I/O) で次の設定の 1 つ以上を指定します。

MIN_CPU_PERCENT および MAX_CPU_PERCENT

これらの設定は、CPU の競合がある場合にリソース プールのすべての要求に最大限および最小限保証される平均 CPU 帯域幅です。 これらの設定を使用すると、各ワークロードのニーズに基づく、複数のワークロードの予測可能な CPU リソース使用率を確立できます。 たとえば、会社の営業部門とマーケティング部門で同じデータベースを共有するとします。 営業部門には、優先度の高いクエリで CPU を集中的に使用するワークロードがあります。 マーケティング部門にも CPU を集中的に使用するワークロードがありますが、クエリの優先度は低くなっています。 各部門に個別のリソース プールを作成することにより、営業部門のリソース プールに対して CPU の割合の 最小値 70 を、マーケティング部門のリソース プールに対して CPU の割合の 最大値 30 を割り当てることができます。 この構成により、営業部門のワークロードは必要な CPU リソースを受け取り、マーケティング部門のワークロードは営業部門のワークロードの CPU 要求から分離されるようになります。 CPU の最大使用率は便宜上の最大値です。 使用可能な CPU 容量がある場合、ワーカー スレッドはそのすべてを最大 100% 使用します。 最大値が適用されるのは、CPU リソースに競合が発生した場合のみです。 この例では、営業部門のワークロードがオフに切り替わると、マーケティング部門のワークロードは必要に応じて 100% の CPU を使用できます。

CAP_CPU_PERCENT

CAP_CPU_PERCENT 設定によって、リソース プールのすべての要求に対する CPU 帯域幅にハード キャップの制限が設定されます。 プールに関連付けられているワークロードは、使用する CPU 処理量が MAX_CPU_PERCENT の値を超えることはできても (利用可能な場合)、CAP_CPU_PERCENT の値を超えることはできません。 前のセクションの例に基づいて、マーケティング部門がリソース使用量に対して課金されていると仮定します。 マーケティング部門は予測可能な請求情報を求めていますが、CPU のうち最大 30% までしか料金を支払いたくありません。 この目標を実現するには、マーケティング部門のリソース プールの CAP_CPU_PERCENT を 30 に設定します。

MIN_MEMORY_PERCENT および MAX_MEMORY_PERCENT

リソース プール用に確保され、他のリソース プールとは共有できないメモリ量の最大値と最小値を設定します。 メモリ最適化テーブルのないデータベースの場合、参照されるメモリは、クエリ実行許可メモリであり、バッファー プール メモリ (データ ページやインデックス ページなど) ではありません。 クエリ実行メモリ許可の詳細については、「メモリ許可に関する考慮事項」を参照してください。 プールの最小メモリ値を設定すると、指定されたメモリの割合が、このリソース プールで実行されるすべてのリクエストに使用できるようになります。 この設定は MIN_CPU_PERCENT とは異なります。この場合、指定されたリソース プールに、このプールに属するワークロード グループにリクエストがない場合でもメモリが残る可能性があるためです。 したがって、アクティブなリクエストがない場合でも、このメモリは他のプールで使用できないため、この設定を使用する場合は注意してください。 プールの最大メモリ値を設定することは、要求がこのプールで実行されているときに、メモリ全体のうちこの割合を超えるメモリを取得することがないことを意味します。

Resource Governor でメモリ最適化テーブルのメモリを制御するには、データベースを個々のリソース プールにバインドします。 詳細については、「メモリ最適化テーブルを持つデータベースのリソース プールへのバインド」を参照してください。

AFFINITY

この設定を使用すると、CPU リソースの分離を向上するために、リソース プールを 1 つ以上のスケジューラまたは NUMA ノードに関連付けることができます。 前のセクションの営業およびマーケティングのシナリオを使用するにあたり、営業部門がより分離された環境を必要とし、常に 100% の CPU コアを必要としていると仮定します。 AFFINITY オプションを使用すると、営業部門とマーケティング部門のワークロードを異なる CPU でスケジュールできます。 マーケティング部門のプールの CAP_CPU_PERCENT がまだ設定されていると仮定すると、マーケティング部門のワークロードでは、引き続き 1 個のコアの最大 30% を使用するのに対し、営業部門のワークロードでは、他のコアの 100% を使用します。 営業部門とマーケティング部門のワークロードに関しては、2 つの分離されたコンピューターで実行されています。

MIN_IOPS_PER_VOLUME および MAX_IOPS_PER_VOLUME

リソース プールのディスク ボリュームごとに、1 秒あたりの物理 IO 操作 (IOPS) の最小値と最大値を設定します。 これらの設定を使用すると、特定のリソース プールのユーザー スレッドに対して発行された物理 IO を制御できます。 たとえば、営業部門では、大きなバッチで月末の報告書をいくつか生成します。 これらのバッチ内のクエリでは、ディスク ボリュームが飽和し、データベース内のその他の優先度の高いワークロードのパフォーマンスに影響を与える可能性のある IO が生成される可能性があります。 このワークロードを分離するために、営業部門のリソース プールの MIN_IOPS_PER_VOLUME が 20 に設定され、MAX_IOPS_PER_VOLUME が 100 に設定されます。 これらの設定は、ワークロードに対して発行できる IO のレベルを制御します。

システムおよびユーザー定義のリソース プール

リソース ガバナーでは、内部プールと既定のプールの 2 つのリソース プールが事前に定義されます。 必要に応じて、プールを作成することもできます。

内部プール

内部プールは、SQL Server 自体が消費するリソースを表します。 このプールには常に内部グループのみが含まれており、プールはいかなる方法でも変更できません。 内部プールによるリソースの消費は制限されません。 プール内のすべてのワークロードは、サーバー機能にとって重要と見なされます。 したがって、リソース ガバナーは、他のプールに設定された制限の違反を意味する場合でも、内部プールが他のプールに圧力をかけることを許可します。

Note

内部プールおよび内部グループのリソース使用量は、全体的なリソース使用量から差し引かれません。 パーセンテージは、使用可能なリソース全体から計算されます。

既定のプール

既定のプールは、事前に定義される最初のユーザー プールです。 構成が行われる前の既定のプールには、既定のグループのみが含まれています。 既定のプールを作成または削除することはできませんが、変更することはできます。 既定のプールには、既定のグループ以外にユーザー定義グループを含めることができます。 SQL Server 2016 (13.x) 以降では、日常的な SQL Server 操作用の既定のリソース プールと、R スクリプトの実行などの外部プロセス用の既定の外部リソース プールがあります。

Note

既定のグループは変更できますが、既定のプールから移動することはできません。

外部プール

ユーザーは、外部プロセス用のリソースを定義する外部プールを作成できます。 R Services の場合、このプールは具体的には rterm.exe、BxlServer.exe、python.exe およびそれらにより生成された他のプロセスが制御されます。 詳細については、「CREATE EXTERNAL RESOURCE POOL」を参照してください。

ユーザー定義のリソース プール

ユーザー定義のリソース プールは、環境内の特定のワークロードに対して作成するリソース プールです。 リソース ガバナーには、リソース プールを作成、変更、および削除するための DDL ステートメントが用意されています。 詳細については、「リソース共有元の作成」、「リソース共有元の削除」、および「リソース共有元の設定の変更」を参照してください。

プール間のリソースの割り当て

CPU またはメモリを構成する際には、すべてのプールの最小値の合計が、サーバー リソースの 100% を超えないようにする必要があります。 また、CPU またはメモリを構成する場合、最大値と上限値は、最小値～ 100% (両方を含む) の間で設定できます。
プールに 0 以外の最小値が定義されている場合は、他のプールの有効な最大値が再調整されます。 プールに設定されている最大値または他のプールの最小値の合計のいずれか大きい方が、100% から引かれます。

次の表は、前述の概念をいくつか説明しています。 表に示されているのは、内部プール、既定のプール、および 2 つのユーザー定義プールの設定です。

プール名 最小 % の設定 最大 % の設定 有効な最大 % の計算値 共有 % の計算値 コメント
internal 0 100 100 0 内部プールには有効な最大 % と共有 % が適用されません。
default 0 100 30 30 有効な最大値の計算式は、min(100,100-(20+50)) = 30 です。 共有 % の計算式は、有効な最大値 - 最小値 = 30 です。
プール 1 20 100 50 30 有効な最大値の計算式は、min(100,100-50) = 50 です。 共有 % の計算式は、有効な最大値 - 最小値 = 30 です。
プール 2 50 70 70 20 有効な最大値の計算式は、min(70,100-20) = 70 です。 共有 % の計算式は、有効な最大値 - 最小値 = 20 です。

テーブルの有効な最大 % および共有 % の計算には、次の式が使用されます。

  • min(X,Y) は、X と Y の小さい方の値を意味します。

  • sum(X) はすべてのプールの X 値の合計を意味します。

  • 共有 % の合計 = 100 - sum(最小 %)。

  • 有効な最大 % = min(X,Y)。

  • 共有 % = 有効な最大 % - 最小 %。

前のテーブルを例として、別のプールが作成されたときに行われる調整について説明します。 作成するのはプール 3 で、その最小 % の設定は 5 です。

プール名 最小 % の設定 最大 % の設定 有効な最大 % の計算値 共有 % の計算値 コメント
internal 0 100 100 0 内部プールには有効な最大 % と共有 % が適用されません。
default 0 100 25 25 有効な最大値の計算式は、min(100,100-(20+50+5)) = 25 です。 共有 % の計算式は、有効な最大値 - 最小値 = 25 です。
プール 1 20 100 45 25 有効な最大値の計算式は、min(100,100-55) = 45 です。 共有 % の計算式は、有効な最大値 - 最小値 = 25 です。
プール 2 50 70 70 20 有効な最大値の計算式は、min(70,100-25) = 70 です。 共有 % の計算式は、有効な最大値 - 最小値 = 20 です。
プール 3 5 100 30 25 有効な最大値の計算式は、min(100,100-70) = 30 です。 共有 % の計算式は、有効な最大値 - 最小値 = 25 です。

プールの共有部分は、使用可能なリソースの行き先を示すために使用されます。 ただし、リソースが消費されると、共有部分は指定のプールに移動し、共有されません。 このビヘイビアーにより、指定のプールに要求がなく、かつそのプールに対して構成されたリソースを他のプールのために解放できる場合は、リソース使用率が向上する可能性があります。

プール構成の極端なケースを次に示します。

  • すべてのプールで最小値が定義され、その合計がサーバー リソースの 100% を表しているケース。 この場合、有効な最大値は最小値と等しくなります。 このとき、いずれかのプール内でサーバー リソースが消費されているかどうかにかかわらず、リソースを重複しない断片に分割した場合と同等の状態になります。

  • すべてのプールの最小値がゼロであるケース。 すべてのプールが使用可能なリソースの確保を求めて競合し、それぞれの最終的なサイズが各プールのリソース消費に基づいて決まります。 ポリシーなどその他の要因も、最終的なプール サイズの決定に影響します。

リソース プール タスク

タスクの説明 [アーティクル]
リソース プールを作成する方法について説明します。 リソース プールの作成
リソース プールの設定を変更する方法について説明します。 リソース プールの設定の変更
リソース プールを削除する方法について説明します。 リソース プールの削除

関連項目