태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

Weblogic 9 - Self Tuing Thread Pool의 위력 - Part1

Enterprise Java 2007.08.08 16:45

Web Application Server(이하 WAS)에서 가장 설정하기가 까다롭고 그 효과가 예측하기 어려운 것은?

나의 견해로는 Worker Thread의 개수를 지정하는 것이다.

Worker Thread: 클라이언트의 Request를 받아서 처리 작업을 수행하는 Thread를 의미한다. Worker Thread는 클라이언트의 요청을 받아, JSP/Servlet을 구동하고 DB Operaiton을 수행하며 그 결과를 클라이언트에 보내준다.

거의 대부분의 WAS가 Thread Pool을 사용하고 있으며, Thread Pool이 지닐 수 있는 Thread의 개수를 사용자가 직접 지정하는 방법을 사용한다. 즉 내가 Thread Pool의 Thread 개수를 최대 15개로 지정하면 비록 동시에 100개의 Request가 들어온다고 해도 최대 15개만의 Thread가 Request를 처리할 수 있다.

Weblogic의 경우에는 Default Thread Pool의 Thread 개수가 15개이다. WAS 종류마다 각기 다른 종류의 알고리즘과 다른 종류의 디폴트 크기를 사용한다.

Weblogic 8의 Thread Pool 관리

아래 그림은 Weblogic 8의 Thread Pool 관리 기법을 표현한 것이다.

Weblogic 8은 [weblogic.kernel.Default]라는하나의 디폴트 Execute Queue를 가지고 있으며, 하나의 Execute Queue에하나의 Thread Pool이 매달리는 구조이다. 하나의 Thread Pool의 디폴트 Thread 개수가 15개이므로 Weblogic 8은 기본적으로 하나의 Execute Queue와 하나의 Thread Pool(Thread 개수는 15개)을 제공하는 셈이다.

아래 그림은 Weblogic8 Server의 콘솔을 통해Default Execute Queue와Thread Pool을 조회하는 화면이다.

Default Execute Queue의 이름은 항상 [weblogic.kernel.Default]라는 사실을 기억하자.

비록 거의 사용되지 않지만,Default Execute Queue외에 새로운 Execute Queue를 생성할 수 있으며 특정 Request들은 특정 Execute Queue를 사용할 수 있도록 지정할 수 있다. 가령 [회원]관련 업무는 [Default Execute Queue]를 사용하고, [주문]관련 업무는 [Execute Queue 2]를 사용할 수 있다. 이렇게 되면 두 업무간에 Worker Thread를 공유하지 않기 때문에 Thread 경쟁과 Context Switching이 줄어드는 효과를 기대할 수 있다.

사용자가 직접 Thread의 개수를 지정해줘야 하기 때문에 이러한 방식의 Worker Thread 관리 방식을 Manual 모드라고 부른다.

Manual 모드의 Thread Pool 관리가 가지는 문제점은 내 시스템에서 최적의 Thread 개수를 예측하는 것이 사실상 불가능하다는 것이다.

가령 50개의 동시 Request가 발생하는 WAS 시스템을 고려해보자.이 WAS 시스템의 CPU 개수는 2개이다. Worker Thread의 개수는 몇개가 적당하겠는가?

대답은 아마 사람들마다 다를 것이다. CPU 개수가 2개이므로 Worker Thread의 개수도 2~3개가 적당하다? 아니면 동시 Request 수가 50개이므로 Thread 개수도 50개? 아니면 그 중간 어디쯤인 15개 정도?

아래에 간단한 테스트 결과가 있다. Worker Thread수가 5개인 경우와 15개(디폴트 값이라는 것을 명심)인 경우 응답 속도를 비교해보면...

재밌게도 Worker Thread 개수가 5개인 경우 평균 응답 속도가 833ms로, 15개의 1915ms에 비해 2배 이상 빠른 것을 확인할 수 있다.

즉, Worker Thread의 개수가 지나치게(CPU 개수에 비교해) 많으면 Thread간의 경쟁과 Context Switching에 의해 오히려 성능이 저하되는 것을 확인할 수 있다.

아래 그림은 [Weblogic Tuning Guide]에서 발췌한 것으로 Thread Count를 CPU 개수와 비례해서 적절히 설정할 것을 권장하고 있다.

또 하나의 큰 문제는 사용자의 동시 Request 수가 고정적이지 않다는 것이다. 만일 하루 중 동시 Request수가 1~100 사이에서 반복적으로 변한다면 동시 Request 수를 어느 기준으로 맞추어야 할 것인가...

이런 이유때문에 Bea는 Weblogic 9에서 [Self Tuning Thread Pool]의 개념을 도입했다.

Part2에 계속 ....

신고
Trackback 0 : Comments 2
  1. 멀더엄마 2007.08.10 11:06 신고 Modify/Delete Reply

    Thread들끼리... CPU랑 메모리 등등... 자원 경쟁 발생해서 그런겨?

  2. 욱짜 2007.08.10 16:18 신고 Modify/Delete Reply

    Thread끼리 CPU를 경쟁했다는 표현이 더 맞을거 같은데...우선 Thread 자체가 리소스를 차지하기 때문에 Overhead가 있고, Thread가 CPU를 할당받을 때 Context Switching이 발생하니까 더 심해지고...

Write a comment

티스토리 툴바