PostgreSQL 53000 오류 원인과 해결 방법 완벽 가이드

53000 insufficient resources 는?

PostgreSQL 에러 코드 53000은 insufficient_resources로, 데이터베이스 서버가 쿼리나 트랜잭션을 수행하는 데 필요한 시스템 자원(메모리, 파일 디스크립터, 프로세스 등)이 부족할 때 발생합니다. 이 에러는 단순한 쿼리 오류가 아니라 서버 인프라 레벨의 문제를 나타내는 심각한 경고 신호입니다. 특히 트래픽이 급증하거나 대용량 데이터 처리, 혹은 잘못된 서버 설정이 누적될 때 예고 없이 발생할 수 있어 사전 모니터링과 예방이 매우 중요합니다.

---

주요 발생 원인

1. 메모리 부족 (Out of Memory)

PostgreSQL은 각 연결 및 쿼리 실행 시 work_mem, shared_buffers 등의 메모리를 할당합니다. 동시 접속자가 급증하거나 대용량 정렬, 해시 조인 등의 복잡한 쿼리가 반복 실행될 경우 서버의 가용 메모리를 초과하여 이 에러가 발생합니다. 특히 work_mem 값이 너무 높게 설정된 상태에서 동시 쿼리가 많아지면 전체 메모리 사용량이 기하급수적으로 증가하게 됩니다.

2. 파일 디스크립터(File Descriptor) 한계 초과

운영 체제는 프로세스당 열 수 있는 파일 디스크립터 수를 제한합니다. PostgreSQL은 테이블, 인덱스, WAL 파일 등을 파일 시스템 상의 파일로 관리하기 때문에, 접속 수가 늘거나 파티션 테이블처럼 다수의 파일을 동시에 열어야 하는 구조에서 OS의 파일 디스크립터 한계에 부딪히게 됩니다. 이 문제는 특히 파티션이 수백 개 이상인 대형 테이블을 운영하는 환경에서 자주 관찰됩니다.

3. 최대 연결 수(max_connections) 초과 및 프로세스 자원 고갈

PostgreSQL은 클라이언트 연결마다 별도의 백엔드 프로세스를 생성합니다. max_connections 설정 값을 초과하는 연결 요청이 들어오거나, 연결이 제대로 종료되지 않아 좀비 프로세스가 누적되면 시스템 자원이 고갈됩니다. 애플리케이션에서 커넥션 풀을 사용하지 않거나 커넥션 반환이 누락된 경우에도 이 문제가 발생합니다.

---

해결 방법

1. 메모리 설정 최적화

현재 메모리 사용량과 설정값을 먼저 확인합니다.

-- 현재 메모리 관련 설정 확인
SHOW work_mem;
SHOW shared_buffers;
SHOW max_connections;

-- 현재 연결별 메모리 사용 현황 확인
SELECT
    pid,
    usename,
    application_name,
    state,
    query_start,
    left(query, 80) AS short_query
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY query_start;

postgresql.conf에서 메모리 설정을 현실적인 값으로 조정합니다.

-- postgresql.conf 설정 변경 후 현재 세션에 즉시 적용 (슈퍼유저)
ALTER SYSTEM SET work_mem = '64MB';         -- 기본값 4MB, 과도하게 높이지 않도록 주의
ALTER SYSTEM SET shared_buffers = '2GB';    -- 전체 RAM의 25% 권장
ALTER SYSTEM SET maintenance_work_mem = '512MB';

-- 설정 재로드 (서비스 재시작 없이)
SELECT pg_reload_conf();

-- 변경 확인
SHOW work_mem;

2. 파일 디스크립터 한계 확인 및 조정

-- PostgreSQL이 현재 열고 있는 파일 수 확인 (pg_stat_activity 기반)
SELECT count(*) AS total_connections FROM pg_stat_activity;

-- 파티션 테이블의 자식 테이블 수 확인
SELECT
    parent.relname AS parent_table,
    count(child.relname) AS partition_count
FROM pg_inherits
JOIN pg_class parent ON pg_inherits.inhparent = parent.oid
JOIN pg_class child  ON pg_inherits.inhrelid  = child.oid
GROUP BY parent.relname
ORDER BY partition_count DESC;

