SUSE OS에서 PostgreSQL 기반 DBMS 대용량 처리 문제 정리

SUSE OS에서 PostgreSQL 기반 DBMS 대용량 처리 문제 정리

정리된 내용

SUSE OS 커널 7버전대 환경에서 PostgreSQL 기반 DBMS가 대용량 데이터를 처리할 때 문제가 발생한다면, 단순히 DB 설정만 볼 것이 아니라 커널 메모리 정책, 디스크 I/O, 파일 시스템, 커넥션 수, 체크포인트, WAL 처리량을 함께 확인해야 한다.

핵심 원인은 대용량 쿼리 자체보다 메모리 사용량 증가, 임시 파일 생성, 디스크 쓰기 병목, 체크포인트 집중, 커넥션 과다, 커널 캐시 압박이 동시에 겹치는 경우가 많다.
운영 환경에서는 PostgreSQL 설정값과 OS 커널 파라미터를 분리해서 보지 말고 하나의 처리 흐름으로 점검해야 한다.

구분	주요 문제	확인 방향
메모리	대용량 정렬, 해시 조인, 캐시 부족, Swap 발생	shared_buffers, work_mem, maintenance_work_mem, Huge Pages 확인
I/O	디스크 대기 증가, WAL 쓰기 지연, 임시 파일 폭증	iostat, vmstat, 체크포인트 로그, WAL 디렉터리 사용량 확인
커널	페이지 캐시 압박, THP 영향, 파일 디스크립터 부족	Transparent Huge Pages, vm 파라미터, ulimit, sysctl 확인
DB 설정	체크포인트 과다, autovacuum 지연, 통계 불일치	checkpoint_timeout, max_wal_size, autovacuum, 통계 갱신 확인
쿼리	Full Scan, 잘못된 실행계획, 인덱스 미사용	EXPLAIN ANALYZE, 인덱스, 파티셔닝, 통계 정보 확인

상세 내용

PostgreSQL 기반 DBMS는 대용량 데이터를 처리할 때 메모리와 디스크를 함께 사용한다. 작은 데이터에서는 문제가 없던 쿼리도 데이터가 수천만 건 이상으로 커지면 정렬, 조인, 집계, 인덱스 스캔 과정에서 임시 파일을 만들거나 디스크 I/O를 크게 증가시킬 수 있다.

PostgreSQL 공식 문서에서도 Linux 환경에서 Huge Pages를 사용하면 큰 shared_buffers를 사용하는 경우 메모리 관리 오버헤드를 줄일 수 있다고 설명한다. 반면 Transparent Huge Pages는 일부 Linux 환경에서 PostgreSQL 성능 저하를 유발할 수 있어 주의가 필요하다고 안내한다. :contentReference[oaicite:0]{index=0}

SUSE 문서에서도 시스템은 기본적으로 THP를 사용할 수 있으며, 명시적인 Huge Pages는 부팅 시점에 설정할 수 있다고 설명한다. 따라서 SUSE OS에서 PostgreSQL 대용량 처리를 안정화하려면 DB 파라미터뿐 아니라 커널의 Huge Pages, THP, 메모리 회수 정책까지 함께 확인하는 것이 좋다. :contentReference[oaicite:1]{index=1}

주요 원인

1. 메모리 설정 부족 또는 과다

PostgreSQL에서 shared_buffers는 데이터 페이지 캐시에 사용되는 핵심 메모리 영역이다. 값이 너무 작으면 디스크 접근이 늘고, 너무 크면 OS 페이지 캐시와 충돌하거나 메모리 압박이 커질 수 있다.

work_mem은 정렬, 해시 조인, 집계 작업에 사용된다. 주의할 점은 이 값이 전체 서버 기준이 아니라 작업 단위로 사용된다는 것이다. 커넥션이 많고 복잡한 쿼리가 동시에 실행되면 work_mem이 예상보다 훨씬 많이 사용될 수 있다.

SHOW shared_buffers;
SHOW work_mem;
SHOW maintenance_work_mem;

2. Transparent Huge Pages 영향

THP는 커널이 메모리 페이지를 자동으로 큰 페이지로 묶어 관리하는 기능이다. 일반 애플리케이션에서는 도움이 될 수 있지만, PostgreSQL 같은 DBMS에서는 지연 시간 변동이나 성능 저하 원인이 될 수 있다.

cat /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/kernel/mm/transparent_hugepage/defrag

