인생은 속도가 아니라 방향이다

DB/MySQL

[MySQL] SHOW PROCESSLIST와 DB 모니터링 메트릭 정리

Joonfluence 2026. 7. 10.

1. 문서 제목

MySQL SHOW PROCESSLIST와 DB 모니터링 메트릭 정리

2. 기술 개요 요약

DB 장애나 성능 저하가 발생했을 때는 먼저 현상을 관찰하고, 현재 DB 내부에서 어떤 세션이 실행 중인지 확인한 뒤, 원인을 쿼리 문제·락 경합·리소스 부족으로 분류해야 한다. MySQL의 SHOW PROCESSLIST는 서버 내부 스레드가 현재 수행 중인 작업을 보여주는 기본 진단 명령어다. 여기에 QPS, Slow Query, InnoDB Buffer Pool Hit Ratio, Replication Lag, Lock Wait, 활성 커넥션 수 같은 메트릭을 함께 보면 장애 원인을 더 빠르게 좁힐 수 있다.

이 문서는 면접 답변과 실무 운영 모두에서 사용할 수 있도록 SHOW PROCESSLIST 해석법과 DB 모니터링 메트릭을 레퍼런스 형태로 정리한다.

3. 핵심 기능/개념 정리

3-1. 장애 대응 기본 흐름

단계 확인할 것 목적
1. 현상 파악 CPU, 메모리, 디스크 I/O, 커넥션 수, 슬로우 쿼리 수 장애가 리소스 문제인지, DB 내부 문제인지 1차 구분
2. 현재 세션 확인 SHOW PROCESSLIST, SHOW FULL PROCESSLIST 오래 실행 중인 쿼리, 락 대기 세션, idle 세션 확인
3. 원인 분류 쿼리 문제, 락 경합, 리소스 부족 대응 방향 결정
4. 상세 진단 EXPLAIN, InnoDB lock 정보, status variables, replication status 실제 병목 지점 추적
5. 대응 쿼리 튜닝, 트랜잭션 범위 축소, 커넥션 풀 조정, 스케일링 장애 완화 및 재발 방지

3-2. SHOW PROCESSLIST 주요 컬럼

MySQL 공식 문서에 따르면 process list는 서버 내부 스레드가 현재 수행 중인 작업을 보여준다. SHOW PROCESSLIST는 이 정보를 확인하는 대표적인 방법 중 하나다.

컬럼 설명 실무 포인트
Id 커넥션 또는 스레드 ID 문제 세션 종료 시 KILL <Id>에 사용
User 접속한 MySQL 계정 특정 계정 또는 애플리케이션 계정 문제인지 확인
Host 접속한 클라이언트 주소 어느 애플리케이션 서버에서 온 요청인지 추적
db 현재 사용 중인 데이터베이스 특정 DB에 문제가 집중되는지 확인
Command 현재 명령 상태 Query, Sleep, Connect 등 확인
Time 현재 상태가 지속된 시간(초) 값이 크면 오래 실행 중이거나 오래 대기 중인 세션일 수 있음
State 내부 실행 상태 Locked, Sending data, Waiting for table metadata lock 등 병목 단서
Info 실행 중인 SQL 실제 문제 쿼리 확인. SHOW FULL PROCESSLIST에서 더 긴 쿼리 확인 가능

3-3. DB 모니터링 메트릭 분류

관점 지표 의미 실무 포인트
트래픽 QPS 초당 처리 쿼리 수 갑작스러운 트래픽 증가, 배치 유입, 재시도 폭증 확인
트래픽 Slow Query 수 기준 시간 이상 걸린 쿼리 수 인덱스 미사용, 실행 계획 변경, 데이터 증가 의심
DB 내부 InnoDB Buffer Pool Hit Ratio 디스크가 아니라 메모리 캐시에서 읽은 비율 낮으면 디스크 I/O 증가 가능성
DB 내부 Lock Wait 트랜잭션이 락을 기다리는 상태 장시간 트랜잭션, 락 순서 문제, metadata lock 확인
DB 내부 Replication Lag Replica가 Source 변경을 따라가지 못하는 지연 읽기 분산 구조에서 오래된 데이터 조회 가능성
리소스 활성 커넥션 수 현재 연결된 세션 수 커넥션 풀 고갈, 커넥션 누수, 장시간 점유 확인
리소스 CPU/메모리/디스크 I/O OS 또는 인프라 레벨 자원 사용량 DB 내부 문제의 결과인지, 순수 리소스 한계인지 구분

4. 사용 예시 및 코드 스니펫

4-1. 현재 실행 중인 세션 확인

SHOW PROCESSLIST;
SHOW FULL PROCESSLIST;

SHOW PROCESSLIST는 현재 연결된 세션과 실행 중인 작업을 보여준다. 쿼리문 전체가 필요하면 SHOW FULL PROCESSLIST를 사용한다.

