Thread Dump

Thread Dump 는

매번 난공불락의 개념이였고

- 웹문서의 Thread Dump 파일 로그를 보고 도대체 저 로그를 보고 어떻게 장애를 해결하는 것인지 이해할 수 가 없었다.

매번 알기를 미뤄뒀다.

- 라이브 장애가 발생 했을 때 thread dump 를 알아보고 추출하는 것보다 catalina.out을 보고 원인파악을 해서 해결 해왔다.

안좋은 기억도 있다.

후임이 담당하는 웹서버중 한 대가 죽지도 살지도 않는 상태여서 후임이 확인 중에 있었다.

예전에 동일한 경험이 있어 좀비프로세스가 있는지 확인 하고 이를 강제 종료 후 다시 웹서버를 시작하도록 조언했고

장애는 빠르게 해결 했으나 원인은 알 수 없는 상태 였다.

이에 대해 다른 팀원이 오더니 후임에게 어떻게 해결 했는지 물어보고 왜 Thread Dump를 추출하지 않았냐고 야단이였다.

마치 나에게 하는 이야기 같아 정말 낯이 뜨거웠다.

JVM에 대해 공부하는 중에 Thread Dump와 연관이 있어 다시 들여다봤다.

- 추출 방법

java pid 를 추출 후 jstack 을 이용해 파일로 저장한다.

혹은 VisualVM 의 thread 탭에서 추출한다.

- 분석 방법

항상 포기 했던 구간이다.

Thread Dump 로그를 보고 난 후 항상 느껴왔던 점은 이 로그를 어떻게 장애 분석을 하라는 것인지 난감했다.

내가 내린 결론은 Thread Dump 로그의 BLOCKED / WAITING / TIMED_WAITING 의 갯수와 원인을 확인하는 것이라고 본다.

회사의 보안 정책 상의 이유로 GUI 분석 툴(VisualVM) 이나 Threrad Daump 분석 웹서비스(https://fastthread.io/index.jsp) 를

사용이 어려운 경우가 있다.

이럴 경우 상태값만 알고 있다면 VI 에서 Find를 사용하거나 스크립트나 툴을 만들어 장애 포인트를 확인 할 수 있다.

- 라이브 서비스에서 어떻게 활용 해야 하는가?

(지금은 현업에 있지 않기 때문에 적용해보진 않았지만 어떻게 할 수 있을까 생각해봤다.)

웹서비스의 장애 해결을 위해 웹 서비스 로그 확인이 우선순위가 가장 높다고 생각한다.

그 다음 순위가 Thread Dump 분석이라고 본다.

두 개발자가 분업해서 한명은 ThreadDump를 추출/분석하고 한명은 웹서비스 로그를 확인하는 것이 효율적이겠지만

혼자 해야 하는 경우 Thread Dump 를 파일을 먼저 추출 걸어놓고

catalina.out 을 확인하고 장애가 해결된다면 이후 Thread Dump를 확인 하는 습관을 들이면

한단계 더 높은 곳에 도달 할 수 있을까 생각해본다.

ren+gin+eer