PostgreSQL 전용 서버라면 THP를 끄고 명시적 Huge Pages를 사용하는 구성을 검토할 수 있다. 다만 운영 중인 서버에서는 즉시 변경보다 테스트 서버에서 부하 패턴을 재현한 뒤 적용하는 것이 안전하다.

3. 디스크 I/O 병목

대용량 조회, 적재, 배치, 인덱스 생성 작업은 디스크 I/O를 크게 증가시킨다. 특히 WAL 쓰기와 데이터 파일 쓰기가 같은 디스크에 집중되면 DB 전체 응답 시간이 늘어날 수 있다.

iostat -x 1
vmstat 1
pidstat -d 1

await, util, r/s, w/s 값이 높게 유지된다면 디스크 대기 병목을 의심할 수 있다. SSD, NVMe, SAN 환경에 따라 해석은 달라지지만, DBMS 대용량 처리에서는 I/O 대기 시간이 가장 직접적인 장애 원인이 되는 경우가 많다.

4. 체크포인트와 WAL 쓰기 집중

PostgreSQL은 변경 내용을 WAL에 기록하고, 일정 시점마다 체크포인트를 수행한다. 대량 INSERT, UPDATE, DELETE, 배치 작업 중 체크포인트가 자주 발생하면 순간적으로 디스크 쓰기가 몰릴 수 있다.

SHOW checkpoint_timeout;
SHOW max_wal_size;
SHOW min_wal_size;
SHOW checkpoint_completion_target;

체크포인트가 너무 자주 발생한다면 max_wal_size를 늘리고 checkpoint_completion_target을 조정해 쓰기 부하를 분산하는 방향을 검토한다.

5. 커넥션 과다

PostgreSQL은 커넥션마다 일정한 메모리와 프로세스 리소스를 사용한다. WAS나 배치 서버에서 커넥션 풀을 과도하게 열면, 실제 쿼리보다 커넥션 유지 비용과 메모리 사용량이 더 큰 문제가 될 수 있다.

SHOW max_connections;

SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state
ORDER BY count(*) DESC;

커넥션 수가 많다면 PostgreSQL 설정을 무작정 늘리기보다 애플리케이션 커넥션 풀 크기, idle 커넥션, long running transaction을 먼저 확인해야 한다.

6. 통계 정보 불일치와 실행계획 문제

데이터가 급격히 증가했는데 통계 정보가 갱신되지 않으면 PostgreSQL 옵티마이저가 잘못된 실행계획을 선택할 수 있다. 이 경우 인덱스가 있어도 Full Scan이 발생하거나, 조인 순서가 비효율적으로 잡힐 수 있다.

ANALYZE;

EXPLAIN (ANALYZE, BUFFERS)
SELECT ...
;

대용량 테이블은 단순 인덱스 추가보다 파티셔닝, 복합 인덱스, 통계 타깃 조정, VACUUM 상태를 함께 봐야 한다.

점검 명령어

SUSE OS에서 PostgreSQL 기반 DBMS 대용량 처리 문제를 분석할 때는 DB 내부 상태와 OS 상태를 동시에 수집하는 것이 좋다.

OS 메모리 확인

free -h
vmstat 1
cat /proc/meminfo | egrep "MemTotal|MemFree|MemAvailable|Huge|Swap"

Huge Pages와 THP 확인

cat /proc/meminfo | grep -i huge
cat /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/kernel/mm/transparent_hugepage/defrag

디스크 I/O 확인

iostat -x 1
iotop
pidstat -d 1

PostgreSQL 세션 확인

SELECT pid, usename, state, wait_event_type, wait_event, query_start, query
FROM pg_stat_activity
ORDER BY query_start;

임시 파일 발생 확인

SELECT datname, temp_files, pg_size_pretty(temp_bytes) AS temp_size
FROM pg_stat_database
ORDER BY temp_bytes DESC;

테이블과 인덱스 크기 확인

SELECT relname,
       pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 20;

개선 방향

1. 메모리 파라미터 조정

shared_buffers는 서버 메모리와 OS 캐시 사용량을 함께 고려해 조정한다. work_mem은 단일 쿼리만 보고 크게 잡으면 동시 실행 시 전체 메모리 사용량이 폭증할 수 있으므로, 커넥션 수와 쿼리 복잡도를 함께 계산해야 한다.

shared_buffers = 8GB
work_mem = 64MB
maintenance_work_mem = 2GB

