728x90
반응형
운영하다 보면 어느 날 모니터링 화면에 낯선 숫자가 보인다.
Aborted_clients.
처음 보면 이렇게 생각하게 된다.
“이거… 장애 징조인가?”
결론부터 말하면,
조금씩 증가하는 건 정상,
빠르게 늘어나면 반드시 점검해야 할 신호다.
오늘은 MySQL Aborted_clients가 정확히 무엇인지, 왜 늘어나는지, 그리고 실무에서 어떻게 대응해야 하는지 정리해본다.
Aborted_clients란?
MySQL 서버 기준에서:
정상적인 종료(QUIT) 없이 끊어진 클라이언트 연결의 누적 횟수
즉,
MySQL 입장에서
“인사도 안 하고 나가버린 연결 수”다.
확인 명령어:
SHOW GLOBAL STATUS LIKE 'Aborted_clients';이 값은:
- 누적 카운터
- 서버 재시작 전까지 계속 증가
- 감소하지 않음
이라는 특징을 가진다.
언제 증가할까?
실제 현장에서 가장 많이 보는 원인들이다.
1. 애플리케이션 강제 종료
- Pod Kill
- App Crash
- 서버 재부팅
MySQL은 연결이 갑자기 사라졌다고 판단한다.
2. 네트워크 끊김
- Load Balancer idle timeout
- VPN 세션 종료
- 일시적인 네트워크 drop
특히 IDC ↔ Cloud 환경에서 자주 발생한다.
3. Connection Pool 설정 문제
대표 패턴:
- connection close 안 함
- keepalive 없음
- idle timeout mismatch
이 경우 조용히 쌓이다가 어느 순간 폭발한다.
4. MySQL wait_timeout 초과
SHOW VARIABLES LIKE 'wait_timeout';클라이언트가 놀고 있으면
MySQL이 먼저 끊어버린다 → aborted 처리.
Aborted_clients vs Aborted_connects 차이
많이 헷갈리는 포인트다.
항목의미
| Aborted_clients | 연결 후 비정상 종료 |
| Aborted_connects | 연결 시도 자체가 실패 |
간단히 말하면:
- clients → 이미 붙은 뒤 문제
- connects → 애초에 붙지도 못함
정상 범위는 어느 정도일까?
절대적인 기준은 없다.
대신 증가 속도가 중요하다.
일반적인 판단 기준
상태의미
| 하루 몇 건 | 정상 |
| 시간당 수십 | 주의 |
| 분당 증가 | 위험 |
| 배포 직후 급증 | 거의 확실히 앱 문제 |
특히 아래 조합이면 바로 조사 대상이다:
- Aborted_clients 증가
- Threads_connected 증가
- Connections 급증
→ connection leak 가능성 높음.
실무 점검 체크리스트
운영 중이면 최소 이것들은 같이 본다.
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Threads_running';
SHOW GLOBAL STATUS LIKE 'Connections';
SHOW GLOBAL STATUS LIKE 'Aborted_connects';그리고 앱 쪽에서는:
- connection pool max size
- idle timeout
- validation query
- close 여부
반드시 확인.
실제 현장에서 자주 나오는 원인 TOP 3
① Kubernetes Pod 재기동
Rolling 배포 중 DB 커넥션 정리 안 됨.
② LB idle timeout < MySQL wait_timeout
LB가 먼저 끊음 → MySQL 입장에서는 aborted.
③ Pool keepalive 미설정
장시간 idle 후 재사용 → 이미 죽은 connection.
한 줄 요약
Aborted_clients는:
MySQL이 기록한 “비정상 종료된 연결 수”
조금은 정상이다.
하지만 빠르게 늘어나면 반드시:
- 앱
- 네트워크
- connection pool
세 군데를 동시에 봐야 한다.
728x90
반응형