태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

WebLogic 9 Self Tuning Thread Pool의 위력 - Part 2

Enterprise Java 2007.08.14 23:02

Part1에 이어...

WebLogic 9의 Self Tuning Thread Pool

WebLogic 8에서 WebLogic 9으로 업그레이드해야 하는 이유를 한가지만 든다면?

아마 SelfTuing Thread Pool을 사용하기 위해서라고 해도 무방할 것이다.

Part1에서 Manaul 모드의 Thread Pool을 적절하게 설정하는 것이 쉽지 않으며, Default Thread Pool의 크기가 항상 적절한 것은 아니다라는 것은 이미 논의한 바가 있다.

가장 적절한 Thread Pool의 크기는 얼마인가? 그에 대한 WebLogic의 대답이 바로 Self Tuning Thread Pool의 도입이다. Self Tuning Thread Pool의 개념이 아래 그림에 간략하게 표현되어 있다.

Self Tuning Thread Pool은 다음과 같은 특징을 가지고 있다.

  • Manual Thread Pool과 달리 Self Tuning Thread Pool은 Weblogic 인스턴스 별로 오직 하나의 Thread Pool(또는 하나의 Execute Queue)만을 제공한다. Manual Thread Pool 에서는 Execute Queue마다 하나의 Thread Pool을 사용하는 것과는 전혀 다른 방식이다.
  • 다중 Execute Queue의 개념이 없어진 대신에 Workload Manager라는 개념이 추가되었다. Workload Manager는 몇가지의 "룰"을 이용해 특정 Application이 Thread 자원을 얼마나 많이 사용할지를 제어한다.
  • Manual Thread Pool 모드에서는 특정 Application(Servlet)이 특정 Execute Queue를 사용하도록 지정되는 반면, Self Tuning Thread Pool 모드에서는, 특정 Application은 특정 Workload Manager에 의해 자원 분배가 이루어지도록 지정할 수 있다.
  • Weblogic은 Thread Pool에 대한 요청 정도, 즉 동시 Request 정도를 주기적으로(매뉴얼에는 2분 단위로 기술되어 있음) 확인해서Thread의 개수를 동적으로 조절한다.

아래 그림은 Weblogic 9의 관리 콘솔에서 Thread 목록을 조회하는 화면으로 Thread가 속한 Execute Queue의 이름이 "weblogic.kernel.Default (self-tuning)"인 것을 확인할 수 있다. 즉, Self Tuning Thread Pool 모드에서는 오직 하나의 Execute Queue가 존재하며 그 이름은 weblogic.kernel.Default (self-tuning)이다. 이 Execute Queue에 하나의 Thread Pool이 사용되는 구조인 셈이다.

그렇다면, Self Tuning Thread Pool의 성능은 어떨까? 즉, Weblogic은 동시 Request의 정도에 따라 Thread를 효율적으로 관리할 수 있을까? 아래에 간단한 테스트 결과가 있다.

(테스트 시나리오는 Part1에서 수행한 것과 동일하다)

Manual Thread Pool모드에서 Thread 수를 5개로 준 경우와 Self Tuning Thread Pool 모드를 사용한 경우를 비교해보면, Self Tuning Thread Pool의 평균 응답 시간이 311ms로 Manual Thread Pool의 833ms에 비해 두배 이상 뛰어난 것을 확인할 수 있다.

이런 큰 성능 차이가 나는 이유는 Thread의 상태를 나타내는 그림에서 더 자세히 알 수 있다.

그림에서 보면Self Tuning Thread Pool을 사용하는 경우에 비해 Manual Thread Pool을 사용하는 경우 빨간색이 훨씬 적은 빈도로 나타난다. 그림에서 빨간 색은 Thread Locking 상태를 의미한다. 즉 Manual Thread Pool 모드에서는 Thread 동기화를 위해 기다리는 시간이 훨씬 많다는 것을 의미한다.

위의 간단한 테스트 결과만으로도 Self Tuning Thread Pool의 장점을 이해했으리라고 믿는다.

요즈음 Enterprise Application 아키텍처의 공통된 특징이 "Self Tuning" 또는 "Self Management"이다. Weblogic의 Self Tuning Thread Pool이 대표적인 사례이고 오라클의 AWR, ADDM이 또한 업계의 대표적인 사례이다.이런 의미에서는 WAS 시스템 또한 사용자의 명시적인 설정이 필요없는 자동화된 최적화 기능이 점점 보편화될 것으로 기대한다.

테스트 과정에서 발견된 Self Tuning Thread Pool의 문제

그렇다면 Self Tuning Thread Pool이 언제나 최적의 성능을 발휘하는가?

그랬으면 좋겠지만, 다양한 테스트를 수행해 본 결과 바람직하지 못한 결과를 낳는 경우가 종종 있다는 것이 발견되었다. 아래 그림은 Self Tuning Thread Pool 환경에서 부하 생성 툴인 JMeter를 이용해 1~ 50 까지 동시 유저를 증가시키면서 부하를 준 사례이다.

흥미롭게도, Thread의 개수가 계단식으로 점점 증가하다가 어느 순간 Thread 폭주로 시스템 성능이 극단적으로 저하되는 현상이 발생하는 것이 목격되었다.

이것이 Self Tuning Thread Pool의 의도된 기능인지, 아니면 버그에 가까운 것인지 확인할 수는 없지만, 확실히 바람직한 결과는 아니다.

이런 상황에 대비해 Weblogic은 이전 스타일의 Thread Pool, 즉 Manual 모드의 Thread Pool 관리 기법을 사용할 수 있는 옵션을 추가했다.

Weblogic의 Main Configuration File인 config.xml에 다음과 같이 "use81-style-execute-queues" 옵션을 true로 바꾸어주면 된다.


AdminServer

true


Epilogue

지금까지 Weblogic 9이 제공하는 Self Tuning Thread Pool의 장단점에 대해 상세하게 알아보았다.

Weblogic 9이 Weblogic 8에 비해 상당히 많은 장점을 제공함에도 불구하고(Self Tuning Thread Pool이 대표적인 사례) 실제 채택 사례는 그리 많지 않은 것으로 알려져 있다.

이것은 아마 제품 자체의 문제라기보다 시장의 환경이나 출시 시점의 문제로 해석된다.

이런 논의를 계기로 Weblogic 9의 장점에 대한 기술적인 공유들이 이루어졌으면 하는 바램이다.

신고
tags : ,
Trackback 0 : Comment 0

Write a comment

티스토리 툴바