위 값은 예시일 뿐이며, 실제 서버 메모리, 동시 접속 수, 쿼리 유형에 따라 달라진다.

2. 명시적 Huge Pages 검토

대용량 메모리를 사용하는 PostgreSQL 서버에서는 명시적 Huge Pages 사용을 검토할 수 있다. PostgreSQL에서는 shared_memory_size_in_huge_pages 값을 통해 필요한 Huge Pages 수를 확인할 수 있다.

SHOW shared_memory_size_in_huge_pages;

이후 OS에서 필요한 Huge Pages를 확보하고 PostgreSQL 설정에서 huge_pages를 지정한다.

huge_pages = on

huge_pages = on은 Huge Pages가 부족하면 PostgreSQL이 시작되지 않을 수 있다.
운영 서버에 바로 적용하기보다 테스트 환경에서 필요한 페이지 수와 재기동 절차를 먼저 검증해야 한다.

3. THP 비활성화 검토

PostgreSQL 대용량 처리에서 지연 시간이 불규칙하게 튄다면 THP 상태를 확인한다. 일시적으로 테스트할 때는 아래와 같이 확인 및 변경할 수 있다.

cat /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

영구 적용 방식은 SUSE OS 버전, 부팅 방식, 운영 정책에 따라 달라질 수 있으므로 서버 표준 구성에 맞춰 반영해야 한다.

4. 체크포인트 부하 완화

대량 적재나 배치 작업 중 디스크 쓰기가 순간적으로 몰린다면 체크포인트 설정을 점검한다.

checkpoint_timeout = 15min
max_wal_size = 16GB
min_wal_size = 4GB
checkpoint_completion_target = 0.9

WAL 크기를 늘리면 체크포인트 빈도를 줄일 수 있지만, 장애 복구 시 필요한 시간이나 디스크 사용량도 함께 증가할 수 있다.

5. 쿼리와 테이블 구조 개선

DBMS 대용량 처리 문제는 커널 튜닝만으로 해결되지 않는 경우가 많다. Full Scan이 반복되는 테이블, 조건절과 맞지 않는 인덱스, 과도한 정렬, 불필요한 DISTINCT, 큰 OFFSET 페이지네이션은 먼저 개선해야 한다.

EXPLAIN (ANALYZE, BUFFERS)
SELECT ...
;

대용량 테이블에서는 기간 기준 파티셔닝, 보관 주기 분리, 이력 테이블 아카이빙, 배치 단위 축소가 효과적일 수 있다.

운영 기준 권장 절차

실무 기준으로 보면 PostgreSQL 기반 DBMS의 대용량 처리 문제는 한 번에 설정값을 크게 바꾸는 방식보다, 병목 지점을 확인하고 변경 전후 수치를 비교하는 방식이 안전하다.

1단계: 장애 시간대의 CPU, 메모리, Swap, I/O, PostgreSQL 세션 상태를 수집한다.
2단계: 느린 쿼리와 임시 파일 발생량을 확인한다.
3단계: shared_buffers, work_mem, 체크포인트, WAL 설정을 점검한다.
4단계: THP, Huge Pages, 파일 디스크립터, 커널 vm 파라미터를 확인한다.
5단계: 테스트 환경에서 변경값을 검증한 뒤 운영에 순차 반영한다.

특히 커널 7버전대 환경이라고 표현되는 서버에서는 OS 기본 정책이 이전 버전과 다르게 적용되어 있을 수 있다. 따라서 기존 PostgreSQL 튜닝 문서를 그대로 적용하기보다 현재 서버의 커널 설정, 메모리 정책, 파일 시스템, DB 버전을 함께 확인해야 한다.

결론

SUSE OS에서 PostgreSQL 기반 DBMS가 대용량 데이터를 처리하다가 느려지는 문제는 대부분 DB 설정, 커널 메모리 정책, 디스크 I/O, 쿼리 실행계획이 복합적으로 얽혀 발생한다. 따라서 shared_buffers나 work_mem만 조정하는 방식으로는 근본 원인을 놓칠 수 있다.

우선 OS 자원 사용량과 PostgreSQL 내부 지표를 함께 확인하고, THP와 Huge Pages, 체크포인트, WAL, 임시 파일, 커넥션 수, 실행계획을 순서대로 점검하는 것이 좋다. 대용량 DBMS 운영에서는 성능 튜닝보다 먼저 재현 가능한 지표 수집과 변경 전후 비교 기준을 마련하는 것이 안정적인 해결 방법이다.