GaussDB（DWS）ユーザー監視の原理と応用を詳しく解説

要約: この記事では、ユーザー監視の原理と応用に焦点を当てます。

この記事は、Huawei Cloud Community「GaussDB (DWS) Monitoring Tool Guide (2) User-level Monitoring」、著者: 舞台裏の小さな黒い爪から共有されたものです。

序文

リソースの監視は、運用とメンテナンス全体、さらには製品ライフサイクル全体においても重要な部分であり、障害は事前にタイムリーに検出され、その後、問題を追跡して特定するために詳細なデータが提供されます。GaussDB (DWS) のリソース監視システム全体は、ジョブレベルの監視、ユーザーの監視、およびリソースプールの監視に分かれています。この記事では、ユーザー監視の原理と応用に焦点を当てます。

1.GuassDB (DWS) ユーザーシステム

製品の場合、最も単純なユーザー分類は、一般ユーザー、システム管理者、およびスーパー管理者の 3 層システムです。スーパー管理者が最上位の権限を持ち、一般ユーザーが最も基本的なユーザーであり、システム管理者はユーザーのOSの権限の一部も持ち、一般ユーザーの権限を変更することもできます。スーパー管理者はすべての権限を持っていますが、使い方は簡単ではありません。

1.1 2 層ユーザーメカニズムの概要

企業の場合、データベースの運用も部門に分かれており、部門ごとにテーブルがあり、優先順位も部門ごとに異なるため、GaussDB (DWS) が設計するユーザーシステムも 2 つに分かれています。レイヤー。:

第 1 層はグループユーザーであり、この層のユーザーはグループリソースプールに関連付けられており、ジョブの実行ユーザーとしては使用されません。

2層目はビジネスユーザーであり、ビジネスリソースプールに関連付けられ、ジョブを実行するユーザーとして利用できます。

グループユーザー間で利用できるリソースを個別に設定することもできます。ビジネスユーザーごとに個別のリソースを設定することもできます。従来の単層ユーザー機構と比較して、二層ユーザー機構では、よりきめ細かいユーザーリソースの制御を実現できます。

例：

# 创建cgroup控制组
gs_ssh -c "gs_cgroup -c -S ClassG1 -G wn1"
# 创建组资源池resource_pool_a绑定ClassG1控制组。
CREATE RESOURCE POOL resource_pool_a WITH (control_group = 'ClassG1');
# 创建业务资源池resource_pool_a1绑定wn1控制组。
CREATE RESOURCE POOL resource_pool_a1 WITH (control_group = 'ClassG1:wn1');
# 创建组用户关联到组资源池。例如，名称为“tenant_a”的组用户关联到“resource_pool_a”组资源池
CREATE USER tenant_a RESOURCE POOL 'resource_pool_a' PASSWORD '********';
# 创建业务用户关联到业务资源池和组用户。例如，名称为“tenant_a1”的业务用户关联到“resource_pool_a1”组资源池和“tenant_a”组用户。
CREATE USER tenant_a1 RESOURCE POOL 'resource_pool_a1' USER GROUP 'tenant_a' PASSWORD '********';

1.2 権限付与

一般ユーザーが特定のテーブルにアクセスする必要がある場合、grant 構文を使用してユーザーにアクセス許可を付与したり、アクセス許可を取り消したりすることができます。この操作は、sysadmin アクセス許可を持つユーザーが実行する必要があります。たとえば、

# 将public表空间下的lineitem表的查询权限赋给user_1：
grant select on public.lineitem to user_1;
# 回收user_1的public表空间下的lineitem表的查询权限：
Revoke select on public.lineitem from user_1;

2. ユーザーリソースの監視

2.1 目標

一般に、データウェアハウス製品では複数のユーザーが同時にデータベースを操作するため、各ユーザーが使用するリソースの量は異なります。極端な例を挙げると、ユーザーが遅い SQL を発行すると、クラスター全体のパフォーマンスが低下します。この時点で、どのユーザーがジョブを発行したかを特定し、対応する遅い SQL を見つけて管理する必要があります。

