장애 대응 (jstack·jmap·OOM killer·FD)

5. 자주 하는 실수 (Tip)

❌ 실수 1: 덤프 없이 재시작한다

증거가 사라져 다음 주에 같은 장애를 처음부터 겪습니다. ✅ 스레드 덤프 3장과 히스토그램을 남긴 뒤 재시작합니다. 4.1 스크립트면 30초입니다.

❌ 실수 2: 스레드 덤프를 한 장만 보고 판단한다

한 장은 순간이라 우연히 잡힌 스택일 수 있습니다. ✅ 5초 간격 세 장에서 같은 스레드가 같은 스택이면 그것이 범인입니다.

❌ 실수 3: jmap -histo 에 :live 를 빼고 본다

GC 안 된 쓰레기까지 세어 누수처럼 보입니다. ✅ :live 로 살아 있는 객체만 셉니다. 단 Full GC 가 한 번 돌아 잠깐 멈춥니다.

❌ 실수 4: 운영 서버에서 힙 덤프를 아무 때나 찍는다

수 GB 를 쓰는 동안 앱이 멈추고 디스크가 찹니다. ✅ 히스토그램으로 먼저 보고, 덤프는 디스크 여유를 확인한 뒤 트래픽이 적을 때 찍습니다.

❌ 실수 5: 다른 사용자로 jstack 을 실행한다

Unable to open socket file 로 붙지 않습니다. ✅ sudo -u myapp jstack PID 처럼 JVM 과 같은 계정으로 실행합니다.

❌ 실수 6: JVM OOM 과 커널 OOM 을 혼동한다

로그에 OutOfMemoryError 가 없는데 -Xmx 를 늘리면 커널 OOM 이 더 자주 납니다. ✅ dmesg 와 종료 코드 137 을 먼저 확인합니다. 커널 OOM 이면 -Xmx 를 줄입니다.

❌ 실수 7: top 의 %CPU 가 100 을 넘는 것을 오류로 본다

코어가 8개면 800% 까지 정상입니다. ✅ top -H 로 스레드 단위로 내려가 한 스레드가 100% 인지 봅니다.

❌ 실수 8: FD 한도를 ulimit -n 으로만 확인한다

셸의 한도와 서비스 프로세스의 한도는 다릅니다. ✅ /proc/PID/limits 로 그 프로세스의 실제 한도를 보고 LimitNOFILE 로 올립니다.

❌ 실수 9: 덤프 파일을 서버에 방치한다

힙 덤프 하나가 힙 크기와 같아 몇 개면 디스크가 찹니다. ✅ 분석용은 PC 로 내려받고 서버 것은 cron 으로 지웁니다. 06 레슨 cleanup.cron 의 .hprof 줄이 그것입니다.

❌ 실수 10: 장애 후 기록을 남기지 않는다

같은 팀이 같은 장애를 반복해서 겪습니다. ✅ 시각, 증상, 증거 경로, 원인, 조치 다섯 줄이면 됩니다. 복구 당일에 씁니다.