**cgroup(Control Groups)**은 Linux 커널의 기능 중 하나로, 프로세스 그룹별로 시스템 자원을 제한하고, 우선순위를 지정하며, 관리할 수 있게 해줍니다. cgroup은 특히 컨테이너화된 환경(Docker, Kubernetes)이나 리소스 관리가 중요한 환경(Greenplum Database 등)에서 자주 사용됩니다.
cgroup의 주요 기능
- 자원 제한(Resource Limiting)
- 프로세스 그룹이 사용할 수 있는 CPU, 메모리, 블록 I/O, 네트워크 대역폭 등을 제한할 수 있습니다.
- 예를 들어, 특정 프로세스가 사용할 수 있는 최대 메모리 용량을 설정하거나, CPU 사용률을 제한할 수 있습니다.
- 자원 계측(Resource Accounting)
- 프로세스 그룹별로 자원 사용량(CPU 시간, 메모리 사용량 등)을 계측합니다.
- 이를 통해 특정 작업이나 컨테이너의 자원 사용 패턴을 분석할 수 있습니다.
- 프로세스 격리(Task Grouping)
- 프로세스를 그룹으로 묶어, 서로 간섭하지 못하도록 격리합니다.
- 이는 특히 컨테이너 환경에서 중요한 역할을 합니다.
- 자원 우선순위(Resource Prioritization)
- 특정 프로세스 그룹에 더 높은 우선순위를 부여하여, 다른 그룹보다 더 많은 자원을 사용할 수 있도록 설정할 수 있습니다.
cgroup의 구조
cgroup은 계층적 구조를 가집니다. 각 계층에는 하나 이상의 서브시스템(subsystem) 또는 **컨트롤러(controller)**가 연결됩니다.
주요 컨트롤러
- cpu
- CPU 사용량을 제한합니다.
- 예: CPU 시간 비율 설정 (cpu.shares)
- cpuset
- 특정 CPU 및 메모리 노드에 프로세스를 고정할 수 있습니다.
- 예: NUMA 환경에서 특정 프로세스를 특정 CPU에 할당.
- memory
- 메모리 사용량을 제한하고, OOM(Out-Of-Memory) 상황에서 우선순위를 설정합니다.
- 예: 최대 메모리 제한 설정 (memory.limit_in_bytes)
- blkio
- 블록 장치(디스크) I/O 속도를 제한합니다.
- 예: 읽기/쓰기 속도 제한 설정.
- net_cls 및 net_prio
- 네트워크 트래픽 우선순위를 설정하거나, 패킷을 특정 클래스 ID로 태깅합니다.
- devices
- 특정 디바이스에 대한 접근 권한을 제어합니다.
- freezer
- 프로세스를 일시정지하거나 재개할 수 있습니다.
cgroup의 작동 방식
cgroup은 cgroup 계층(hierarchy) 안에서 작동합니다. 각 계층은 파일 시스템처럼 동작하며, 특정 컨트롤러를 기반으로 자원을 관리합니다.
작업 흐름
- cgroup 계층 생성
- mkdir 명령으로 cgroup 디렉토리를 생성합니다.
- 각 디렉토리는 특정 자원 컨트롤러와 연결됩니다.
- 프로세스 추가
- 특정 프로세스를 cgroup에 추가하려면, 해당 프로세스 ID를 cgroup 디렉토리의 tasks 파일에 기록합니다.
- 자원 제한 설정
- cgroup 디렉토리에 있는 컨트롤러별 설정 파일(cpu.shares, memory.limit_in_bytes 등)을 수정하여 자원 제한을 설정합니다.
cgroup 사용 방법
1. cgroup 설치 확인
cgroup은 대부분의 Linux 배포판에 기본적으로 포함되어 있습니다. 하지만 systemd 기반 환경에서는 자동으로 관리됩니다.
cgroup 버전 확인
ls /sys/fs/cgroup
- cgroup2 디렉토리가 보이면 cgroup v2를 사용 중입니다.
2. cgroup v1 사용 예제
cgroup 디렉토리 생성
sudo mkdir /sys/fs/cgroup/cpu/my_cgroup
CPU 제한 설정
- CPU의 할당 비율을 설정:
echo 512 > /sys/fs/cgroup/cpu/my_cgroup/cpu.shares
(512는 기본값 1024의 절반, 즉 50% CPU를 할당)
프로세스 추가
- 특정 프로세스를 cgroup에 추가:
echo <PID> > /sys/fs/cgroup/cpu/my_cgroup/tasks
3. cgroup v2 사용 예제
cgroup 디렉토리 생성
sudo mkdir /sys/fs/cgroup/my_cgroup
메모리 제한 설정
echo 100M > /sys/fs/cgroup/my_cgroup/memory.max
프로세스 추가
echo <PID> > /sys/fs/cgroup/my_cgroup/cgroup.procs
cgroup 관련 도구
- systemd
- 대부분의 현대 Linux 시스템에서는 systemd를 사용하여 cgroup을 관리합니다.
- 서비스 단위 파일에서 cgroup 설정을 정의할 수 있습니다.
[Service] CPUQuota=50% MemoryMax=100M
- cgexec / cgclassify
- cgroup-tools 패키지에 포함된 도구로, 특정 명령을 cgroup에서 실행하거나 프로세스를 cgroup에 분류할 수 있습니다.
1. cgroup 디렉토리와 마운트의 연관성
- Greenplum Database의 리소스 그룹은 cgroup 기능을 사용하여 리소스를 제어합니다.
- cgroup 설정은 일반적으로 /sys/fs/cgroup 아래에 위치하며, 이는 특정 파일 시스템(예: tmpfs, cgroupfs)에 마운트되어 있습니다.
- NFS 서버 활성화 과정에서 마운트된 파일 시스템이 해제되면, 이 경로에서 관리되던 디렉토리도 함께 사라질 수 있습니다.
2. NFS 서버와 파일 시스템 충돌
- NFS 서버가 활성화되면서 /etc/exports 파일에 정의된 디렉토리를 NFS 서버가 관리하려고 할 때, 기존에 마운트되어 있던 파일 시스템이 충돌하거나 비정상적으로 해제될 수 있습니다.
- 파일 시스템이 해제되면, 그 경로에서 사용되던 데이터나 디렉토리가 임시로 보이지 않게 되며, 일부 경우 실제 데이터가 삭제될 수도 있습니다.
3. GPDB 폴더가 삭제될 수 있는 시나리오
- cgroup 디렉토리가 파일 시스템에 종속적일 때: GPDB가 사용하는 cgroup 디렉토리가 마운트된 파일 시스템 위에 있었고, 이 파일 시스템이 NFS 활성화로 인해 해제되었다면, cgroup 리소스 그룹과 관련된 데이터가 사라질 수 있습니다.
- 마운트 풀린 상태에서 GPDB가 작동할 경우: GPDB가 해당 디렉토리를 재사용하려고 하거나, 새로 생성하려는 과정에서 원래 디렉토리가 없는 상태라면, 운영체제가 "비어 있는" 상태의 디렉토리를 만들어버릴 수 있습니다.
- 강제로 디렉토리 삭제: cgroup 디렉토리가 풀린 상태에서 NFS가 동일한 경로를 다시 마운트하려고 하면, 기존 경로에 있던 내용이 덮어쓰이거나 삭제될 수 있습니다.
4. GPDB와 cgroup 리소스 그룹의 의존성
- GPDB는 리소스 그룹을 통해 CPU 및 메모리를 제어합니다. 리소스 그룹은 cgroup 설정에 강하게 의존하며, cgroup 디렉토리가 삭제되거나 제대로 마운트되지 않으면 GPDB의 리소스 그룹 기능이 비정상적으로 동작할 수 있습니다.
- 심각한 경우, GPDB가 정상적으로 시작되지 않거나 일부 리소스 그룹이 작동하지 않아 데이터베이스 성능이 저하될 수 있습니다.
5. 해결 및 예방 방법
(1) 현재 상황 복구
- 파일 시스템 확인: 먼저, 문제가 발생한 파일 시스템을 다시 마운트하고, cgroup 디렉토리가 복구되었는지 확인합니다.
mount | grep cgroup
- GPDB cgroup 디렉토리 복구: 만약 삭제된 디렉토리가 있다면, GPDB의 리소스 그룹 설정을 초기화하거나 다시 구성해야 할 수 있습니다. /sys/fs/cgroup/gpdb 디렉토리를 복구하고, 권한 및 설정을 확인합니다.
(2) NFS 설정 수정
- NFS 마운트 디렉토리 확인: NFS가 사용하는 디렉토리가 cgroup 디렉토리나 GPDB 데이터 디렉토리와 충돌하지 않도록 /etc/exports를 점검합니다.
- 파일 시스템 보호: 중요한 파일 시스템에 대해 NFS 서버 설정을 변경할 때 영향을 최소화하도록 주의합니다.
(3) GPDB 재설정
- 리소스 그룹 재구성: cgroup 디렉토리가 정상적으로 복구되지 않았다면, GPDB에서 리소스 그룹을 재구성합니다.
ALTER RESOURCE GROUP <group_name> SET MEMORY_LIMIT <value>;
- GPDB 재시작: 문제 해결 후 GPDB를 재시작하여 모든 리소스 그룹이 정상적으로 작동하는지 확인합니다.
반응형
'DB > PostgreSQL' 카테고리의 다른 글
| 쿼리 튜닝 - 플랜 분석 예시 (memory 부족) (0) | 2025.02.18 |
|---|---|
| could not find segment file (0) | 2025.01.22 |
| GPDB - Query Plan 예시 (0) | 2024.10.01 |
| GPDB - motion 정의 (0) | 2024.09.12 |
| GPDB 분산키 Randomly vs 특정 컬럼 (0) | 2024.09.12 |