次の方法で共有

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

  • [アーティクル]

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

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

  • MIN_MEMORY_PERCENT および MAX_MEMORY_PERCENT

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

  • 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 のレベルが制御されます。

CPU またはメモリを構成する際には、すべてのプールの最小値の合計が、サーバー リソースの 100% を超えないようにする必要があります。 また、CPU またはメモリを構成する場合、最大値と上限値は、最小値～ 100% (両方を含む) の間で設定できます。

プールに 0 以外の最小値が定義されている場合は、他のプールの有効な最大値が再調整されます。 プールに設定されている最大値または他のプールの最小値の合計のいずれか大きい方が、100% から引かれます。

次の表は、前述の概念をいくつか説明しています。 表に示されているのは、内部プール、既定のプール、および 2 つのユーザー定義プールの設定です。 有効な最大 % および共有 % の計算には、次の式が使用されます。

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

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

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

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

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

プール名 最小 % の設定 最大 % の設定 有効な最大 % の計算値 共有 % の計算値 解説
内部 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 です。

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

プール名 最小 % の設定 最大 % の設定 有効な最大 % の計算値 共有 % の計算値 解説
内部 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% を表しているケース。 この場合、有効な最大値は最小値と等しくなります。 このとき、いずれかのプール内でサーバー リソースが消費されているかどうかにかかわらず、リソースを重複しない断片に分割した場合と同等の状態になります。

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

リソース ガバナーでは、内部プールと既定のプールの 2 つのリソース プールが事前に定義されます。

内部プール

内部プールは、 SQL Server 自体が消費するリソースを表します。 このプールは、常に内部グループのみを含んでおり、一切変更できません。 内部プールによるリソースの消費は制限されません。 このプール内のワークロードはサーバーの機能に不可欠と見なされ、内部プールが他のプールを圧迫して他のプールに設定されている制限に違反することになっても、リソース ガバナーはこれを許可します。

注意

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

既定のプール

既定のプールは、事前に定義される最初のユーザー プールです。 構成が行われる前の既定のプールには、既定のグループのみが含まれています。 既定のプールは作成または削除できませんが、変更することは可能です。 既定のプールには、既定のグループ以外にユーザー定義グループを含めることができます。

注意

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

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

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

リソース プール タスク

タスクの説明 トピック
リソース プールを作成する方法について説明します。 リソース プールの作成
リソース プールの設定を変更する方法について説明します。 リソース プールの設定の変更
リソース プールを削除する方法について説明します。 リソース プールの削除

参照

リソース ガバナー
リソース ガバナー ワークロード グループ
リソース ガバナーの分類子関数
テンプレートを使用してリソース ガバナーを構成する
リソース ガバナー プロパティの表示