느린 쿼리 제거, 풀 크기와 대기 타임아웃 조정(풀을 무작정 키우지 않기), 기능별 풀 분리.
인프라팀 할 일
DB의 최대 연결 수와 CPU·IOPS 여유 확인, 증설·오토스케일링 전에 서버 수 × 풀 크기가 최대 연결 수 안인지 확인, 커넥션 대기·락 대기 지표를 모니터링에 추가.
수치 감각
필요한 연결 수는 “초당 요청 × 한 건이 연결을 점유하는 시간”으로 어림합니다. 1초에 2,000건, 건당 5ms면 평균 10개가 늘 바쁩니다. 몰릴 때를 생각해 보통 그 두세 배를 둡니다. 쿼리가 150ms로 느려지면 같은 요청에 300개가 필요해집니다.
그래프에서는
한도에 닿아 평평해짐 · 사용 중 DB 연결 수, 커넥션 대기 시간
확인할 곳
DB 쪽에서 게임 서버별 연결 상태를 셈. MySQL은 SHOW PROCESSLIST의 Host·Command(쉬는 연결은 Sleep)·Time과 Threads_connected·Threads_running, 거부된 연결 수 Connection_errors_max_connections를 봄. PostgreSQL은 pg_stat_activity를 client_addr·state로 묶어 셈. 게임 서버의 커넥션 풀 라이브러리가 대기 수·대기 시간을 내보내면 함께 봄
이러면 맞음
한 게임 서버의 연결이 풀 크기만큼 모두 쿼리 실행 중이고 쉬는 연결이 0인 동안 로그인·저장이 대기함. 또는 DB 전체 연결 수가 max_connections에 닿아 새 연결이 거부됨
이러면 아님
쉬는 연결이 넉넉한데도 느리면 쿼리 자체의 지연(db-no-index, db-hot-row)이나 DB 자원 포화 쪽
확인 수단
인프라 도구로 확인(게임 코드 불필요)
더 알아보기
풀을 무작정 키우면 DB CPU와 잠금 경쟁만 늘어 모두가 같이 느려집니다. 또 서버 수 × 풀 크기가 DB의 최대 연결 수를 넘으면, 증설한 서버나 재시작한 서버가 연결조차 못 맺습니다. 오토스케일링이나 점검 직후에 흔합니다.
출처
Number Of Database ConnectionsPostgreSQL DB 자원을 다 쓴 뒤에는 연결을 늘려도 처리량이 오히려 떨어짐, 활성 연결을 자원에 맞추고 나머지는 대기열에 두는 편이 지연·처리량 모두 좋음
Too many connectionsMySQL max_connections를 모두 쓰면 새 연결이 Too many connections 오류로 거부됨