OS 레벨에서 파일 디스크립터 한계를 높입니다 (Linux 기준, shell 명령):

-- PostgreSQL 내에서 현재 max_files_per_process 확인
SHOW max_files_per_process;

-- 필요시 조정 (postgresql.conf)
ALTER SYSTEM SET max_files_per_process = 1000;
SELECT pg_reload_conf();

3. 연결 수 관리 및 유휴 연결 정리

-- 현재 연결 상태별 집계
SELECT
    state,
    count(*) AS connection_count,
    max(now() - state_change) AS max_idle_duration
FROM pg_stat_activity
GROUP BY state
ORDER BY connection_count DESC;

-- 오래된 유휴 연결 강제 종료 (idle 상태 10분 이상)
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle'
  AND state_change < now() - interval '10 minutes'
  AND pid <> pg_backend_pid();

-- 특정 유저의 모든 연결 종료
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE usename = 'target_user'
  AND pid <> pg_backend_pid();

-- max_connections 및 현재 사용량 확인
SELECT
    max_conn,
    used,
    res_for_super,
    max_conn - used - res_for_super AS available
FROM
    (SELECT count(*) AS used FROM pg_stat_activity) t1,
    (SELECT setting::int AS max_conn FROM pg_settings WHERE name = 'max_connections') t2,
    (SELECT setting::int AS res_for_super FROM pg_settings WHERE name = 'superuser_reserved_connections') t3;

---

예방 방법

1. PgBouncer 또는 커넥션 풀러 도입

애플리케이션과 PostgreSQL 사이에 PgBouncer와 같은 커넥션 풀러를 반드시 도입하세요. 직접 연결 방식은 연결마다 백엔드 프로세스를 생성하므로, 트래픽 급증 시 자원 고갈로 이어집니다. PgBouncer의 transaction 모드를 사용하면 수천 개의 클라이언트 연결을 수십 개의 실제 DB 연결로 효율적으로 관리할 수 있습니다.

-- PgBouncer 도입 후 실제 DB 연결 수 모니터링 쿼리
SELECT
    client_addr,
    count(*) AS connection_count,
    string_agg(state, ', ') AS states
FROM pg_stat_activity
WHERE usename IS NOT NULL
GROUP BY client_addr
ORDER BY connection_count DESC
LIMIT 20;

2. 지속적인 리소스 모니터링 자동화

Prometheus + pg_stat_statements + Grafana 조합으로 메모리, 연결 수, 쿼리 성능을 실시간으로 모니터링하고, 임계값 초과 시 알림을 받도록 설정하세요. 아래 쿼리를 주기적으로 실행하는 모니터링 스크립트를 구성하면 문제 발생 전에 선제적으로 대응할 수 있습니다.

-- 리소스 모니터링용 종합 쿼리 (cron 또는 모니터링 툴에서 주기적 실행 권장)
SELECT
    now() AS check_time,
    (SELECT count(*) FROM pg_stat_activity) AS total_connections,
    (SELECT count(*) FROM pg_stat_activity WHERE state = 'active') AS active_queries,
    (SELECT count(*) FROM pg_stat_activity WHERE state = 'idle in transaction') AS idle_in_transaction,
    (SELECT setting FROM pg_settings WHERE name = 'max_connections') AS max_connections,
    (SELECT pg_size_pretty(sum(blks_hit + blks_read) * 8192)
     FROM pg_stat_database) AS total_buffer_usage;

---

관련 에러

• 53100 disk_full: 디스크 공간 부족으로 데이터 쓰기가 불가능한 상태. WAL 파일이나 임시 파일 생성 실패 시 발생.
• 53200 out_of_memory: 53000의 하위 에러로, 메모리 할당 자체가 실패했을 때 발생. OOM Killer에 의해 PostgreSQL 프로세스가 종료될 수 있음.
• 53300 too_many_connections: max_connections 설정을 초과한 연결 시도 시 발생. PgBouncer 미사용 환경에서 가장 빈번하게 나타남.
• 57P03 cannot_connect_now: 서버가 시작 중이거나 복구 모드에 있어 연결 자체가 불가능한 상태.

본 포스트는 AI가 생성한 기술 가이드입니다. 운영 환경 적용 전 충분한 검토를 권장합니다.