SQLServerリソースガバナーのユーザー定義リソースプール
SQL Serverリソースガバナーのコンテキストで、ユーザー定義のリソースプールを作成するのはなぜですか？すべてにデフォルトのリソースプールを使用し、代わりにワークロードグループ設定を使用してリソースを制御することで、ほぼ同じ結果が得られるようです。
作成するリソースプールが多すぎると問題が発生する可能性があると聞いたので、ワークロードグループの設定に比べてどのような利点があるのでしょうか。
リソースプールは、サーバーのCPU、メモリ、およびIO）を物理的に分割するものと考えてください。これは、重複するワークロードによって使用されるリソースを制限する必要がある場合に役立ちます。ワークロードグループは、使用されるリソースをさらに制限します。プール内のクエリレベルで。これは、ワークロード内で使用されるリソースを制限する必要がある場合、おそらくスループットを向上させるために役立ちます。
リソースガバナーの概要 は、リソースグループではなくリソースプールでのみ満たすことができるいくつかのユースケースを提供します。例えば：
スロットルIO IOサブシステムを飽和させ、他のワークロードに悪影響を与える可能性のあるDBCCCHECKDBなどの操作用のリソース。
リソースプールには、IOを制限するためのMIN_IOPS_PER_VOLUMEおよびMAX_IOPS_PER_VOLUMEオプションがあります。ワークロードグループには、IOを制限するオプションはありません。
ワークロードグループは、CPU使用率を制御する方法にも制限があります。 REQUEST_MAX_CPU_TIME_SECオプションは、クエリによってCPUにハード制限を実際に強制しません。
リソースガバナーは、最大時間を超えてもリクエストの続行を妨げることはありません。ただし、イベントは生成されます。詳細については、「CPUしきい値超過イベントクラス」を参照してください。
ワークロードグループを介してCPUを適切に制限するには、ワークロードグループにMAXDOPオプションを使用する必要がありますが、それでは十分に細かくない場合があります。リソースプールは、暴走クエリがサーバーで使用可能なすべてのCPUを使用するのを防ぐためのはるかに優れたオプションを提供します。
ワークロードグループを使用して、競合するワークロードに対するクエリメモリの付与とGROUP_MAX_REQUESTSおよびREQUEST_MAX_MEMORY_GRANT_PERCENTオプションのバランスをとることができるように思われるかもしれません。ただし、さまざまなサイズの数千のクエリを送信して、一度に最大40のクエリの同時実行でサーバーに対して実行するワークロードについて考えてみます。クエリのごく一部はメモリを大量に消費し、チェックを外したままにすると、クエリの許可に使用可能なすべてのメモリが使用されます。パフォーマンステストを通じて、REQUEST_MAX_MEMORY_GRANT_PERCENTを4％に制限すると、全体的なスループットが妥当であることがわかります。ワークロードグループを介してのみこれを構成した場合、次のようになります。
GROUP_MAX_REQUESTS = 40
REQUEST_MAX_MEMORY_GRANT_PERCENT = 4
これにより、そのワークロードのパフォーマンスは向上する可能性がありますが、サーバー上のすべてのメモリを使用する可能性があります。別のワークロードを同時に実行する必要がある場合は、リソースプールレベルで構成を行う必要があります。元のワークロードがサーバー上のメモリの50％で処理できると判断したとします。プールレベルでは、次のように設定できます。
MAX_MEMORY_PERCENT = 50
また、ワークロードグループレベルでは、次のように設定できます。
GROUP_MAX_REQUESTS = 40
REQUEST_MAX_MEMORY_GRANT_PERCENT = 8
これにより、最初のワークロードに適切なスループットが得られますが、2番目のワークロードを同時に実行することもできます。リソースプールは、ワークロード間でリソースを分割するために使用され、ワークロードグループは、プールに属するクエリ間でリソースを分割するために使用されます。