Skip to content

11.(Old) ResourceGroup.md

Latest commit

 

History

History
217 lines (174 loc) · 7.25 KB

11.(Old) ResourceGroup.md

File metadata and controls

217 lines (174 loc) · 7.25 KB
https://warehouse-pg.io/docs/7x/admin_guide/workload_mgmt_resgroups.html#using-resource-groups

리소스 그룹은 **워크로드 관리(Workload Management)**를 위한 Greenplum의 핵심 기능입니다. 특정 사용자 그룹(Role)이 사용할 수 있는 CPU, 메모리, 동시성(동시 실행 쿼리 수)을 제한하여, 중요한 작업이 리소스를 안정적으로 확보하고 시스템 전체의 과부하를 방지하는 역할을 합니다.

1.Redhat(Rocky) OS 사전 구성.

Cgroup Ver 2. 설정.

모든 노드에서 root 계정으로 작업.

sudo -iu root

whpg cgroup 서비스 등록(Version 2)

## root 계정
sudo tee -a /etc/systemd/system/gpdb.service << EOF 
[Unit]
Description=Greenplum Cgroup v2 Configuration Service
 
[Service]
# Use simple type with sleep infinity to prevent Systemd from garbage collecting the cgroup
Type=simple
Delegate=yes
Slice=-.slice
 
ExecCondition=bash -c '[ xcgroup2fs = x$$(stat -fc "%%T" /sys/fs/cgroup) ] || exit 1'
 
# 1. Prepare base paths and root delegation ONLY
ExecStartPre=bash -ec '\
echo "+cpuset +io +cpu +memory" > /sys/fs/cgroup/cgroup.subtree_control || true; \
mkdir -p /sys/fs/cgroup/gpdb; \
chown -R gpadmin:gpadmin /sys/fs/cgroup/gpdb; \
chmod a+w /sys/fs/cgroup/cgroup.procs;'
 
# 2. Main process to keep the cgroup alive (Anchor)
ExecStart=/usr/bin/sleep infinity
 
# 3. Post-start: Migrate the anchor process to a leaf node FIRST, THEN delegate controllers
# This solves the 219/CGROUP error and satisfies the No Internal Processes rule
ExecStartPost=bash -ec '\
mkdir -p /sys/fs/cgroup/gpdb.service/helper.scope; \
echo $MAINPID > /sys/fs/cgroup/gpdb.service/helper.scope/cgroup.procs; \
\
echo "+cpuset +io +cpu +memory" > /sys/fs/cgroup/gpdb.service/cgroup.subtree_control || true; \
echo "+cpuset +io +cpu +memory" > /sys/fs/cgroup/gpdb/cgroup.subtree_control || true; \
\
chown -R gpadmin:gpadmin /sys/fs/cgroup/gpdb.service;'
 
[Install]
WantedBy=basic.target
EOF

whpg cgroup 서비스 시작/확인.

sudo systemctl daemon-reload
sudo systemctl enable gpdb.service
sudo systemctl start gpdb.service
sudo systemctl status gpdb.service

OS에서 cgroup v1 설정 ( 권장 안함 )

mkdir -p /sys/fs/cgroup/gpdb
chown -R gpadmin:gpadmin /sys/fs/cgroup/gpdb
chown -R gpadmin:gpadmin /sys/fs/cgroup/gpdb.service
chmod a+w /sys/fs/cgroup/cgroup.procs 
echo "+cpuset +io +cpu +memory" | tee -a /sys/fs/cgroup/gpdb.service/cgroup.subtree_control
echo "+cpuset +io +cpu +memory" | tee -a /sys/fs/cgroup/gpdb/cgroup.subtree_control

OS에서 cgroup v2 설정

grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="systemd.unified_cgroup_hierarchy=1"
grubby --update-kernel=/boot/vmlinuz-$(uname -r) --remove-args="systemd.legacy_systemd_cgroup_controller"
grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="psi=1" 
#(옵션) reboot

# cgroup v2 활성화 확인: 재부팅 후 아래 명령어로 cgroup2fs가 출력되는지 확인합니다
stat -fc %T /sys/fs/cgroup/
or
mount | grep cgroup2

whpg cgroup 서비스 확인.

sudo systemctl status gpdb.service

2. 테스트 시나리오

대시보드 조회를 위한 사용자 그룹(dashboard_users)과 데이터 로딩을 위한 ETL 그룹(etl_users)을 나누어 리소스를 할당하는 예시입니다.

0단계: postgresql.conf 설정.

마스트 노드에서 gpadmin 계정으로 작업.

gpconfig -c gp_resource_manager -v "group-v2"
gpstop -r
gpconfig -s gp_resource_manager

1단계: 리소스 그룹 생성 (CREATE RESOURCE GROUP) 먼저, 각 그룹의 리소스 제한을 정의하여 생성합니다.

dashboard_users_rg: 대시보드 사용자를 위한 그룹. 쿼리 5개가 동시에 실행될 수 있으며, 전체 CPU의 30%, 메모리의 20%를 사용하도록 제한합니다.

