リソース ガバナー

適用対象: SQL Server Azure SQL Managed Instance

SQL Server Resource Governor は、SQL Server のワークロードとシステム リソースの消費を管理するために使用できる機能です。 Resource Governor を使用すると、着信アプリケーション要求で使用できる CPU、物理 I/O、およびメモリの量に対して制限を指定できます。

リソース ガバナーの利点

Resource Governor を使用すると、受信要求によるリソースの使用に関する制限を指定して SQL Server のワークロードとリソースを管理できます。 リソース ガバナーでは、同程度のサイズの複数のクエリや要求を 1 つのエンティティとして扱う場合、それらをワークロードと呼んでいます。 これは必須ではありませんが、ワークロードのリソースの使用パターンが統一化されていると、リソース ガバナーから得られる利点も増えます。 リソース制限は、実行中のワークロードへの影響を最小限に抑えながらリアルタイムで再構成できます。

複数の個別のワークロードが同一サーバー上に存在する環境でリソース ガバナーを使用すると、指定された制限に基づいてこれらのワークロードを区別し、要求された共有リソースを割り当てることができます。 それらのリソースは CPU、物理 I/O、およびメモリです。

リソース ガバナーを使用すると、次のことが可能です。

• 複数のクライアント ワークロードを提供する SQL Server の 1 つのインスタンスで、マルチテナント機能とリソースの分離を提供します。 つまり、サーバー上の使用可能なリソースをワークロード間で分散し、ワークロードがリソースの確保を求めて競合したときに発生する可能性のある問題を最小限に抑えることができます。

• 複数のワークロードが存在するマルチユーザー環境で、予測可能なパフォーマンスを実現し、ワークロード テナントの SLA をサポートします。

• I/O サブシステムを飽和させ、他のワークロードに悪影響を与える可能性のある DBCC CHECKDB などの操作に対して、ランナウェイ クエリの分離と制限または I/O リソースの調整を行います。

• リソース使用のチャージバックに対して詳細なリソースの追跡を追加し、サーバー リソースの消費者に予測可能な請求情報を提供します。

リソース ガバナーの制約

このリリースのリソース ガバナーには次の制約があります。

• リソース管理は、SQL Server データベース エンジンに限定されます。 リソース ガバナーは、Analysis Services、統合サービス、Reporting Services には使用できません。

• SQL Server のインスタンス間のワークロードの監視機能、または管理機能はありません。

• リソース ガバナーで OLTP ワークロードを管理することは可能ですが、このような種類のクエリは通常短時間で、CPU 上の滞留期間が短いために帯域幅制御を適用できない場合があります。 この結果、CPU 使用率として返される統計が偏る可能性があります。

• 物理 I/O を制御する機能は、ユーザー操作のみに適用され、システム タスクには適用されません。 システム タスクには、トランザクション ログへの書き込み操作およびレイジー ライターの I/O 操作が含まれます。 ほとんどの書き込み操作は通常システム タスクによって実行されるため、Resource Governor は主にユーザーの読み取り操作に適用されます。

• 内部リソース プールで I/O のしきい値を設定することはできません。

リソースの概念

次に示す 3 つの概念は、リソース ガバナーを理解し、使用するための基本となります。

• リソース プール。 リソース プールは、サーバーの物理リソースを表します。 プールは、SQL Server インスタンス内部の仮想 SQL Server インスタンスと考えることができます。 SQL Server をインストールすると、2 つのリソース プール (内部と既定) が作成されます。 リソース ガバナーでは、ユーザー定義のリソース プールもサポートされます。 詳細については、「 リソース ガバナー リソース プール」を参照してください。

• ワークロード グループ。 ワークロード グループは、分類基準が類似しているセッション要求のコンテナーとして機能します。 ワークロードは、セッションの全体的な監視を可能にし、セッションのポリシーを定義します。 各ワークロード グループはリソース プールに存在します。 SQL Server をインストールすると、2 つのワークロード グループ (内部と既定) が作成され、対応するリソース プールにマップされます。 リソース ガバナーでは、ユーザー定義のワークロード グループもサポートされます。 詳細については、「 リソース ガバナー ワークロード グループ」を参照してください。

• 分類。 分類プロセスにより、着信セッションがセッションの特性に基づいてワークロード グループに割り当てられます。 分類ロジックは、分類子関数と呼ばれるユーザー定義関数を記述することで調整できます。 リソース ガバナーでは、分類規則を実装するための、ユーザー定義の分類関数もサポートされます。 詳細については、「 リソース ガバナーの分類子関数」を参照してください。

リソース ガバナーのコンテキストでは、上記の概念をコンポーネントとして扱うことができます。 次の図は、これらのコンポーネントと、データベース エンジン環境でのその相互関係を示しています。 処理の観点から見たフローを簡単に示すと次のようになります。

• セッション (セッション 1/ n) に着信接続が存在します。

• セッションが分類されます (分類)。

• セッション ワークロードがワークロード グループ (グループ 4 など) にルーティングされます。

• ワークロード グループは、自身が関連付けられているリソース プール (プール 2 など) を使用します。

• リソース プールは、アプリケーション (アプリケーション 3 など) に必要なリソースの提供と制限を行います。

リソース ガバナーのタスク

参照

データベース エンジンのインスタンス (SQL Server)