この記事は、Huawei クラウド コミュニティ「[GaussTech Express] きめ細かいリソース管理と制御の技術的解釈」、著者: GaussDB データベースから共有されたものです。
背景
データベース クラスター内のリソース制御とリソース分離は、企業顧客の長年の要求でした。エンタープライズレベルの分散データベースとして、Huawei Cloud GaussDB は、大規模データベースクラスターに対する企業の管理ニーズを満たすことに尽力してきました。
データベースが管理できるリソースには、コンピューティング リソースとストレージ リソースが含まれます。コンピューティング リソースには、CPU、メモリ、IO、ネットワークが含まれます。ストレージ リソースには、データ ストレージ スペース、ログ ストレージ スペース、および一時ファイルが含まれます。
ユーザーの観点から見ると、リソースの管理と制御は、リソースの使用に関するしきい値や優先度の制限を設定することでサービス レベル アグリーメントへのコミットメントを保証すると同時に、異なるユーザー間のリソースの分離を実現し、複数のテナント間でデータベース リソースを共有するという目的も達成します。
システムの観点から見ると、リソースの監視および制御方法を導入すると、制御可能な条件下でリソースを合理的に利用するという目的を達成し、リソースの枯渇を回避し、システムの応答停止やクラッシュを防ぐことができます。ジョブの優先順位により、ジョブのスムーズな操作が保証され、リソースの使用量が多すぎる場合にジョブが他のジョブに影響を与えるのを防ぎ、リソースが豊富な場合にリソースの使用率を最大化できます。さらに、外部の期待にも応え、システム リソースを最大限に活用することもできます。ジョブを制御することで、ジョブの安定性を確保し、ジョブ実行中の制御不能な動作を回避できます。
上記の目標を解決するために、Huawei Cloud GaussDB データベースは、データベースクラスター内のリソースのきめ細かな管理と制御のためのソリューション、つまりきめの細かいリソース管理と制御を提供します。このソリューションは、さまざまな制御粒度 (ユーザー レベル、セッション レベル、ステートメント レベルなど) およびさまざまな制御次元 (CPU、メモリ、IO) で、対応する管理および制御機能を提供します。ユーザーは、自身のビジネス ニーズに応じて適切な制御ディメンションと制御の粒度を採用し、リソース制御とリソース分離の目標を達成し、さまざまなシナリオでのリソース制御のニーズを満たすことができます。
テクノロジーアーキテクチャ
まず、きめ細かいリソース管理と制御の技術的なアーキテクチャと動作原理を見てみましょう。
上の図からわかるように、GaussDB は、CPU、メモリ、および IO の管理および制御ロジックを完成させるためのリソース プール モジュールを提供します。ユーザーはリソース プールを作成し、使用できる CPU、メモリ、および IO シェアを指定し、リソース プールをユーザーにバインドできます。その後、ユーザーが開始したジョブは、データベース カーネルの最適化と解析、実行エンジン、およびストレージ エンジン モジュールの動作中にリアルタイムのリソース管理と制御の対象となり、その CPU、メモリ、および IO が規定の範囲内にあることが保証されます。対応するリソース プールのスコープ。
会社 A が GaussDB インスタンスをデプロイし、OLTP ビジネス、レポート ビジネス、その他の優先度の低いビジネスなどの 3 つの異なるアプリケーションが同時にインスタンスにアクセスすると仮定します。 A 社は、リソースを最大限に活用しながらシステムをスムーズに実行できるように、3 つのビジネスのリソースを合理的に管理および制御したいと考えています。システム管理者は次のコマンドを実行して、3 人のビジネス ユーザーのリソース共有比率を 50:30:10 に設定し、残りの 10% がシステム用に予約されます。
ここでは簡単な使用例のみを示します。各パラメータの具体的な意味については、次の章で詳しく説明します。
リソース プール respool_tp を作成します (control_group="cgroup_tp", max_dynamic_memory="5GB", max_shared_memory="5GB", io_limits=50, io_priority="High"); ロール tp_user リソース プール 'respool_tp' を変更します。 リソース プール respool_report を作成します (control_group="cgroup_report", max_dynamic_memory="3GB", max_shared_memory="3GB", io_limits=30, io_priority="Medium"); ロール report_user リソース プール 'respool_report' を変更します。 リソース プール respool_other を作成します (control_group="cgroup_other", max_dynamic_memory="1GB", max_shared_memory="1GB", io_limits=10, io_priority="Low"); ロール other_user リソース プール 'respool_other' を変更します。
上記の操作後、OLTP 業務、レポート業務、およびその他の優先度の低い業務が tp_user、report_user、other_user を使用して GaussDB に接続し、ジョブを実行すると、これら 3 つの業務は、対応するリソース プール respool_tp、respool_report、respool_other によって制御されます。 resource 競合が発生した場合、3 つのビジネスがそれぞれ GaussDB クラスターのリソースの 50%、30%、10% を使用できることが保証されます。
主要な機能
全体的なアーキテクチャと、きめ細かいリソース管理と制御の使用法を理解した後、その主要な機能と、これらの機能が顧客にどのようなビジネス価値をもたらすかを見てみましょう。
CPU制御
GaussDB の CPU 管理と制御は、ユーザー リソースの管理と制御のためのリソース プールの粒度に基づいており、各リソース プールはコントロール グループにバインドされており、CPU の管理と制御はコントロール グループ (コントロール グループ、CGroup) を通じて実装されます。 CGroup は、プロセス グループによって使用される物理リソース (CPU、メモリ、IO など) を制限、記録、分離するために Linux カーネルによって提供されるメカニズムです。
さまざまな次元でのデータベース システム、ユーザー、ジョブの分離と構成可能性を考慮して、GaussDB はコントロール グループの階層特性を使用して、データベース シナリオ (下図を参照) に準拠するモデルを構築します。これは、データベースの主要な特性を満たすものです。顧客 SLA をサポートし、階層的な分離と制御の 3 つの側面をサポートします。つまり、データベース プログラムと非データベース プログラム間の分離、データベース常駐バックアップ スレッドと実行ジョブ スレッド間の分離、および複数のデータベース ユーザー間の分離です。
GaussDB コントロール グループは、CPU の割合とコア数の上限を設定できます。ルート ノードは、GaussDB プロセスで使用できる CPU シェアを制御します。バックエンド コントロール グループは、データベース常駐の CPU シェアを制御します。バックグラウンド スレッド (Vacuum、DefaultBackend)。クラス コントロール グループは、ユーザーのジョブ スレッドの CPU シェア (UserClass1、UserClass2、...UserClassN) の制御を担当します。ワークロード コントロール グループ (TopWD、RemainWD...) も作成できます。クラス制御グループ内で、よりきめ細かい制御を行うことができます。
上記の例の続きとして、GaussDB が提供する CGroup ツールを使用して、A 社の OLTP ビジネス、レポーティング ビジネス、およびその他の優先度の低いビジネス用のコントロール グループを、CPU 割り当て率 50%、30%、10% で作成します。
gs_cgroup -c -S cgroup_tp -s 50; gs_cgroup -c -S cgroup_report -s 30; gs_cgroup -c -S cgroup_other -s 10;
上記のコマンドを実行すると、3 つのコントロール グループが正常に作成されたことになり、リソース プールを作成するときにコントロール グループの名前を指定できるようになります。リソース プールにバインドされたユーザーによって開始されたジョブは、制御グループの対応する CPU シェアによって制御されます。
CGroup で CPU を制御する場合は、次の 2 つの問題に注意する必要があります。
まず、スレッドの CPU を CGroup によって制御する必要がある場合、CGroup のシステム API を実行して、対応する CGroup をスレッドにバインドする必要がありますが、これは時間のかかる操作です。
次に、CGroup の CPU 制御効果は、スレッド数が CPU に比例する場合に最適になります。
こうした問題を踏まえ、GaussDB では、各リソース プールがスレッド グループに対応し、スレッド グループ内のスレッドがリソース プールに対応する CGroup にバインドされるという概念を提案しました。同時に、GaussDB は、対応する CGroup の CPU シェアと一致するように、各スレッド グループのスレッド数を調整します。詳細については、以下の図を参照してください。
ユーザーが開始した各ジョブは、対応するスレッド グループ内のスレッドに分散されて実行されます。スレッドは対応する Cgroup ノードにバインドされているため、オペレーティング システムはスレッド スケジューリング中に CPU 管理と制御を完了します。
GaussDB は 2 層のユーザー メカニズムを提供します。クラス コントロール グループにバインドされたリソース プールはグループ リソース プールと呼ばれ、対応するユーザーはワークロード コントロール グループにバインドされたリソース プールと呼ばれます。対応するユーザーはビジネス ユーザーです。通常、グループ ユーザーは 1 つの部門に対応しますが、ビジネス ユーザーはその部門のさまざまなビジネスに対応します。ビジネス リソース プール内の各リソース ディメンションのリソース シェアが、それが属するグループのリソース プールのシェアを超え、それによって 2 レベルのリソース管理と制御の目標が達成されますか。
CPU 制御には、単一セッションの CPU が対応するリソース プールの CPU 制限を超えないように制限する session_respool という名前の GUC も提供されます。
メモリ管理
GaussDB は、動的メモリと共有キャッシュの管理と制御を提供します。リソース プールを作成するときに、max_dynamic_memory と max_shared_memory を指定して、それぞれ動的メモリと共有キャッシュのしきい値設定を完了できます。
動的メモリ管理は、元のメモリ リソース割り当てメカニズムを変更せず、過剰に割り当てられたメモリを考慮してメモリを割り当てる前に論理的な判断層を追加し、そのアカウンティング値が許容メモリの上限に達しているかどうかをチェックするだけです。コントロール。動的メモリが上限を超えると、ジョブはメモリの適用に失敗します。ジョブが終了すると、他のジョブが正常に実行できるように、ジョブによって要求されたメモリが解放されます。同様に、ジョブが使用する共有キャッシュがリソースプールの上限を超えた場合、再度共有キャッシュを申請する場合は、既に占有しているBufferPoolなどの共有キャッシュを解放する必要があります。ジョブがページに適用されると、すでに占有されていたページは削除され、削除後の残りのページは引き続き使用できます。
ユーザー単位の詳細なメモリ制御に加えて、GaussDB には、セッション レベルおよびステートメント レベルの動的メモリ制御を完了するための 2 つの GUC パラメータ session_max_dynamic_memory と query_max_mem も用意されており、セッションまたはステートメントによって使用される動的メモリが GUC しきい値に達すると、ジョブが実行されます。メモリの適用に失敗します。
IO制御
GaussDB のディスク読み取りおよび書き込み IO はすべてバックグラウンド スレッドによって完了します。このスレッドはページの所有者を区別することができず、時系列にディスクに書き込むだけであり、ユーザーごとに異なる IO 使用を制御することはできません。これに基づいて、IO 管理および制御機能は、論理 IO 統計を使用して、ユーザーまたはセッションの読み取りおよび書き込み IO を制御および制限することを考慮します。行ストレージ テーブルの場合、論理 IO カウントが追加されます。 6000 ごと (io_control_unit を渡すことができます) GUC (GUC によって変更) は 1 つの IO としてカウントされます。 1 秒間に生成された読み取りおよび書き込み IO リクエストの数がリソース プールによって設定されたしきい値を超えると、その IO リクエストは待機状態に追加されます。これらの IO リクエストはバックグラウンド スレッドのキューに応答し、バックグラウンド スレッドは待機キューに応答します。これらの IO リクエストは監視され、待機時間が条件を満たすと、これらの IO リクエストは待機キューから呼び出されます。
GaussDB は、IO リソースの管理と制御の 2 つのモードをサポートしています。オンライン数値モードは、IO 時間をトリガーするための固定値を設定することで IO リソースを制御します。優先モードは、現在のディスク使用率が長期間にわたって 95% を超えると、すべてのジョブが停止されることを意味します。オンライン値モードに到達すると、ユーザーはこのモードを通じて IO を制御し、最初に IO をトリガーしたジョブの優先度比率を制御できます。優先度には、高、中、低の 3 つのレベルがあります。
上記の例の続きとして、A 社の OLTP ビジネス、レポート ビジネス、およびその他の優先度の低いビジネス用のリソース プールを作成し、IO の重みをそれぞれ高、中、低に設定します。その後、OLTP ビジネスは、バッファプールへのデータの読み取りまたは書き込みに IO リクエストの 50% を使用でき、少数の IO リクエストは待機キューに入り、待機することができます。レポート ビジネスは、IO リクエストの 20% を読み取りに使用できます。他の優先度の低いビジネスは、バッファプールへのデータの読み取りまたは書き込みに IO リクエストの 10% を使用でき、さらに多くの IO リクエストが待機キューに入ります。 wait; バックグラウンド監視スレッドは定期的に IO 待機キューを走査し、バッファプールからのデータの読み取りまたは書き込みに必要な待機時間を満たす IO リクエストをウェイクアップします。
GaussDB は、ユーザー詳細な IO 制御のサポートに加えて、指定されたセッションで許可されるジョブの IO 制御を完了するためのセッション レベルの GUC パラメーター io_limits および io_priority の設定もサポートします。
接続数と同時実行管理
GaussDB では、リソース プールを作成するときに、max_connections と max_concurrency を指定して、それぞれ接続数と同時実行数の設定を行うことができます。前の例では、A 社の 3 つのビジネスがプールによって接続数と同時実行数の管理と制御が完了します。
リソース プール respool_tp を変更します (max_connections=-1, max_concurrency = -1); リソース プール respool_report を変更します (max_connections=200, max_concurrency = 100); リソース プール respool_other を (max_connections=100, max_concurrency = 50) で変更します。
上記の SQL が正常に実行されると、リアルタイムで有効になります。 A 社の OLTP ビジネスの接続数と同時実行数は、クラスターにリソースがある限り制限されず、レポート ビジネスの最大接続数は 200 であり、他の優先度の低いビジネスの最大接続数は制限されません。これら 2 つのビジネスの場合、確立された接続の数がこの値を超えると、GaussDB カーネルが自動的にインターセプトし、現在の接続数が不十分でリンクが失敗したことをレポート ビジネスの最大同時実行数は 100 であると報告します。 、他の優先度の低いビジネスの最大同時実行数は 50 です。これら 2 つのビジネスで同時に開始されたジョブの数がこの値を超えると、超過したジョブは GaussDB をウェイクアップしません。既存のジョブが完了するまでジョブの実行を続けます。
ストレージスペースの管理と制御
記憶域スペースの管理と制御は、単一ユーザーによる記憶域スペースの過度の使用によってデータベース ビジネス全体がブロックされるのを防ぐために、さまざまなユーザーが使用できるスペース クォータを制限するために使用されます。 GaussDB は、ユーザーの作成時にストレージ領域のサイズを指定することで、ストレージ リソースを管理および制御します。
ストレージスペースリソースは、永続テーブルスペース (Perm Space)、一時テーブルスペース (Temp Space)、およびオペレータボトムディスクスペース (Spill Space) の 3 つのタイプに分類されます。
次の SQL を使用して、前の例の A 社の 3 つの事業に対応するユーザーのディスク領域の管理と制御を完了できます。
alter user tp_user PERM SPACE '200G' TEMP SPACE '20G' SPILL SPACE '20G'; alter user report_user PERM SPACE '100G' TEMP SPACE '10G' SPILL SPACE '10G'; ユーザー other_user を変更します PERM SPACE '100G' TEMP SPACE '10G' SPILL SPACE '10G';
ストレージスペース管理は、グループユーザーおよびビジネスユーザーのストレージスペース管理をサポートします。ビジネスユーザーに対応するグループユーザーにスペース制限がある場合、ビジネスユーザーのスペースもユーザーグループのスペース制限によって制限されます。ストレージスペースのサイズを指定した後、DN 上のユーザーによるすべての書き込み操作によってユーザーの使用スペースが増加し、削除操作によってユーザーの使用スペースが減少します。CN は定期的に DN から合計使用スペースを取得し、合計使用スペースを計算します。最大値を超えると、書き込みジョブはキャンセルされ（挿入/テーブルの作成/コピー）、後続の書き込みジョブはエラーを報告して終了します。
機能のデモンストレーション
機能のデモ CPU はビジネスに最も大きな影響を与えるため、ここでは簡単に CPU 制御の効果を全員にデモします。
2 つのリソース プールを作成し、それぞれ CPU の 20% と 60% を設定し、リソース プールにバインドされた 2 人のユーザーを使用してビジネスの実行を開始します。実際の CPU 使用率を観察します。
1. コントロール グループを作成します。
gs_cgroup -c -S クラス 1 -s 20; gs_cgroup -c -S クラス 2 -s 60;
2. リソース プールを作成します。
リソースプールの作成 xuuer_pool with(control_group = "class1"); リソースプールの作成 xyuser1_pool with(control_group = "class2");
3. ユーザーバインドされたリソースプールを作成します。
ロール user1 リソース プール 'xuuer_pool' を作成します。 ロール user2 リソース プール 'xyuser1_pool' を作成します。
4. Top を通じてシステムの CPU ステータスを監視し、gs_wlm_respool_cpu_info 関数を使用して各リソース プールのリアルタイムの CPU ステータスを監視するきめ細かいリソース管理と制御を提供します。
上の図に示すように、初期システム CPU がアイドル状態であることがわかり、リソース プールの CPU 監視ビューにも CPU 使用率が 0 であることが示されています。 user1 がサービスの実行を開始します。リソース プールの CPU 監視ビューをクエリすると、システム CPU が CPU の 80% を使用できることがわかります。この時点で、user2 も業務を開始します。観察すると、システム CPU がビジー状態になっていることがわかります。リソース プールの CPU リソース監視のシステム機能を問い合わせると、user1 の CPU 使用率が減少し始め、user2 の CPU 使用率が増加し始めていることがわかります。 。
2 人のユーザーの CPU 使用率を整理し、以下に示すような曲線グラフを描きます。user1 と user2 の CPU 使用率は、最終的には 20% と 60% と一致する 3:1 の状態になることがわかります。リソース プールの % 比率に対応する CGroup 制御グループの設定により、CPU 制御の効果が得られます。
要約する
詳細なリソース管理および制御機能は現在、集中化および分散化をサポートしています。分散コンピューティング リソースの管理と制御とは、各ノードが自身のノードのリソースを独立して制御する一方、ストレージ リソースの管理と制御はクラスターの次元から全体として管理されることを意味します。
きめ細かいリソース管理と制御は、マルチテナント リソース分離の基礎として機能し、リソースの正確な分割と制御を可能にし、高負荷シナリオでのリソース不足によって引き起こされるクラスターの使用不能の問題を解決します。この機能は、データ分離は重要ではないが、さまざまなビジネスでリソース分離が必要なシナリオに適しています。顧客がリソース分離とデータ分離の両方の要件を持っている場合は、後で説明するマルチテナント データベース機能に注目してください。
クリックしてフォローし、できるだけ早くHuawei Cloudの新しいテクノロジーについて学びましょう~
高校生が成人式として独自のオープンソースプログラミング言語を作成―ネットユーザーの鋭いコメント： アップル、M4チップ RustDeskをリリース 不正行為横行で国内サービス停止 雲峰氏がアリババを辞任。将来的には、Windows プラットフォームの タオバオ (taabao.com) で独立したゲームを制作する予定です。Web バージョンの最適化作業を再開し、 プログラマの目的地、 Visual Studio Code 1.89 が最も一般的に使用される Java LTS バージョンである Java 17 をリリースします。Windows 10 には、市場シェアは70%、Windows 11は減少し続けるOpen Source Daily | GoogleはオープンソースのRabbit R1を支持、Microsoftの不安と野心;
{{名前}}
{{名前}}