예시:

+----+------+-----------+------+---------+------+----------------+------------------------+
| Id | User | Host      | db   | Command | Time | State          | Info                   |
+----+------+-----------+------+---------+------+----------------+------------------------+
| 12 | app  | 10.0.1.5  | shop | Query   |   45 | Locked         | UPDATE orders SET ...  |
| 13 | app  | 10.0.1.6  | shop | Sleep   |    2 |                | NULL                   |
+----+------+-----------+------+---------+------+----------------+------------------------+

볼 때의 우선순위:

  1. Time이 큰 세션을 찾는다.
  2. State가 Locked, Waiting for table metadata lock 등인지 확인한다.
  3. Info에서 어떤 SQL이 실행 중인지 확인한다.
  4. 필요하면 락 상세 정보로 넘어간다.

4-2. 락 대기 상세 확인

SHOW PROCESSLIST만으로는 누가 락을 잡고 있는지 충분히 보이지 않을 수 있다. 이때는 InnoDB 상태 또는 Performance Schema를 함께 확인한다.

SHOW ENGINE INNODB STATUS\G

MySQL 8.0 이상에서는 Performance Schema의 data_locks, data_lock_waits를 활용할 수 있다.

SELECT *
FROM performance_schema.data_lock_waits;

data_lock_waits는 어떤 트랜잭션이 보유한 락이 다른 트랜잭션의 락 요청을 막고 있는지 확인하는 데 사용된다.

4-3. QPS 확인

MySQL status variables는 SHOW [GLOBAL | SESSION] STATUS로 조회할 수 있다.

SHOW GLOBAL STATUS LIKE 'Questions';

QPS는 일정 시간 간격으로 Questions 값을 두 번 조회해 계산한다.

QPS = (두 번째 Questions 값 - 첫 번째 Questions 값) / 경과 시간(초)

예를 들어 1초 간격으로 조회했을 때 Questions가 100,000에서 100,850으로 증가했다면 대략 QPS는 850이다.

4-4. InnoDB Buffer Pool Hit Ratio 계산

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

주요 변수:

Innodb_buffer_pool_reads          -- 디스크에서 직접 읽은 횟수
Innodb_buffer_pool_read_requests  -- 전체 논리 읽기 요청 횟수

계산식:

Hit Ratio = 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)

해석:

  • Hit Ratio가 높다: 대부분의 읽기가 메모리 버퍼풀에서 처리된다.
  • Hit Ratio가 낮다: 디스크까지 읽으러 가는 비율이 높아지고, I/O 병목 가능성이 커진다.

4-5. Replication Lag 확인

MySQL 8.0.22 이후에는 SHOW SLAVE STATUS가 deprecated 되었고, SHOW REPLICA STATUS 사용이 권장된다.

SHOW REPLICA STATUS\G

구버전 또는 기존 문서에서는 다음 명령을 볼 수 있다.

SHOW SLAVE STATUS\G

확인할 대표 지표:

Seconds_Behind_Source

기존 용어 기반 문서나 구버전 출력에서는 Seconds_Behind_Master로 표기될 수 있다. 이 값이 커지면 Replica가 Source의 변경 사항을 늦게 반영하고 있다는 뜻이다.

4-6. 활성 커넥션 수 확인

SHOW STATUS LIKE 'Threads_connected';

이 값은 현재 열려 있는 연결 수를 확인하는 데 사용한다. 애플리케이션의 커넥션 풀 지표와 함께 봐야 한다.

함께 보면 좋은 애플리케이션 지표:

지표 의미
active connection 현재 사용 중인 커넥션 수
idle connection 풀 안에서 대기 중인 커넥션 수
pending connection 커넥션을 얻기 위해 대기 중인 요청 수
maximumPoolSize 커넥션 풀 최대 크기

5. 실제 사용 시 주의점 / Best Practice

5-1. SHOW PROCESSLIST는 출발점이지 최종 진단 도구가 아니다

SHOW PROCESSLIST로 오래 걸리는 세션이나 락 대기 상태를 발견할 수는 있지만, 락을 누가 잡고 있는지까지 항상 충분히 설명해주지는 않는다. 락 경합이 의심되면 SHOW ENGINE INNODB STATUS\G, performance_schema.data_locks, performance_schema.data_lock_waits를 함께 확인해야 한다.

MySQL 8.4 공식 문서에서는 SHOW PROCESSLIST 자체는 계속 제공하지만, INFORMATION_SCHEMA 기반 구현은 deprecated 되었고 Performance Schema 기반 구현 사용을 권장한다. 운영 환경에서는 performance_schema.processlist와 관련 lock wait 테이블을 함께 보는 방향이 더 안전하다.

