풀러가 없는 Postgres max_connections

Postgres는 연결에 경량 스레드 풀을 사용하지 않습니다. 각 클라이언트 연결은 완전한 시스템 프로세스를 트리거합니다.

postmaster 프로세스는 각 연결 시도에 대해 이 단일 세션이 닫힐 때까지 전용으로 새로운 세션("포크")을 생성합니다. 공식 프로젝트 문서는 아키텍처 기본 사항에 대한 장(postgresql.org/docs/current/connect-estab.html, "Connection Semantics" 섹션, 2026년 8월 24일 액세스)에서 이 메커니즘을 정확하게 설명합니다.

이 선택에는 실질적인 이점이 있습니다. 한 연결의 충돌이 다른 연결에 영향을 주지 않으며 각 프로세스가 서버의 나머지 부분과 격리됩니다. 또한 직접적인 비용도 발생합니다. 각각의 추가 연결은 자체 메모리 공간과 커널에 대한 자체 컨텍스트 전환 오버헤드를 포함하여 예약할 전체 OS 프로세스를 추가합니다.

두 가지 서로 다른 메커니즘이 기억에 영향을 미치며, 이를 혼동하면 거의 항상 오진이 발생합니다.

첫 번째는 고정되어 있습니다. 시작 시 Postgres는 이러한 연결이 이후에 열리는지 여부에 관계없이 max_connections 값에 따라 크기가 지정된 공유 메모리 구조(잠금, 프로세스 테이블)를 예약합니다. 설정에 대한 공식 문서에서는 이 설정을 늘리면 OS의 기본 구성에서 허용하는 것보다 더 많은 시스템 공유 메모리가 필요할 수 있다고 명시합니다(postgresql.org/docs/current/runtime-config-connection.html, 2026년 8월 24일 액세스).

두 번째는 가변적이며 규모면에서 훨씬 더 위험합니다. work_mem는 연결당 한 번 할당되지 않고 쿼리 계획의 정렬 또는 해싱 작업당 한 번 할당됩니다. 공식 문서는 이 점에 대해 명시적으로 설명합니다. 복잡한 쿼리는 여러 작업을 병렬로 시작할 수 있고 여러 세션이 동시에 동일한 작업을 수행할 수 있으므로 실제로 사용되는 메모리는 work_mem(postgresql.org/docs/current/runtime-config-resource.html, 2026년 8월 24일 액세스)의 몇 배 가치가 될 수 있습니다.

공식 PostgreSQL 프로젝트 위키에는 총 열려 있는 연결 수가 아니라 하드웨어가 병렬로 효율적으로 처리할 수 있는 활성 연결 수를 계산하기 위한 벤치마크 공식이 문서화되어 있습니다(wiki.postgresql.org/wiki/Number_Of_Database_Connections, 2026년 8월 24일 액세스).

8개의 물리적 코어와 SSD 스토리지가 있는 서버에서 공식은 처리량이 저하되기 전에 (8 × 2) + 1 = 17개의 활성 연결을 제공합니다. 이 수치는 종종 놀랍습니다. 실제로 애플리케이션이 여는 수백 개의 연결에 비하면 작은 것처럼 보입니다. 이것이 바로 다음 단락의 주제입니다.

The number calculated by the formula measures the concurrency that the CPU and disk can absorb, not the number of client connections your application needs to open. A fleet of 20 application processes, each with its own pool of 10 connections, opens 200 simultaneous connections to Postgres even if only 17 of them are actively working at any given time. Without a pooler, max_connections must cover the 200, not the 17. It is this gap that pushes most architectures to add a pooler in transaction mode, even if it means choosing which one (see our comparison PgBouncer, Supavisor and PgCat).

max_connections는 핫스왑되지 않습니다. 이것은 postmaster 컨텍스트 매개변수입니다. Postgres는 시작 시 이를 한 번 읽어 공유 메모리 크기를 조정합니다. 구성 다시 로드(pg_reload_conf() 또는 SIGHUP)로는 충분하지 않습니다. 서버를 다시 시작해야 합니다.

먼저 현재 값과 해당 컨텍스트를 확인하여 다시 시작해야 하는지 확인하세요.

SHOW max_connections;

SELECT name, setting, context
FROM pg_settings
WHERE name = 'max_connections';

-- context='postmaster'는 재부팅이 필요함을 확인합니다.

그런 다음 새 값을 적용하고 다시 시작합니다.

ALTER SYSTEM SET max_connections = '300';

-- postgresql.auto.conf에 작성되었습니다.
-- Postgres를 다시 시작할 때까지는 아무런 효과가 없습니다.

# 체계적으로
sudo systemctl restart postgresql

# systemd 없이 pg_ctl을 사용하여 직접
pg_ctl restart -D $PGDATA -m fast

