Apr 3, 2026

MySQL too many connections 가이드: 연결 수가 꽉 찰 때 어떻게 봐야 할까

운영 중인 서비스에서 too many connections 에러가 보이면 꽤 당황스럽습니다. 애플리케이션은 살아 있는 것처럼 보이는데 DB 연결이 더 이상 잡히지 않아서 요청이 줄줄이 실패할 수 있기 때문입니다.

이 글에서는 아래 내용을 정리합니다.

MySQL too many connections가 왜 생기는지
어떤 순서로 원인을 좁혀야 하는지
connection pool, 누수, 긴 쿼리, 트래픽 급증을 어떻게 구분할지

핵심은 연결 수 문제는 DB 설정만의 문제가 아니라, 애플리케이션 풀 설정과 쿼리 지속 시간까지 함께 봐야 풀린다는 점입니다.

왜 too many connections가 생길까

대표적인 원인은 아래와 같습니다.

애플리케이션이 연결을 제대로 반환하지 않음
connection pool 크기가 과도함
느린 쿼리 때문에 연결이 오래 점유됨
트래픽이 갑자기 급증함
max_connections가 워크로드에 비해 너무 낮음

즉, 단순히 DB가 “약해서” 생기는 문제라고 보기 어렵습니다.

먼저 무엇부터 확인할까

실무에서는 아래 순서가 실용적입니다.

현재 연결 수가 얼마나 차 있는지 확인
활성 세션이 무엇을 하고 있는지 보기
느린 쿼리가 있는지 확인
앱의 connection pool 설정 확인
최근 배포나 트래픽 변화 확인

특히 “연결이 많다”와 “연결이 오래 붙어 있다”는 전혀 다른 문제일 수 있습니다.

앱 쪽에서 자주 생기는 문제

1. connection leak

쿼리 후 연결을 반납하지 않으면 풀에서 연결이 계속 점유됩니다. 이 문제는 트래픽이 조금만 늘어도 빠르게 터집니다.

2. pool size 과다

애플리케이션 인스턴스 수가 여러 대인데 각 인스턴스가 큰 풀을 갖고 있으면, 합쳐서 MySQL 한도를 쉽게 넘을 수 있습니다.

3. 타임아웃 설정 부재

응답이 느린 요청이 오래 매달리면 연결도 같이 오래 잡고 있게 됩니다.

DB 쪽에서는 무엇을 볼까

DB에서는 보통 아래를 함께 봅니다.

현재 세션 수
Sleep 세션 과다 여부
오래 실행 중인 쿼리
잠금 대기

연결 수가 많아도 실제로는 대부분 Sleep이고, 앱이 연결 관리를 잘못하고 있는 경우도 흔합니다.

max_connections만 올리면 될까

긴급 대응으로는 가능할 수 있지만, 근본 해결은 아닐 때가 많습니다.

왜냐하면:

느린 쿼리는 그대로 남고
누수 문제도 그대로 남고
메모리 사용량만 더 커질 수 있기 때문입니다

즉, 설정 완화는 응급처치일 수는 있어도 원인 분석을 대체하지는 못합니다.

자주 하는 오해

1. DB CPU가 낮으면 DB 문제는 아니다

연결 고갈은 CPU와 별개로도 충분히 생길 수 있습니다.

2. pool을 크게 잡으면 안전하다

오히려 전체 시스템 차원에서는 더 위험해질 수 있습니다.

3. Sleep 세션은 무조건 문제 없다

일부는 정상일 수 있지만, 너무 많으면 연결 반환이나 풀 설정을 의심해야 합니다.

FAQ

Q. 가장 먼저 앱에서 확인할 것은 무엇인가

풀 크기, connection 반환 코드, 요청 타임아웃 설정입니다.

Q. max_connections를 올려도 되나

단기 대응으로는 가능하지만, 왜 포화됐는지 먼저 파악하는 것이 중요합니다.

Q. 느린 쿼리도 연결 수 문제를 만들 수 있나

그렇습니다. 오래 실행되는 쿼리는 연결을 오래 붙잡아 전체 연결 고갈로 이어질 수 있습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.