WebLogic Server Native I/O 이해
1 Java muxer와 Native Muxer.
WebLogic Server는 Request / Response를 처리하기 위해 Muxer라 불리는 내부 모듈을 사용한다.
이러한 Muxer들은 socket reader구현 방식에 따라 Java Muxer(JDK에서 제공)와
Native Muxer(BEA WLS에서 제공)의 두 가지 종류가 있다.
Pure Java Muxer는 Socket으로부터 데이터를 읽기 위해서 Pure Java를 사용한다.
하나의 socket으로부터 data를 읽는 시점에는 해당 socket이 block상태가 된다.
이러한 특성으로 인해 많은 수의 socket들이 있거나 요청이 빈번한 경우 얼마만큼의 reader socket을 생성 해야 할지 측정할 수 없다. 이 때문에 실제 server side에서 bottleneck이 발생할 수도 있다.
Native Muxer들은 Socket으로부터 데이터를 읽기 위한 기능을 제공하기 위해 OS 플랫폼 별로
서로 다른 native binary를 사용하며, 모든 플랫폼에서의 Muxer의 내부 알고리즘은 동일하다.
Native Muxer는 non-blocking thread model를 사용하기 때문에 pure java thread model보다 더 좋은
성능을 제공한다.
WLS에서 "native muxer"를 사용하는 경우, 해당 Server는 요청하는 request를 처리하기 위한 고정된
개수의 muxer thread를 생성한다.
알고리즘 상 Muxer Thread의 수는 CPU수에 맞게 생성하도록 되어 있다.
BEA는 해당 Server에서 사용하기 위한 적절한 muxer를 자동적으로 생성하기 위해, "Enable Native IO" 옵션을 사용할 것을 권고한다.
pure java를 implementation한 socket reader thread들은 확실하고 portable한 방법의 일대일 통신 방법을 제공하지만, WebLogic Server안에서 대량의 소켓을 사용시 best performance를 제공하지는 못한다.
pure java socket reader thread들은 socket안에 읽을 데이터의 유무와 관계없이 open된 모든 socket을 poll해야만 한다. 즉, socket reader thread들은 socket에 읽을 데이터가 없어도 항상 socket들을 polling하기 위해 busy한 상태가 된다.
한 서버 내에서 socket reader thread들 보다 더 많은 socket이 open되었을 때 이러한 문제는
확대 된다. 이런 경우 reader thread들은 하나 이상의 open socket을 poll해야만 한다.
그 socket이 inactive상태가 된다면 reader thread는 timeout 상태를 결정 하기 위해
기다려야 하고 timeout 후에 그 thread는 waiting하고 있는 다른 socket으로 이동한다.
open된 socket의 수가 사용 가능한 socket reader의 수를 넘어서면 사용 가능한 reader thread가
active socket들을 poll할 때 까지 그 socket들은 service를 할 수 없게 될 것이다.
최상의 socket performance를 내기 위해서는 항상 OS에서 수행되는 native socket reader 사용 하도록 구성하여야 한다. Native socket reader들은 socket이 데이터를 읽기 위해 훨씬 더 효율적인 기법을 제공 한다. Native reader socket thread들은 inactive socket들에 대해 poll할 필요가 없다.
Socket이 active상태로 변경되었을 때 즉각적으로 반응되어 active된 socket들만 서비스 하게 된다.
그림 1. pure java socket reader
그림 2. native socket reader
2 Thread 개수 산정 및 병목 구간의 파악
2.1 한 Instance에서 사용 할 수 있는 thread 개수 산정 문제
WebLogic9.x에서 thread는 max 400개까지 가능하며, 한 인스턴스의 적정 thread 개수는 실 업무 어플리케이션에 따라서 많이 다르게 된다.
실 업무 어플리케이션이 cpu 또는 memory등 어느 resource를 많이 쓰는지 뒷 단의 연계하는 DB 수행 로직이 빠른지 느린지 등등의 여러 가지 요소에 의해서 thread 사용이 다르게 된다.
이에 따라서, 실제 업무 어플리케이션에 맞는 적정 thread 수, Data Source 수, EJB Instance수, DB Query 튜닝 및 각종 연관 시스템을 고려하여 튜닝을 통하여 WebLogic의 각종 resource들은 실제 업무 어플리케이션에 맞는 설정 값을 갖게 된다.
J2EE Application의 병목구간을 확인하기 위해서는 그 문제를 발견하고 툴과 경험을 이용해서 문제의 원인을 발견하고 제거 해야 한다.
JVM이나 Web Server, Network 등에 대해서는 별도의 경험과 Log 분석 등을 통해 알아 내야하고 DB에 의한 slow down이나 hang up현상은 DB 자체의 분석이 필요하다.
대부분의 WAS또는 User Application의 slow down이나 hang up은 Thread dump를 통한 분석을 통해서 발견 및 해결을 할 수 있다.