max_connections 크기 조정은 단순한 이론적인 연습이 아닙니다. Aurabase가 관리형 Postgres 클러스터에 예산을 책정하는 방법은 다음과 같습니다.

전용 클러스터: 프로젝트당 Postgres 클러스터 1개

이 수준에서( 전용 및 공유 기반비교 참조) 각 프로젝트는 인스턴스 크기에 맞는 자체 CloudNativePG 클러스터와 자체 max_connections 예산을 받습니다.

공유 클러스터: 조직의 여러 프로젝트, 공유 예산

이 두 번째 경로에서는 동일한 조직의 모든 프로젝트가 공유 기본 프로젝트 앞에서 CNPG 풀러(PgBouncer, transaction모드)를 통해 연결됩니다.

조직의 모든 프로젝트는 공유 애플리케이션 역할을 통해 연결됩니다. 따라서 max_user_connections만으로도 이 역할이 전체 클러스터에서 열 수 있는 총 서버 연결을 제한합니다. 이는 풀러 자체에 대한 클라이언트 연결만 제한하는 max_client_conn가 아닌 실제 클러스터 전역 보호 장치입니다.

그러나 이 풀러는 SDK 애플리케이션 트래픽만 제공합니다. PostgREST는 기본(-rw서비스)에 직접 연결된 상태로 유지됩니다. 트랜잭션 모드에서 풀링하면 pgrst라는 전용 LISTEN 채널을 수신하는 스키마 재로드 메커니즘이 중단됩니다. 따라서 자체 연결(공유 수준의 복제본당 2개, 전용 수준의 복제본당 10개)은 풀러 외부에 있는 기본의 max_connections 예산에서 직접적으로 아래 절차의 1단계에 포함되어야 하는 "잊혀진" 연결 종류로 직접 계산됩니다.

이 절차는 특정 도구에 의존하지 않으며 관리되거나 자체 호스팅되는 모든 Postgres 서버에 적용됩니다.

1. 실제 클라이언트 연결을 계산합니다. 내부 풀의 크기와 관리 도구, 복제 및 모니터링을 곱한 애플리케이션 프로세스 수입니다. max_connections 층을 설정하는 것은 공식이 아니라 이 숫자입니다.
2. PostgreSQL 위키의 공식(물리적 코어 × 2) + 효율적인 디스크를 사용하여 하드웨어의 이상적인 동시성을 계산하십시오. 이 그림은 처리량을 저하시키지 않고 실제로 병렬로 작동할 수 있는 연결 수를 나타냅니다.
3. superuser_reserved_connections 및 애플리케이션 외부에서 자체 연결을 여는 모든 관리 도구에 대한 여유를 두고 1단계의 실제 요구 사항 이상으로 max_connections를 설정합니다.
4. ALTER SYSTEM SET을 사용하여 변경 사항을 적용한 다음 서버를 다시 시작합니다. 이것은 postmaster 매개변수입니다. 위에서 자세히 설명했듯이 간단한 다시 로드만으로는 충분하지 않습니다.
5. 시간 경과에 따른 pg_stat_activity를 모니터링합니다. 유휴 연결 수가 활성 연결 수를 크게 초과하는 경우 이는 max_connections 문제가 아닙니다. 이는 더 높은 수가 아니라 서버 앞에 풀러가 필요하다는 신호입니다.

5단계의 모니터링 요청은 직접 사용할 수 있습니다.

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

값에 관계없이 max_connections만으로는 더 이상 충분하지 않을 때 세 가지 신호가 체계적으로 반환됩니다.

1. FATAL: sorry, too many clients already 오류는 최대 로드 중에 나타나는 반면 pg_stat_activity에 표시된 대부분의 연결은 유휴 상태입니다.
2. 애플리케이션은 서버리스 환경이나 임시 작업자(에지 기능, 단기 작업)에서 실행되며 Postgres의 연결당 프로세스 모델이 수용하도록 설계된 것보다 훨씬 빠르게 연결을 열고 닫습니다.
3. 위의 공식과 절차는 이미 적용되었으며 클라이언트 연결에 대한 실제 요구는 work_mem 또는 shared_buffers를 위험에 빠뜨리지 않고 할당할 수 있는 사용 가능한 메모리를 계속 초과하고 있습니다.

이 세 가지 경우에서 정답은 거의 항상 더 높은 max_connections가 아니라 애플리케이션과 Postgres 사이에 위치한 풀러입니다. 비교 PgBouncer, Supavisor 및 PgCat에서는 세 가지 옵션을 자세히 설명하고 트랜잭션 모드 가이드에서는 풀러가 설치된 후 가장 일반적인 절충안을 설명합니다. 연결 이상의 모든 Postgres 조정에 대해서는 프로덕션 Postgres 조정 체크리스트를 참조하세요.