etl_users_rg: ETL 작업을 위한 그룹. 동시 실행은 2개로 제한하지만, 더 많은 CPU와 메모리(각각 50%)를 할당합니다.

-- 대시보드 사용자용 리소스 그룹 생성

CREATE RESOURCE GROUP dashboard_users_rg WITH (
    CPU_MAX_PERCENT=20,       -- CPU 사용률 30% 제한
    MEMORY_QUOTA=250,     -- 메모리 사용률 20% 제한
    CONCURRENCY=5           -- 동시 실행 쿼리 수 5개 제한
);

-- ETL 사용자용 리소스 그룹 생성

CREATE RESOURCE GROUP etl_users_rg WITH (
    CPU_MAX_PERCENT=20, 
    MEMORY_QUOTA=250, 
    CONCURRENCY=2
);

참고: MEMORY_SHARED_QUOTA 옵션을 사용하여 그룹 내 쿼리들이 공유할 메모리 비율을 정할 수도 있습니다.

-- 설정 확인.

SELECT * FROM gp_toolkit.gp_resgroup_config;

2단계: 역할(Role) 생성 및 리소스 그룹 할당 이제 이 리소스 그룹에 속할 사용자(Role)를 만들고, 해당 리소스 그룹을 할당합니다.

새로운 역할(사용자) 생성

SQL

CREATE ROLE dashboard_user WITH LOGIN PASSWORD 'your_password';
CREATE ROLE etl_user WITH LOGIN PASSWORD 'your_password';

역할에 리소스 그룹 할당 (ALTER ROLE) ALTER ROLE 명령어를 사용하여 각 역할을 해당 리소스 그룹에 배정합니다.

SQL

ALTER ROLE dashboard_user RESOURCE GROUP dashboard_users_rg;
ALTER ROLE etl_user RESOURCE GROUP etl_users_rg;

이제 dashboard_user로 접속하여 실행하는 모든 쿼리는 dashboard_users_rg에 설정된 리소스 제한(CPU 30%, 메모리 20%, 동시성 5)을 따르게 됩니다.

3단계: 설정 확인 ✅ 생성된 리소스 그룹과 역할 할당 상태를 아래 뷰(view)를 통해 확인할 수 있습니다.

리소스 그룹 설정 확인

SQL

SELECT * FROM gp_toolkit.gp_resgroup_config;

역할에 할당된 리소스 그룹 확인

SQL

SELECT rolname, rsgname
FROM pg_roles, gp_toolkit.gp_resgroup_config
WHERE pg_roles.rolresgroup = gp_toolkit.gp_resgroup_config.groupid
  AND rolname IN ('dashboard_user', 'etl_user');

이처럼 리소스 그룹을 사용하면, 다양한 워크로드가 서로 영향을 주지 않고 안정적으로 실행되도록 시스템 리소스를 효과적으로 통제하고 관리할 수 있습니다.

대시보드 사용자용 리소스 그룹 생성 예시.

CREATE RESOURCE GROUP rgroup1 WITH (
    CONCURRENCY=20, 
    CPU_MAX_PERCENT=20, 
    MEMORY_QUOTA=250, 
    CPU_WEIGHT=500, 
    MIN_COST=50, 
    IO_LIMIT='pg_default: wbps=1000, rbps=1000, wiops=100, riops=100'
);

ALTER RESOURCE GROUP rg_role_light SET CONCURRENCY 7;
ALTER RESOURCE GROUP exec SET MEMORY_QUOTA 30;
ALTER RESOURCE GROUP rgroup1 SET CPUSET '1;2,4';
ALTER RESOURCE GROUP sales SET IO_LIMIT 'tablespace1:wbps=2000,wiops=2000;tablespace2:rbps=2024,riops=2024';

DROP RESOURCE GROUP olap_rg; 

ALTER ROLE bill RESOURCE GROUP olap_rg;
CREATE ROLE mary RESOURCE GROUP etl_rt;

ALTER ROLE mary RESOURCE GROUP NONE;

SELECT * FROM gp_toolkit.gp_resgroup_config;
SELECT * FROM gp_toolkit.gp_resgroup_status;
SELECT * FROM gp_toolkit.gp_resgroup_status_per_host;

SELECT rolname, rsgname FROM pg_roles, pg_resgroup
WHERE pg_roles.rolresgroup=pg_resgroup.oid;

SELECT * FROM gp_toolkit.gp_resgroup_iostats_per_host;
SELECT query, rsgname,wait_event_type, wait_event FROM pg_stat_activity;

SELECT rolname, g.rsgname, pid, waiting, state, query, datname 
FROM pg_roles, gp_toolkit.gp_resgroup_status g, pg_stat_activity 
WHERE pg_roles.rolresgroup=g.groupid
AND pg_stat_activity.usename=pg_roles.rolname;

SELECT pg_cancel_backend(31905);