管理者ユーザーの場合、ユーザー監視は、管理者がユーザーの観点からシステムのパフォーマンスステータスを理解し、リソースのボトルネックや障害を適時に発見して解決し、システムの信頼性と安定性を向上させるのに役立ちます。また、クラスター全体で各ユーザーが使用するリソースの量を区別し、標準よりも多くのリソースを使用しているユーザーを特定し、標準を超えるユーザーを制限することもできます。

2.2 監視寸法

ユーザー監視は、CPU、メモリ、ストレージスペース、一時スペース、オペレータストレージスペース、ディスクIO、ネットワークなどの監視をサポートします。これらのリソースを監視することで、管理者はシステム負荷、プロセスの実行ステータス、ディスクスペースの使用状況、ネットワーク帯域幅の使用状況を把握できます。およびその他の情報。この情報は、管理者がシステムの異常を適時に発見し、システムのクラッシュやサービスの中断を回避するために適時に措置を講じるのに役立ちます。

使用例:

postgres=# SELECT * FROM PG_TOTAL_USER_RESOURCE_INFO;
     username     | used_memory | total_memory | used_cpu | total_cpu | used_space | total_space | used_temp_space | total_temp_space | used_spill_space | total_spill_space | read_kbytes | write_kbytes | read_cou
nts | write_counts | read_speed | write_speed | send_speed | recv_speed
------------------+-------------+--------------+----------+-----------+------------+-------------+-----------------+------------------+------------------+-------------------+-------------+--------------+---------
----+--------------+------------+-------------+------------+------------
 user_grp_1       | 0 | 4928 | 0 | 16 | 1573880 |          -1 | 0 |               -1 | 0 |                -1 | 0 | 0 | 
 0 | 0 | 0 | 0 | 0 | 0
 perfadm | 0 | 0 | 0 | 0 | 0 |          -1 | 0 |               -1 | 0 |                -1 | 0 | 0 | 
 0 | 0 | 0 | 0 | 0 | 0
 user_normal | 0 | 24643 | 0 | 16 | 0 |          -1 | 0 |               -1 | 0 |                -1 | 0 | 0 | 
 0 | 0 | 0 | 0 | 0 | 0
 usr1             | 0 | 69763 | 0 | 40 | 0 |          -1 | 0 |               -1 | 0 |                -1 | 0 | 0 | 
 0 | 0 | 0 | 0 | 0 | 0
 logical_cluster1 | 0 | 24643 | 0 | 16 | 1834424 |          -1 | 0 |               -1 | 0 |                -1 | 0 | 0 | 
 0 | 0 | 0 | 0 | 0 | 0
 user_2           | 0 | 985 | 0 | 16 | 0 |          -1 | 0 |               -1 | 0 |                -1 | 0 | 0 | 
 0 | 0 | 0 | 0 | 0 | 0
 user_1           | 0 | 3942 | 0 | 16 | 1573880 |          -1 | 0 |               -1 | 0 |                -1 | 0 | 0 | 
 0 | 0 | 0 | 0 | 0 | 0
 logical_cluster2 | 0 | 45120 | 0 | 24 | 0 |          -1 | 0 |               -1 | 0 |                -1 | 0 | 0 | 
 0 | 0 | 0 | 0 | 0 | 0
 user_default | 0 | 24643 | 0 | 16 | 0 |          -1 | 0 |               -1 | 0 |                -1 | 0 | 0 | 
 0 | 0 | 0 | 0 | 0 | 0
 wjx | 0 | 24643 | 0 | 16 | 0 |          -1 | 0 |               -1 | 0 |                -1 | 0 | 0 | 
 0 | 0 | 0 | 0 | 0 | 0
(10 rows)
postgres=# select * from GS_WLM_USER_RESOURCE_HISTORY;
     username     |           timestamp           | used_memory | total_memory | used_cpu | total_cpu | used_space | total_space | used_temp_space | total_temp_space | used_spill_space | total_spill_space | read_
