14장. 모니터링과 트러블슈팅 — "느려요"를 지표로 번역하기

"DB가 느려요"는 증상이지 진단이 아닙니다. pg_stat_* 뷰와 로그만으로 대부분의 장애를 좁혀 들어가는, 새벽 2시에도 통하는 사고 순서를 몸에 새깁니다.

14.1 장애의 첫 5분 — 진단 순서를 몸에 새겨라

장애 대응에서 가장 비싼 것은 "어디부터 볼까" 고민하는 시간입니다. 현업 DBA는 항상 같은 순서로 봅니다: 값싸고 흔한 원인부터, 비싸고 드문 원인 순으로.

-- 5단계 진단 쿼리 묶음 (즐겨찾기 필수)
-- ① 연결 수
SELECT count(*), state FROM pg_stat_activity GROUP BY state;

-- ③ 긴 트랜잭션
SELECT pid, state, now()-xact_start AS age, query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL AND now()-xact_start > interval '1 minute'
ORDER BY age DESC;

-- ④ 무거운 쿼리 TOP 10
SELECT query, calls, round(mean_exec_time::numeric, 2) AS mean_ms
FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;

14.2 Lock 체인 — 한 명이 모두를 세운다

Lock 장애의 전형적인 그림: 누군가 트랜잭션을 열어 ALTER TABLE(또는 커밋을 잊은 UPDATE)을 잡고 있고, 그 뒤로 수백 개의 세션이 기차처럼 줄줄이 기다립니다. 관건은 대기자가 아니라 맨 앞의 blocker를 찾는 것입니다.

-- 누가 누구를 막고 있는가 (v9.6+)
SELECT blocked.pid  AS blocked_pid,  blocked.query  AS blocked_query,
       blocking.pid AS blocking_pid, blocking.state AS blocking_state,
       blocking.query AS blocking_query
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking
  ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
WHERE blocked.wait_event_type = 'Lock';

-- 재발 방지: 잊힌 트랜잭션 자동 정리
-- postgresql.conf: idle_in_transaction_session_timeout = '10min'

14.3 슬로우 쿼리 추적 — 증상→증거→수정→검증 루프

"어제부터 이 화면이 느려요"를 해결하는 표준 루프입니다. 핵심은 감(感)이 아니라 재현 가능한 증거로 움직이는 것.

14.4 pg_stat_* 뷰 지도 — 어디서 무엇을 보나

자주 보는 건강 지표 몇 가지의 해석 기준:

• 캐시 히트율 (blks_hit / (blks_hit+blks_read)): 보통 99% 이상이 정상. 95% 아래면 shared_buffers 부족 또는 비효율적 시퀀셜 스캔 의심.
• state = 'idle in transaction': 트랜잭션을 열어놓고 노는 세션 — Bloat·Lock의 원흉.
• temp_files/temp_bytes 증가: work_mem 부족으로 디스크 정렬·해시 중.
• checkpoints_req 비중 30% 이상: max_wal_size 부족 (9장).

-- DB 건강 요약 한 방 쿼리
SELECT datname, numbackends, xact_commit, deadlocks,
       round(100.0 * blks_hit / nullif(blks_hit + blks_read, 0), 2) AS cache_hit_pct,
       temp_files, temp_bytes
FROM pg_stat_database
WHERE datname NOT IN ('template0','template1');

14.5 알림 임계값 — 시작점 치트시트

✍️ 이해도 체크