cl_waiting이 높으면 클라이언트가 기다리고 있다는 사실은 알 수 있지만 원인이 작은 pool이라는 결론은 아직 이릅니다. 같은 database/user 풀에서 사용 중인 서버 연결과 쿼리 지속 시간을 함께 봐야 합니다. 다른 풀의 idle 연결을 보고 전체 용량이 남는다고 판단하지 마세요.
SHOW POOLS;
SHOW STATS;
SHOW DATABASES;위 명령은 PostgreSQL 데이터베이스가 아니라 PgBouncer 관리 콘솔에서 실행합니다. 관리 출력 설명과 설치 버전의 필드를 대조하고 같은 풀을 일정 간격으로 비교합니다. cl_waiting·sv_active·sv_idle의 한 번 측정값보다 대기 증가와 처리율 변화가 유용합니다.
계산 예: 연결을 두 배로 늘리면 무엇이 달라지는가
가상의 4개 database/user 풀에 각각 서버 연결 한도 20이 있으면 최대 예산은 단순 합계만으로도 80입니다. 여러 PgBouncer 인스턴스가 같은 PostgreSQL을 쓰면 이를 다시 합산해야 합니다. default_pool_size를 전역 연결 수처럼 해석하면 DB의 관리용·복제용 여유를 놓칠 수 있습니다. 설정 문서의 풀별 한도와 database/user 제한을 함께 봅니다.
대기와 함께 장기 트랜잭션·잠금 대기가 증가하면 먼저 쿼리와 트랜잭션 범위를 조사합니다. DB는 여유롭고 정상적인 짧은 쿼리만 풀 한도에 걸린다면 스테이징에서 한도를 조금 조정해 처리율과 지연을 비교할 수 있습니다. 연결을 늘려도 처리율은 같고 DB 대기만 늘면 그 변경은 해법이 아닙니다.
변경 항목마다 reload·재연결·재시작 필요 여부가 다릅니다. 수정 전 값을 남기고 같은 부하에서 대기 감소와 오류율을 확인하며, 숫자 20·80은 설명용 계산이지 이 서버의 관측값이나 권장 크기가 아닙니다.