5-2. Time이 크다고 항상 나쁜 쿼리는 아니다

Time은 현재 상태가 지속된 시간이다. Command = Sleep인 세션의 Time이 큰 경우는 쿼리가 오래 실행 중인 것이 아니라 idle connection이 오래 유지된 상황일 수 있다. 반대로 Command = Query이고 Time이 크다면 장기 실행 쿼리나 락 대기를 의심해야 한다.

5-3. 커넥션 수 증가는 원인보다 증상일 수 있다

커넥션 풀이 고갈되었다고 해서 바로 maximumPoolSize를 늘리면 안 된다. 슬로우 쿼리나 락 대기로 커넥션이 오래 반환되지 않아 풀이 마르는 경우가 많다. 먼저 어떤 쿼리나 트랜잭션이 커넥션을 오래 점유하는지 확인해야 한다.

5-4. Replication Lag는 읽기 정합성과 연결된다

읽기 트래픽을 Replica로 분산하는 구조에서는 Replication Lag가 커질수록 사용자가 오래된 데이터를 읽을 가능성이 높아진다. 최신 데이터가 중요한 조회는 Source로 라우팅하거나, lag 기준으로 라우팅 정책을 조정해야 한다.

5-5. 메트릭은 단독으로 해석하지 않는다

하나의 지표만 보고 결론을 내리면 오판하기 쉽다.

현상 잘못된 단정 더 나은 해석
CPU가 높다 서버 스펙이 부족하다 비효율 쿼리, 풀스캔, 정렬/임시 테이블 증가 가능성 확인
커넥션이 많다 커넥션 풀을 늘리면 된다 슬로우 쿼리나 락 대기로 반환이 지연되는지 확인
QPS가 높다 트래픽 증가가 원인이다 재시도 폭증, 배치 유입, 캐시 미스도 함께 확인
Slow Query가 늘었다 인덱스만 추가하면 된다 실행 계획, 데이터 분포, 락 대기, I/O 병목 함께 확인
Replication Lag가 있다 Replica만 증설하면 된다 Source 쓰기 부하, 네트워크, SQL thread 처리 지연 확인

5-6. 권한과 출력 길이를 확인한다

SHOW PROCESSLIST는 권한에 따라 볼 수 있는 thread 범위가 달라질 수 있고, FULL 없이 실행하면 Info 컬럼의 SQL 텍스트가 잘릴 수 있다. 장애 대응 중에는 SHOW FULL PROCESSLIST 또는 Performance Schema 조회를 우선 고려한다.

5-7. 면접 답변으로 압축하기

DB 장애나 성능 저하가 발생하면 먼저 모니터링 대시보드에서 CPU, 메모리, 커넥션 수, 슬로우 쿼리 수를 확인해 현상을 파악합니다. 이후 MySQL 기준으로 SHOW PROCESSLIST를 확인해 현재 실행 중인 쿼리, 오래 걸리는 세션, 락 대기 상태를 봅니다. 원인은 쿼리 문제, 락 경합, 리소스 부족으로 분류합니다. 쿼리 문제라면 slow query log와 EXPLAIN으로 튜닝하고, 락 경합이면 InnoDB lock wait 정보를 확인해 장시간 트랜잭션을 줄이며, 리소스 부족이면 커넥션 풀 조정이나 스케일링을 검토합니다. 모니터링 메트릭은 트래픽(QPS, slow query), DB 내부(Buffer Pool Hit Ratio, Replication Lag, lock wait), 리소스(CPU, 메모리, active connection) 관점으로 나눠 봅니다.

검증 메모

  • MySQL 8.4 공식 문서 기준으로 SHOW PROCESSLIST, SHOW FULL PROCESSLIST, 권한, 출력 길이, Performance Schema 권장 사항을 확인했다.
  • SHOW PROCESSLIST만으로 락 보유자까지 항상 충분히 특정할 수 없다는 제한을 유지했다.
  • replication 용어는 Source/Replica 기준으로 정리하고, 구버전 Master/Slave 표기를 병기했다.

6. 참고자료 / 공식 문서 출처

반응형
저작자표시 비영리 (새창열림)

'DB > MySQL' 카테고리의 다른 글

[MySQL] 인덱스 레인지 스캔, 랜덤 I/O, 검색엔진 도입 기준 정리  (0) 2026.07.11
[MySQL] Replication과 InnoDB Cluster, Sharding은 무엇이 다를까?  (0) 2026.07.11
[MySQL] EXPLAIN 실행계획과 파티셔닝 정리  (0) 2026.07.10
[Index] 플랫폼 내 페이지네이션 방식에 대한 개선사항 제안  (0) 2025.01.18
[MySQL] 쿼리 튜닝을 위한 인덱스 활용의 모든 것  (0) 2024.07.04

댓글

티스토리툴바