[WEB/WAS] Tomcat 장애시 제일먼저 확인 하는것

Tomcat 장애 났을 때 내가 먼저 보는것들

---

 

Tomcat 장애가 났다는 연락을 받으면

보통 log를 먼저 확인들 하실텐데

저는 일단 tomcat이 올라간 서버부터 확인합니다.

 

제일 먼저 CPU 상태 확인 (top)

서버에 접속하면 가장 먼저 top 명령어를 실행합니다.

top 명령어

 

top

여기서 보는 포인트는 단순합니다.

 

CPU 사용률이 비정상적으로 높은가?

특정 프로세스(Java)가 CPU를 거의 독점하고 있는가?

 

만약 CPU 사용량이 계속 치솟고 있다면,
이건 대부분 무한 루프, 특정 로직 폭주, 쓰레드 문제입니다.

이 경우 바로 해야 할 일은

 

쓰레드 덤프(thread dump) 를 뜨는 겁니다.

kill -3 tomcat PID

kill -3 127688

 

쓰레드 덤프

 

CPU를 많이 잡아먹는 PID를 확인한 뒤,
덤프를 남겨 두는 게 중요합니다.

덤프는 tomcat log 디렉토리에 catalina.out 에 기록됩니다.

장애가 났다고 바로 재기동 해버리면 

나중에 같은 장애가 나올 가능성이 높습니다.

쓰레드 덤프를 확인하는게 좋습니다.

 

ps -mo pid,lwp,pcpu,start_time,time -p PID

 

ps -mo pid,lwp,pcpu,start_time,time -p 127688

 

ps 명령어로 어떤 pid가 cpu를 많이 사용하는지 확인후 

쓰레드덤프확인하는법

 

프로그래머 계산기에 cpu가 비정상적으로 많이사용하는 pid를 입력하면

HEX 헥사코드 쓰레드덤프의 nid로 나오게 됩니다. (저는 대충 쓰레드 덤프 뜬거라 안나왔습니다.)

원인을 알수가 있습니다.

 

CPU가 정상이라면?
로그로 넘어갑니다.

---

로그 확인 

 

 

 

CPU가 정상인데 서비스가 안 된다면
로그에 답이 있습니다.

 

$TOMCAT_HOME/logs/catalina.out

 

여기서 자주 만나는 메시지는 거의 정해져 있습니다.

-OutOfMemoryError

-Java heap space

-GC overhead limit exceeded

tomcat log

 

위 캡쳐화면은 제가 일부러 발생시킨 outOfMemory 오류입니다.

catalina.out 를 열어서 확인해보면 그냥 뭐가 문제인지 

바로 직관적으로 확인할수 있습니다.

날짜, 시간 등으로 이때 어떤 어플리케이션이 돌았는지 확인해보면 

원인을 쉽게 찾을수 있습니다.

 

이런 메시지가 보이면
Heap 메모리가 부족하거나 메모리 누수 가능성이 큽니다.

이 경우에는

 

JVM 옵션 확인

Heap 사이즈 확인 

Heap dump 확인

최근 배포 여부

 

---

 

메모리 상태 확인

free -h

그리고 Tomcat 프로세스가
실제로 얼마나 메모리를 쓰고 있는지도 확인합니다.

 

free -h

total 12 기가인데 

used 사용중은 5.3 기가네요 

안정적입니다. 

 

토탈의 90% 사용중이면 메모리 부분도 확인이 필요합니다.

 

---

힙메모리

 

Heap은 충분한데도 OOM이 난다면
Metaspace 영역 문제일 가능성도 있습니다.

metasapce 와 perm 영역은 같은 곳입니다.

jdk1.8 로 올라오면서 perm -> metaspace로 변경됐다고 보시면됩니다.

 

이런경우는 heap dump 를 생성해서 확인이 필요합니다.

 

힙덤프 수동생성
jmap -dump:format=b,file=heapdump.hprof {Runtime PID}

 

 

heap 사이즈 조정 및 톰켓 튜닝은 아래 링크 참고

2025.12.30 - [WEB,WAS] - [WEB/WAS] Tomcat jvm option, 힙메모리 , java option

[WEB/WAS] Tomcat jvm option, 힙메모리 , java option

 

---

재기동

장애상황을 다 파악했으면 재기동 하면됩니다.

재기동하고 꾸준히 모니터링 하면 됩니다.

 

만약 장애상황을 파악 못했는데.. 한시가 급하다 하면 그냥 재기동 하는 방법도 있지만

이방법은 진짜 최후의 수단입니다. 

쓰레드 덤프, 힙덤프, 로그들 확보 후 재기동 하고 추후에 원인을 찾아야 합니다.

 

 

CPU 상태
로그
메모리

 

이 3가지만 확인해도 장애의 전반적인 오류를 확인 가능할수 있습니다.