Thread Dump Pattern Type을 통한 트러블슈팅

Thread Dump 관련 글을 찾다가 마침 Dzone에서 좋은 포스팅
(“How to Analyze Java Thread Dumps“)을 읽고 그중에서
Thread Dump Pattern를 통한 트러블 슈팅” 부분만을 발췌해서 설명 드리고자 합니다.
시스템이 갑자기 느려지거나, CPU/Memory가 비정상일 경우 “트러블슈팅“를 해야 합니다.
느려지는 이유“는 다양하겠지만, 일단 “현재 구동중인 시스템”에 대한 “Health Check”
필요합니다.

대부분의 시스템들은 1Process, Multi Thread로 구성이 되어 있습니다.
특히 제일 중요한 것은 “내부 Thread“에 대한 분석 입니다.

하지만 “Thread“에 대한 “분석”은 쉽지가 않습니다. “Thread” 덤프를 떠서 분석하지만
또한 전체적으로 “원인”을 찾기가 어렵습니다.

그래서 “Thread에서 발생하는 유형을 그래픽” 통해서 “정의“한것을 “Thread Dump Pattern
이라고 합니다.

여기서는 “JVM“를 실시간으로 분석해주는 툴인 “VisualVM“에서 제공하는 그래프 이며,
기타 다른 언어로 개발된 시스템도 유사한 툴들이 있지 않을까 하며
“언어 상관없이” 보셔도 도움이 되지 않을까 합니다.

※ VisualVM에 대해서 알고 싶은 분은 “Eclipse에서 VisualVM 사용하기“를 참고 하시기 바랍니다.

(1) Unable to Obtain a Lock (BLOCKED)

대부분 동일한 “Task”를 수행하는 “Thread”는 매번 생성 하는 것이 아니고 “ThreadPool
에 생성 후 재사용을 합니다.
해당 “패턴“은 “특정 Thread가 lock를 획득후에 자원을 release를 하지 않은 경우” 입니다.

pool-0-thread-1의 상태는 Runnable이면서 lock를 획득한 상태 입니다.
반면 “pool-0-thread-2, pool-0thread-3의 상태는 Runnable이면서 lock를 획득하지 못한
상태 입니다.” 이러한 상태를 “BLOCKED” 상태라고 합니다.
즉 아래와 같은 그래프의 패턴을 보면

특정 Thread가 오랫동안 자원을 Locking하고 Release가 되고 있지 않은 상황 입니다.   즉 리소스에 대한 Lock Release를 의심 하면서 트러블 슈팅을 해야 합니다.

이미지 4

(2) Deadlock Status

Thread“에서 “Deadlock” 이란 “서로 사용하고자 하는 자원을 서로 locking”  한 상태 입니다.
좀더 쉽계 예를 들면 “두 명의 여자가 서로 머리채를 잡고 놓치 않은 상황”에 비유 할수 있습니다.
둘중 한명이 놓아야 하는데 고집이 쎄서 절대 안놓아서 싸움이 끝이 나지 않은” 경우라 할 수
있습니다.

아래 그림을 보면 “TEST-1“, “TEST-2“, “TEST-3” 3개의 “Thread“가 처음에는 “Runnable
상태였다가 “Monitor (Blocked 상태)”가 지속되고 있습니다.

즉 “TEST-1은 TEST-2가 사용할 자원을 locking”, “TEST-2는 TEST-3가 사용할 자원을 locking”, “TEST-3은 TEST1이 사용할 자원을 locking” 하고 있는 상태 입니다. 이런 경우 “DeadLock” 상태를 의심 하면서 트러블 슈팅을 해야 합니다.

이미지 5
(3) Continuously Waiting to Receive Messages from a Remote Server

“Remote Server” 로 “요청”을 보내고 “응답”을 받을 때까지 “Thread는 Runnable” 상태를
유지 합니다. 만약 “Socket Thread”가 지속적으로 “Runnable” 상태가 유지되면 상태를
의심해야 합니다.

만약 아래와 같은 그래프가 지속 된다면, Client에서 Remote 서버 접속 정보를
확인을 하거나 Remote 서버의 응답쪽을 의심 해야 합니다.

이미지 6

(4) Wating

LinkedBlockingQueue” 같은 로컬 “Queue” 또는 “외부 Queue“를 사용할 때
Thread는 “Wating 상태“로 대기 합니다.  주로 “join” 메서드
(하나의 쓰레드가 완료될동안 기다리는)를 통해서 “wating” 됩니다.

만약 해당 쓰레드가 “wating” 상태로 계속 지속될 경우 ‘queue’에 데이터를
저장 시켜주는 thread 또는 외부 queue 상태를 확인해야 합니다.

이미지 7

(5) Thread Resources Cannot be Organized Normally

“Thread Pool”에 등록된 “Thread”들이 “Runnable” 상태가 유지되지 않고, 모든 Thread가
“Waiting”를 유지 할경우

더 이상 Thread가 해당 프로세스에서 실행할  Task값 없는지 의심을 해야 합니다. 이럴 경우
괜히 시스템 리소스가 낭비 될수 있습니다. 반드시 확인 후 Thread를 Terminate 되도록
처리가 필요 합니다.

이미지 8

지금까지 “Thread Dump Pattern Type”에 대해서 알아 봤습니다. 혹시 본 포스팅이
조금이나 “Thread 트러블 슈팅”에 도움이 되었으면 하고, 이외에
좋은 내용들이 많으니 아래의 포스팅을 꼭 한번씩 읽어 봤으면 합니다.

출처 : http://architects.dzone.com/articles/how-analyze-java-thread-dumps

Published by: beyondj2ee

Past SI AA, now I am pikicast developer in yellow mobile and daddy, Java, Spring, OpenSource, Application Architect :) Java Application Architect. mail : beyondj2ee@gmail.com twitter : twitter.com/beyondj2ee facebook : https:www.facebook.com/beyondj2ee blog: http:beyondj2ee.wordpress.com

Categories Architecture댓글 한 개

One thought on “Thread Dump Pattern Type을 통한 트러블슈팅”

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중