GaussDB(DWS) 사용자 모니터링의 원리와 적용에 대해 자세히 설명

개요: 이 기사는 사용자 모니터링의 원칙과 적용에 중점을 둘 것입니다.

이 기사는 Huawei 클라우드 커뮤니티 " GaussDB(DWS) 모니터링 도구 가이드(2) 사용자 수준 모니터링 ", 저자: Little black claw behind the scenes에서 공유됩니다.

머리말

리소스 모니터링은 전체 운영 및 유지 보수, 심지어 전체 제품 수명 주기의 중요한 부분입니다.결함은 사전에 적시에 감지되고 이후에 자세한 데이터를 제공하여 문제를 추적하고 찾습니다. GaussDB(DWS)의 전체 리소스 모니터링 시스템은 작업 수준 모니터링, 사용자 모니터링 및 리소스 풀 모니터링으로 구분됩니다. 이 기사는 사용자 모니터링의 원칙과 적용에 중점을 둘 것입니다.

1. GuassDB(DWS) 사용자 시스템

제품의 경우 가장 간단한 사용자 분류는 일반 사용자, 시스템 관리자 및 최고 관리자의 3계층 시스템입니다. 최고 관리자는 최고 수준의 권한을 가지며 일반 사용자는 가장 기본적인 사용자이며 시스템 관리자는 사용자 운영 체제의 일부 권한도 가지고 있으며 일반 사용자의 권한도 변경할 수 있습니다. 최고 관리자는 모든 권한을 가지고 있지만 사용하기 쉽지 않습니다.

1.1 2계층 사용자 메커니즘 소개

기업의 경우 데이터베이스의 운영도 부서로 나뉘는데 각 부서마다 별도의 테이블이 있고 각 부서 역시 별도의 우선순위를 가집니다. 레이어. :

첫 번째 계층은 그룹 사용자입니다. 이 계층의 사용자는 그룹 리소스 풀과 연결되며 작업을 실행하는 사용자로 사용되지 않습니다.

두 번째 계층은 비즈니스 사용자로, 이 계층의 사용자는 비즈니스 리소스 풀과 연결되어 작업을 수행하는 사용자로 사용될 수 있습니다.

그룹 사용자 간에 사용할 수 있는 리소스도 개별적으로 설정할 수 있습니다. 각 비즈니스 사용자 간에 별도의 리소스를 설정할 수도 있습니다. 이전의 단일 계층 사용자 메커니즘과 비교하여 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 권한 부여

일반 사용자가 특정 테이블에 액세스해야 하는 경우 권한 부여 구문을 사용하여 사용자에게 권한을 부여하거나 권한을 철회할 수 있습니다. 이 작업은 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을 실행하면 클러스터의 전반적인 성능이 저하됩니다. 이 시점에서 우리는 어떤 사용자가 Job을 발행했는지 파악한 후 그에 해당하는 Slow 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의 새로운 기술에 대해 알아보고 팔로우하려면 클릭하세요~