어플리케이션 진단하기

1. 애플리케이션 문제 원인

애플리케이션 레벨에서 어떤 문제가 날 수 있는지, 이에 대한 원인 파악은 어떤 식으로 하는지에 대해 다뤘다. 일반적인 ‘버그’ 수준의 오류는 아예 다루지 않았다. 왜냐하면 그건 인프라 요소도 아니거니와 애초에 프로그램을 잘못짜서 발생하는 에러이기 때문이다. 이번 챕터에서 말하는 애플리케이션에서의 장애란 인프라적인 요소에 한정한다.

강의에서는 주로 애플리케이션 레벨에서의 장애는 스레드 이슈가 대부분이며 그 유형으로는 아래 세 가지가 있다고 했다.

  • BLOCKED 상태인 Thread

  • 한 Task가 너무 오래 Thread를 점유하고 있지는 않은지

  • CPU 사용률이 너무 높지는 않은지

위 세 유형 모두 결국 데드락 이 유발하는 현상들이다.

2. 애플리케이션 문제 해결

스레드 이슈는 Thread 덤프를 통해 파악한다. Thread 덤프는 아래와 같은 상황일 때 사용한다.

  • 사용자 수가 많지도 않은데, CPU 사용량이 떨어지지 않을 때

  • 특정 애플리케이션을 수행헀는데, 응답이 없을 때

Thread 덤프 생성

$ ps -ef | pgrep java
$ jstack [pid] > thread.dump
  • process 중 커널 프로세스를 제외한(-e) 프로세스들을 풀 포맷으로(-f) 보여주고 그 중 process 가 java인 것을 grep

Thread 덤프 내용

아래는 현재 서비스 인스턴스에서 덤프를 떠본 것이다.

만약 DeadLock이 있다면 아래와 같이 덤프 내용이 나온다고 한다.

아래는 Thread 스택 정보이다.

결론(강의자료 발췌)

  • Thread 이름, 식별자, 우선순위(prio), Thread가 점유하는 메모리 주소를 의미하는 Thread ID(tid), OS에서 관리하는 Thread ID (nid), Thread 상태 (NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, TERMINATED) 등의 정보를 확인할 수 있음.

  • 이 중 RUNNABLE과 BLOCKED의 경우가 문제가 될 수 있음. RUNNABLE 상태면서 지속시간이 긴 Thread가 없는지, Lock 처리가 제대로 되지 않아 문제가 발생하고 있지는 않은지 확인해봐야한다.

Last updated