kbytes | write_kbytes | read_counts | write_counts | read_speed | write_speed | send_speed | recv_speed
------------------+-------------------------------+-------------+--------------+----------+-----------+------------+-------------+-----------------+------------------+------------------+-------------------+------
-------+--------------+-------------+--------------+------------+-------------+------------+------------
 user_grp_1       | 2023-05-22 16:51:03.380482+08 | 0 | 4928 | 0 | 16 | 1573880 |          -1 | 0 |               -1 | 0 |                -1 | 
 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
 wjx | 2023-05-22 16:51:03.380482+08 | 0 | 24643 | 0 | 16 | 0 |          -1 | 0 |               -1 | 0 |                -1 | 
 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
 user_default | 2023-05-22 16:51:03.380482+08 | 0 | 24643 | 0 | 16 | 0 |          -1 | 0 |               -1 | 0 |                -1 | 
 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
 logical_cluster2 | 2023-05-22 16:51:03.380482+08 | 0 | 45120 | 0 | 24 | 0 |          -1 | 0 |               -1 | 0 |                -1 | 
 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
 user_1           | 2023-05-22 16:51:03.380482+08 | 0 | 3942 | 0 | 16 | 1573880 |          -1 | 0 |               -1 | 0 |                -1 | 
 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
 user_2           | 2023-05-22 16:51:03.380482+08 | 0 | 985 | 0 | 16 | 0 |          -1 | 0 |               -1 | 0 |                -1 | 
 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
 logical_cluster1 | 2023-05-22 16:51:03.380482+08 | 0 | 24643 | 0 | 16 | 1834424 |          -1 | 0 |               -1 | 0 |                -1 | 
 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
 usr1             | 2023-05-22 16:51:03.380482+08 | 0 | 69763 | 0 | 40 | 0 |          -1 | 0 |               -1 | 0 |                -1 | 
 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
 user_normal | 2023-05-22 16:51:03.380482+08 | 0 | 24643 | 0 | 16 | 0 |          -1 | 0 |               -1 | 0 |                -1 | 
 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0

2.3 モニタリングの原則

ジョブの実行中、カーネルはジョブによって運ばれるユーザー情報に従って関連するリソースフィールドを蓄積し、その情報を定期的にユーザー監視履歴テーブルに要約します。また、この関数の使用にはいくつかの仕様があります。

2.3.1 関連する GUC パラメータ

Enable_logical_io_statistics : ユーザーリソース監視とリソースプールリソース監視の IO 関連値の切り替えデフォルトは on 有効にすると、ユーザー監視の IO 関連レコード (read_kbytes、write_kbytes、read_counts、write_counts、read_speed、write_speed) がカウントされます。

Enable_user_metric_persistent : ユーザー/リソースプールの履歴リソースの監視およびダンプ機能を有効にするかどうか。有効にすると、監視レコードが履歴テーブルにダンプされます。

user_metric_retention_time:ユーザーの履歴リソース監視データの保存日数を設定します。デフォルトは 7 日です。

2.3.2 関連する指示

現在のユーザー監視では、高速レーンと低速レーンのすべてのジョブの CPU、IO、メモリ使用量を同時に監視できます。

ユーザーが CN に対してクエリを実行すると、すべての DN リソースプールの使用量とリソース制限の累積合計が表示されます。DN がクエリされると、DN 上のリソースプールの使用量とリソース制限情報のみがカウントされます。

DN でのデータ収集期間は 5 秒で、CN は 5 秒ごとに DN から情報を収集します。補助スレッドは、ユーザー監視データを永続化するために 30 秒ごとに永続化操作を自動的に実行します。

初期管理ユーザーはスーパー管理者ユーザーのため、一時的にリソースの監視は行われず、監視する必要がありません。

2.4 ケーススタディ

2.4.1 メモリが使用できない場合、このビューを使用して、どのユーザーがメモリを過剰に使用しているかを確認できます

2.4.2 ネットワークの送受信速度など、ユーザーのネットワーク使用状況を監視できます。

クリックしてフォローして、Huawei Cloudの最新テクノロジーについて初めて学びましょう~