제3장 JEUS 서버 제어 및 모니터링
이전   다음

제3장 JEUS 서버 제어 및 모니터링

내용 목차

3.1. 서버 제어 및 모니터링
3.1.1. Managed Server의 Lifecycle
3.1.2. Managed Server 시작
3.1.3. Managed Server 종료
3.1.4. Managed Server 일시 정지
3.1.5. Managed Server 복귀
3.2. 서버 엔진 설정
3.2.1. 엔진 사용 여부 설정
3.2.2. 엔진 초기화 시점 설정
3.3. Thread 모니터링 및 제어
3.3.1. Thread 모니터링
3.3.2. Thread 제어
3.4. 메모리 모니터링 및 제어
3.4.1. 메모리 모니터링
3.4.2. 메모리 사용량에 따른 제어

본 장에서는 JEUS 서버를 제어하고 모니터링하는 방법을 설명한다. 여기에서 설명하는 서버는 MS에 한정되며, 관리를 담당하는 MASTER가 정상 동작 중이라고 가정한다. 설명한 내용은 WebAdmin을 통해서도 가능하므로 COMMAND Line에 익숙하지 않다면 WebAdmin을 사용할 것을 권장한다.

참고

서버 실행 스크립트와 콘솔 툴에 관한 자세한 사항은 “JEUS Reference 안내서”의 “제3장 JEUS 서버 기동 및 종료”과 “JEUS Reference 안내서”의 “4.2.2. Local 명령어”를 참고한다.

3.1. 서버 제어 및 모니터링

본 절에서는 서버 제어 및 모니터링에 대해서 설명한다.

MS는 다음과 같은 동작 상태를 갖는다. MS의 상태는 MASTER 또는 사용자에 의해 변경될 수 있다.

[그림 3.1] MS의 상태 전이도

MS의 상태 전이도


구분설명
SHUTDOWN서버가 아직 부팅되지 않았거나 정상적으로 종료된 상태이다.
STARTING

서버가 시작 명령을 받고 부팅 중인 상태이다.

서버는 실행 스크립트 또는 호스트 매니저에 의해서 시작될 수 있다. 이 단계에서 서버는 엔진(WEB, EJB, JMS) 생성, JEUS 서비스(보안, SCF 등) 실행, 그리고 등록된 애플리케이션 deploy 등의 작업을 수행한다.

STADNBY서버에서 실행되어야 하는 JEUS 서비스가 시작된 상태이다. 만약 서버가 이 상태로 부팅을 완료했다면 서버에 등록된 애플리케이션이 deploy를 실패한 것이다. 서버에 등록된 애플리케이션 distribute가 실패한 경우에도 서버는 STANDBY 상태에 머무르게 된다.
RUNNING서버가 부팅이 완료되고 등록된 애플리케이션들도 정상적으로 서비스되는 상태이다. 만약 STANDBY 상태의 서버를 -force 옵션을 통해 시작시킨 상황이라면 서버에 등록된 모든 애플리케이션이 서비스되지 못하는 상태일 수도 있다.
SUSPENDING

RUNNING 상태인 서버가 suspend 명령을 수행 중인 상태이다.

이 단계에서는 서버에서 서비스되고 있는 모든 애플리케이션의 서비스를 중단된다. 단, 애플리케이션 서비스를 위한 Listener는 내리지 않는다.

SUSPENDED서버에 deploy된 애플리케이션을 모두 중지시켜 서비스가 되지 않도록 멈춘 상태이다. 단, 애플리케이션 서비스를 위한 Listener는 내리지 않고 그대로 있다.
RESUMING

SUSPENDED 상태의 서버가 resume 명령을 수행 중인 상태이다.

이 상태에서는 중지된 모든 애플리케이션을 다시 시작시켜 서비스 가능한 상태로 만든다. resume 명령이 성공적으로 수행되면 서버는 RUNNING 상태가 된다.

SHUTTING_DOWN

서버가 종료되고 있는 상태이다. deploy된 애플리케이션을 undeploy하고 부팅할 때 실행시켰던 JEUS 서비스들을 모두 종료시킨다.

서버를 종료할 때 적절한 타임아웃을 설정해서 서비스 중인 요청이 처리될 수 있도록 보장할 수 있다. 이를 Graceful Shutdown이라고 한다.

참고

1. MASTER에서 관리하는 MS의 Lifecycle에 대한 자세한 내용은 “JEUS Domain 안내서”의 “4.4. 서버 Life Cycle 상태 확인”을 참고한다.

2. Graceful Shutdown에 대한 자세한 내용은 “3.1.3. Managed Server 종료”를 참고한다.

MASTER와 MS는 기본적으로 Launcher를 통해 기동된다. 스크립트나 MASTER를 통한 서버 실행 명령은 Launcher를 실행하게 되고, Launcher에서는 서버를 띄우기 위한 준비작업과 실제 서버를 기동하는 작업을 수행한다. Launcher에 대한 자세한 내용은 “1.4. Launcher”를 참고한다. 콘솔 툴이나 WebAdmin으로 MASTER를 통해 서버를 시작하는 방법은 “JEUS Domain 안내서”의 “4.2.2. Managed Server(MS) 시작”을 참고한다. 본 절에서는 스크립트로 서버를 실행하는 예제만 설명한다.

예제

Launcher에서는 실제 서버의 JVM을 기동하고 해당 서버의 부팅이 완료된 것을 확인한 뒤에 종료된다.

다음과 같이 Launcher 로그를 통해 서버가 정상적으로 기동되었는지 확인할 수 있다.

JEUS_HOME/bin$ ./startManagedServer -domain domain1 -server server1 -u jeus -p jeus -masterurl localhost:9736
***************************************************************
  - JEUS Home         : /home/test/jeus
  - Java Vendor       : Sun                         
  - Added Java Option :    
***************************************************************
...
[2022.07.14 22:35:04][2] [launcher-1] [SERVER-0201] Successfully connected to the JEUS Master Server(localhost:9736).
[2022.07.14 22:35:04][2] [launcher-1] [Launcher-0058] All local configurations are up-to-date.
...
[2022.07.14 22:35:07][0] [server1-1] [SERVER-0242] Successfully started the server.
[2022.07.14 22:35:07][2] [server1-1] [SERVER-0248] The JEUS server is RUNNING.
[2022.07.14 22:35:07][2] [launcher-22] [Launcher-0034] The server[server1] initialization completed successfully[pid : 81719].
[2022.07.14 22:35:07][0] [launcher-1] [Launcher-0040] Successfully started the server[server1]. The server state is now RUNNING.
JEUS_HOME/bin$

MS가 자신이 갖고 있는 애플리케이션 파일을 부팅 중 deploy할 때 문제가 발생할 경우 STANDBY 상태에 머무를 수 있다. MS가 부팅 중 deploy하는 애플리케이션은 보통 한 번 이상 정상적으로 서비스되던 것이다. 그렇기 때문에 이러한 문제가 발생했다면 이전과 비교하여 파일이 잘못 변경되었을 가능성이 크다.

특정 MS에서 JEUS 내부 디렉터리인 .workspace에 존재하는 애플리케이션의 xml 태그를 잘못 수정할 경우 아래와 같이 STANDBY 상태에 머무를 수 있다. 도메인 구조의 deploy에 대한 자세한 내용은 “JEUS Applications & Deployment 안내서”의 “제1장 도메인 환경에서 애플리케이션 관리”를 참고한다.

주의

애플리케이션의 관리는 MASTER를 통해서 하는 것이 기본 정책이므로, MS의 .workspace 디렉터리에 직접 접근하여 작업하지 않도록 한다.

JEUS_HOME/bin$ ./startManagedServer -domain domain1 -server server1 -u jeus -p jeus -masterurl localhost:9736
...
[2022.07.14 23:20:07][2] [launcher-1] [SERVER-0201] Successfully connected to the JEUS Master Server(localhost:9736).
...
[2022.07.14 23:20:09][2] [server1-1] [Deploy-0095] Distributing the application[healthcheck].
java.lang.RuntimeException: [was class com.ctc.wstx.exc.WstxParsingException] Unexpected close tag </urlpattern>; expected </url-pattern>.
[2022.07.14 23:20:09][0] [server1-1] [SERVER-0522] An exception occurred while processing [SERVER_HOME/.workspace/deployed/healthcheck/1657613257716/healthcheck_war___/WEB-INF/web.xml].
<<__Exception__>>
...
<<__!Exception__>>
[2022.07.14 23:20:09][2] [server1-1] [SERVER-0248] The JEUS server is STANDBY.
[2022.07.14 23:20:09][0] [server1-1] [SERVER-0250] Starting server (server1) failed. Staying in STANDBY.
[2022.07.14 23:20:09][2] [server1-1] [SERVER-0401] The elapsed time to start: 1775ms.
[2022.07.14 23:20:09][2] [launcher-22] [Launcher-0034] The server[server1] initialization completed successfully[pid : 86118].
[2022.07.14 23:20:09][0] [launcher-1] [Launcher-0042] Completed starting the server but the server state is still STANDBY.
JEUS_HOME/bin$

이 경우 다음과 같이 server-info 명령어를 통해 MS가 STANDBY 상태임을 확인할 수 있다.

[MASTER]domain1.adminServer>server-info
Information about Domain (domain1)
================================================================================
+--------+---------+-----+-----+-----+-----------+--------+-----------+--------+
| Server |  Status |Node | PID | Clu |   Latest  |  Need  |   Listen  |Running |
|        |         |Name |     |ster |Start Time |   to   |   Ports   |Engines |
|        |         |     |     |     |     /     |Restart |           |        |
|        |         |     |     |     | Shutdown  |        |           |        |
|        |         |     |     |     |   Time    |        |           |        |
+--------+---------+-----+-----+-----+-----------+--------+-----------+--------+
| adminS | RUNNING | nod | 814 | N/A |2022-07-14 | false  | base-0.0. | jms,   |
|erver   |(00:52:3 |e1   |82   |     |(목) 오후   |        |0.0:9736   |web, ejb|
|(*)     |7)       |     |     |     |10:34:03   |        | http-serv |        |
|        |         |     |     |     |KST        |        |er-0.0.0.0 |        |
|        |         |     |     |     |           |        |:8088      |        |
+--------+---------+-----+-----+-----+-----------+--------+-----------+--------+
| server1| STANDBY | N/A | 861 | N/A |2022-07-14 | false  | base-0.0. | jms,   |
|        |(00:06:3 |     |18   |     |(목) 오후   |        |0.0:9836   |web, ejb|
|        |2)       |     |     |     |11:20:08   |        | http-serv |        |
|        |         |     |     |     |KST        |        |er-0.0.0.0 |        |
|        |         |     |     |     |           |        |:8188      |        |
+--------+---------+-----+-----+-----+-----------+--------+-----------+--------+
================================================================================

MS의 종료는 jeusadmin 명령어를 통해 가능하다. 특정 MS에 접속한 콘솔 툴에서 local-shutdown 명령어를 통해 접속한 MS를 종료할 수도 있으며, 콘솔 툴이나 WebAdmin에서 MASTER를 통한 명령어로 종료할 수도 있다. MS를 종료하는 방법에 대한 자세한 내용은 “JEUS Domain 안내서”의 “4.3.2. Managed Server(MS) 종료”를 참고한다.

참고

MS는 MASTER의 관리를 받는 것이 기본 정책이므로 MASTER를 통해 종료하는 것을 권장한다.

예제

MS를 종료할 때 현재 수행 중인 요청에 대한 처리를 보장해주는 Graceful Shutdown 기능이 존재한다. 서버 종료를 요청한 시점부터는 새로운 요청은 처리하지 않으나, 현재 수행 중인 요청에 대해서는 정해진 시간만큼 처리가 끝나길 기다려 줄 수 있다.

다음은 MS 종료 명령에 Timeout 옵션을 통해 대기시간을 설정하는 예제이다.

[MASTER]domain1.adminServer>stop-server server1 -to 60000
Stop server message to server [server1] was successfully sent.

콘솔 툴을 통해 해당 MS에 직접 접속한 경우 역시 Timeout 지정이 가능하다.

domain1.server1>local-shutdown -to 60000
Executing this command affects the service. Do you want to continue? (y/n)y
The server [server1] has been shut down successfully.
offline>

정상적으로 종료된 서버에서는 다음과 같은 로그를 확인할 수 있다.

...
[2022.07.14 23:39:28][2] [server1-25] [SERVER-0248] The JEUS server is SHUTDOWN.
[2022.07.14 23:39:28][2] [server1-24] [NET-0214] Closing http-server.
[2022.07.14 23:39:28][0] [server1-25] [SERVER-0265] The JEUS server has exited.
[2022.07.14 23:39:28][0] [server1-1] [SERVER-0099] The server[server1] has been shut down.
[2022.07.14 23:39:28][0] [server1-20] [SERVER-0565] The JVM process is shutting down.
[2022.07.14 23:39:28][0] [server1-20] [SERVER-0566] The JVM process will be terminated.
[2022.07.14 23:39:28][2] [server1-22] [NET-0214] Closing base.

MS의 종료는 애플리케이션 서비스를 모두 내리고 MS JVM을 종료하는 과정이다. 이와 달리 서비스하고 있던 모든 애플리케이션의 일시 정지 기능이 제공된다. 여기서도 마찬가지로 Graceful Timeout을 적용하여 현재 수행 중인 요청 처리 완료를 기다릴 수 있다. 콘솔 툴의 suspend-server 명령어 또는 WebAdmin을 통해서 동작 가능하다.

WebAdmin 사용

다음은 WebAdmin을 통해 서버를 일시 정지하는 과정에 대한 설명이다.

  1. WebAdmin의 도메인 관리 콘솔 화면에서 서버 항목을 클릭하면 도메인 내 서버 목록이 조회된다. 서버 목록에서 일시 정지할 서버의 이름 옆에 있는 체크박스를 체크한 뒤 [일시정지] 버튼을 클릭한다.

    [그림 3.2] 도메인 서버 목록 조회

    도메인 서버 목록 조회

  2. [선택한 서버/클러스터를 일시정지합니다. 진행하시겠습니까?] 라는 창이 나타나고 다시 한 번 [일시정지] 버튼을 클릭한다.

    [그림 3.3] 도메인 서버 일시 정지 확인

    도메인 서버 일시 정지 확인

  3. 서버 목록에서 서버의 상태가 SUSPENDED로 변경된 것을 확인할 수 있다.

    [그림 3.4] 도메인 서버 일시 정지

    도메인 서버 일시 정지

콘솔 툴 사용

다음은 콘솔 툴을 통해 서버를 일시 정지하는 예제이다.

[MASTER]domain1.adminServer>suspend-server -servers server1
Executing this command affects the service. Do you want to continue? (y/n)y
Successfully suspended server(s).

server-info 명령어로 서버가 SUSPENDED 상태가 된 것을 확인할 수 있다.

[MASTER]domain1.adminServer>server-info
================================================================================
+-------+---------+-----+-----+-----+--------------+-------+-----------+-------+
| Server|  Status |Node | PID | Clu | Latest Start |  Need |   Listen  | Runni |
|       |         |Name |     |ster |    Time /    |  to   |   Ports   |  ng   |
|       |         |     |     |     |Shutdown Time |Restart|           |Engines|
+-------+---------+-----+-----+-----+--------------+-------+-----------+-------+
| admin | RUNNING | nod | 880 | N/A | 2022-07-14   | false | base-0.0. | jms,  |
|Server |(00:22:1 |e1   |29   |     |(목) 오후      |       |0.0:9736   |web,   |
| (*)   |4)       |     |     |     |11:38:36 KST  |       | http-serv |ejb    |
|       |         |     |     |     |              |       |er-0.0.0.0 |       |
|       |         |     |     |     |              |       |:8088      |       |
+-------+---------+-----+-----+-----+--------------+-------+-----------+-------+
| serve | SUSPEND | N/A | 891 | N/A | 2022-07-14   | false | base-0.0. | jms,  |
|r1     |ED(00:08 |     |46   |     |(목) 오후      |       |0.0:9836   |web,   |
|       |:01)     |     |     |     |11:52:49 KST  |       | http-serv |ejb    |
|       |         |     |     |     |              |       |er-0.0.0.0 |       |
|       |         |     |     |     |              |       |:8188      |       |
+-------+---------+-----+-----+-----+--------------+-------+-----------+-------+
================================================================================

정상적으로 일시 정지된 서버에서는 다음과 같은 로그를 확인할 수 있다.

[2022.07.15 00:15:16][2] [server1-25] [SERVER-0248] The JEUS server is SUSPENDING.
[2022.07.15 00:15:16][2] [server1-25] [JMS-7375] The persistence store manager for the JMS server 'server1' has been shut down.
[2022.07.15 00:15:16][2] [server1-25] [SERVER-0248] The JEUS server is SUSPENDED.

참고

MASTER의 제어를 받지 않고 있는 경우에도 해당 서버에 직접 콘솔 툴에 접속하여 MS를 일시 정지시킬 수 있다.

일시 정지되었던 서버의 애플리케이션들을 다시 서비스하도록 복귀시킬 수 있다.

WebAdmin 사용

다음은 WebAdmin을 통해 서버를 복귀시키는 과정에 대한 설명이다.

  1. WebAdmin의 도메인 관리 콘솔 화면에서 서버 항목을 클릭하면 도메인 내 서버 목록이 조회된다. 서버 목록에서 복귀할 서버의 이름 옆에 있는 체크박스를 체크한 뒤 [재개] 버튼을 클릭한다.

    [그림 3.5] 도메인 서버 목록 조회

    도메인 서버 목록 조회

  2. [선택한 서버/클러스터를 재개합니다. 진행하시겠습니까?] 라는 창이 나타나고 다시 한 번 [재개] 버튼을 클릭한다.

    [그림 3.6] 도메인 서버 재개 확인

    도메인 서버 재개 확인

  3. 동작이 완료된 후 서버 목록의 Status 값을 통해 서버가 정상적으로 복귀되었는지 여부를 확인할 수 있다.

    [그림 3.7] 도메인 서버 재개

    도메인 서버 재개

콘솔 툴 사용

MASTER의 제어를 받지 않고 있는 경우에도 해당 서버에 직접 콘솔 툴에 접속하여 SUSPENDED 상태인 MS를 다시 시작시킬 수 있다.

다음은 콘솔 툴을 통해 서버를 복귀시키는 예제이다.

[MASTER]domain1.adminServer>resume-server -servers server1
Successfully resumed the servers.

server-info 명령어를 통해 서버가 다시 RUNNING 상태가 된 것을 확인할 수 있다.

[MASTER]domain1.adminServer>server-info
================================================================================
+--------+--------+-----+-----+-----+------------+--------+-----------+--------+
| Server | Status |Node | PID | Clu |   Latest   |  Need  |   Listen  |Running |
|        |        |Name |     |ster | Start Time |   to   |   Ports   |Engines |
|        |        |     |     |     | / Shutdown |Restart |           |        |
|        |        |     |     |     |    Time    |        |           |        |
+--------+--------+-----+-----+-----+------------+--------+-----------+--------+
| adminS | RUNNIN | nod | 121 | N/A | 2022-07-15 | false  | base-0.0. | jms,   |
|erver   |G(00:04 |e1   |360  |     | (금) 오전   |        |0.0:9736   |web, ejb|
|(*)     |:21)    |     |     |     |11:30:11 KST|        | http-serv |        |
|        |        |     |     |     |            |        |er-0.0.0.0 |        |
|        |        |     |     |     |            |        |:8088      |        |
+--------+--------+-----+-----+-----+------------+--------+-----------+--------+
| server1| RUNNIN | N/A | 122 | N/A | 2022-07-15 | false  | base-0.0. | jms,   |
|        |G(00:01 |     |223  |     | (금) 오전   |        |0.0:9836   |web, ejb|
|        |:07)    |     |     |     |11:33:26 KST|        | http-serv |        |
|        |        |     |     |     |            |        |er-0.0.0.0 |        |
|        |        |     |     |     |            |        |:8188      |        |
+--------+--------+-----+-----+-----+------------+--------+-----------+--------+
================================================================================

정상적으로 애플리케이션 서비스가 다시 시작된 서버에서는 다음과 같은 로그를 확인할 수 있다.

[2022.07.15 11:34:29][2] [server1-26] [SERVER-0248] The JEUS server is RESUMING.
[2022.07.15 11:34:29][2] [server1-26] [SERVER-0248] The JEUS server is RUNNING.

3.2. 서버 엔진 설정

JEUS 서버에는 애플리케이션을 서비스하는 엔진이 내부적으로 존재한다. 웹 애플리케이션 서비스, EJB 애플리케이션 서비스, JMS 서비스를 위한 엔진이 각각 존재한다. 이들 각 엔진의 사용 여부는 초기화 시점을 설정을 통해 제어할 수 있다. 단, 현재 이들 설정은 모두 서버를 재기동해야 적용된다.

JEUS 서버의 각 엔진의 사용 여부를 설정한다. 각 엔진에 대하여 사용 설정을 할 경우 각 엔진들은 서버가 기동되거나 각 엔진에서 서비스될 첫 번째 애플리케이션이 deploy될 때 필요한 엔진이 초기화된다. 사용 설정을 하지 않은 경우 서버가 기동된 후에도 엔진은 초기화되지 않으므로 해당 엔진에서 서비스될 애플리케이션들을 deploy하면 실패하게 된다.

주의

엔진 사용가능할 때 정상적으로 deploy된 애플리케이션을 이후 엔진 미사용을 한 후 서버를 기동할 경우 해당 애플리케이션은 deploy 실패하게된다. 그리고 서버의 상태도 서비스 가능상태(RUNNING)가 아닌 대기(STANDBY)로 전환됨으로 관리자가 이를 확인하여 엔진의 상태와 애플리케이션의 상태를 수정해주어야 한다.

WebAdmin 사용

WebAdmin의 도메인 관리 콘솔 화면에서 서버 항목을 클릭하면 도메인 내 서버 목록이 조회된다. 서버 목록에서 서버(server1)를 선택한 뒤에, 서버 설정 화면에서 [Basic > Basic Info] 탭을 선택한다. [수정] 버튼을 누르고 엔진 정보를 변경한 뒤에 [저장] 버튼을 클릭한다. 변경한 설정을 적용하기 위해서는 서버를 재시작해야 한다.

콘솔 툴 사용

콘솔 툴에서 서버 내 각 엔진 사용 여부를 설정하는 방법은 다음과 같다.

[MASTER]domain1.adminServer>disable-engines adminServer -all
[adminServer]
Change Engine to Disabled: Web EJB JMS 

Applying configuration ...
================================================================================
+------------------------------------------------------------------------------+
|                                    Result                                    |
+------------------------------------------------------------------------------+
| Successfully changed only the JEUS Domain Configuration.                     |
| Restart the server to apply the changes.                                     |
+------------------------------------------------------------------------------+
================================================================================
...
[MASTER]domain1.adminServer>enable-engines adminServer -all
[adminServer]
Change Engine to Enabled: Web EJB JMS 

Applying configuration ...
================================================================================
+------------------------------------------------------------------------------+
|                                    Result                                    |
+------------------------------------------------------------------------------+
| Successfully changed only the JEUS Domain Configuration.                     |
| Restart the server to apply the changes.                                     |
+------------------------------------------------------------------------------+
================================================================================
...
[MASTER]domain1.adminServer>disable-engines adminServer -web -ejb
[adminServer]
Change Engine to Disabled: Web EJB 

Applying configuration ...
================================================================================
+------------------------------------------------------------------------------+
|                                    Result                                    |
+------------------------------------------------------------------------------+
| Successfully changed only the JEUS Domain Configuration.                     |
| Restart the server to apply the changes.                                     |
+------------------------------------------------------------------------------+
================================================================================
...
[MASTER]domain1.adminServer>enable-engines adminServer -web -ejb
[adminServer]
Change Engine to Enabled: Web EJB 

Applying configuration ...
================================================================================
+------------------------------------------------------------------------------+
|                                    Result                                    |
+------------------------------------------------------------------------------+
| Successfully changed only the JEUS Domain Configuration.                     |
| Restart the server to apply the changes.                                     |
+------------------------------------------------------------------------------+
================================================================================

참고

JEUS 콘솔 툴의 서버 내 엔진 설정 명령어에 대한 자세한 정보는 “JEUS Reference 안내서”의 “4.2.3.13. disable-engines”, “JEUS Reference 안내서”의 “4.2.3.16. enable-engines”를 참고한다.

JEUS 서버의 각 엔진의 사용 여부를 설정한다. 각 엔진에 대하여 사용 설정을 할 경우 각 엔진들은 엔진 초기화와 동시에 또는 각 엔진에서 서비스될 첫 번째 애플리케이션이 deploy될 때 필요한 엔진이 초기화된다. 사용 설정을 하지 않은 경우 서버가 기동된 후에도엔진은 초기화되지 않으므로 해당 엔진에서 서비스될 애플리케이션들을 deploy할 경우 실패하게 된다. WebAdmin과 콘솔 툴로 각 엔진별 사용 여부를 설정할 수 있다.

WebAdmin 사용

WebAdmin의 도메인 관리 콘솔 화면에서 서버 항목을 클릭하면 도메인 내 서버 목록이 조회된다. 서버 목록에서 서버(server1)를 선택한 뒤에, 서버 설정 화면에서 [Basic > Basic Info] 탭을 선택한다. [수정] 버튼을 누르고 'Engine Init On Startup' 설정을 변경한 뒤에 [저장] 버튼을 클릭한다. 변경한 설정을 적용하기 위해서는 서버를 재시작해야 한다.

콘솔 툴 사용

콘솔 툴에서 서버 내 각 엔진의 초기화 시점을 설정하는 방법은 다음과 같다.

[MASTER]domain1.adminServer>disable-engine-init-on-boot adminServer,server1
EngineInitOnBoot was successfully disabled.
Applying configuration ...
================================================================================
+------------------------------------------------------------------------------+
|                                    Result                                    |
+------------------------------------------------------------------------------+
| Successfully changed only the JEUS Domain Configuration.                     |
| Restart the server to apply the changes.                                     |
+------------------------------------------------------------------------------+
================================================================================

[MASTER]domain1.adminServer>enable-engine-init-on-boot adminServer
EngineInitOnBoot was successfully enabled.
Applying configuration ...
================================================================================
+------------------------------------------------------------------------------+
|                                    Result                                    |
+------------------------------------------------------------------------------+
| Successfully changed only the JEUS Domain Configuration.                     |
| Restart the server to apply the changes.                                     |
+------------------------------------------------------------------------------+
================================================================================

참고

JEUS 콘솔 툴의 서버 내 엔진 설정 명령어에 대한 자세한 정보는 “JEUS Reference 안내서”의 “4.2.3.12. disable-engine-init-on-boot”, “JEUS Reference 안내서”의 “4.2.3.15. enable-engine-init-on-boot”를 참고한다.

3.3. Thread 모니터링 및 제어

JEUS에서는 서블릿 Thread와 EJB 리모트 Thread, System Thread Pool에 대한 모니터링 기능과 Thread의 Stack을 확인할 수 있는 기능, 그리고 특정 Thread에 Interrupt Signal을 보낼 수 있는 기능을 제공한다.

JEUS에서는 Thread를 모니터링하는 기능을 제공한다. 모니터링의 대상이 되는 Thread는 서블릿 Thread, EJB 리모트 요청 Thread 그리고 System Thread Pool이다.

서블릿 Thread나 EJB 리모트 요청 Thread의 모니터링 기능을 사용하면 Thread ID, Thread 이름, Thread 상태, 처리시간 등의 정보를 알 수 있고 Thread Pool 모니터링 기능을 사용하면 System Thread Pool의 core size, max size, keep alive time 그리고 System Thread Pool에 있는 Thread 정보를 알 수 있다. 단, 콘솔 툴에서는 서블릿 Thread와 EJB 리모트 요청 Thread만 모니터링할 수 있다.

Thread 정보 확인

WebAdmin과 콘솔 툴로 Thread 정보를 확인할 수 있다.

특정 Thread의 Stack Trace 조회

WebAdmin과 콘솔 툴로 특정 Thread의 Stack Trace를 조회할 수 있다.

참고

1. JEUS 콘솔 툴의 ti 명령어와 strace 명령어에 대한 자세한 정보는 “JEUS Reference 안내서”의 “4.2.2. Local 명령어”를 참고한다.

2. 서블릿 Thread와 EJB 리모트 요청 Thread 정보, Stack Trace는 WebAdmin의 [Monitoring] > [Thread] 메뉴에서 확인할 수 있다. 또한 System Thread Pool의 정보와 System Thread Pool의 Thread 정보를 확인할 수 있다. 더 자세한 사항은 "JEUS WebAdmin 안내서"를 참고한다.

JEUS에서는 특정 Thread에 Interrupt Signal을 보내서 수행 중인 작업을 중단할 수 있도록 Exception을 발생시키는 기능이 있다.

주의

이 기능은 현재 실험적으로 제공되는 기능으로 Thread에 Interrupt가 걸려 있으면 수행 중인 Thread가 바로 중단되는 것이 아니라 Interrupt Status를 체크하여 Exception을 던져 더 이상 진행하지 않도록 유도하는 것이기 때문에 발생하는 Exception에 대해서는 사용자 애플리케이션에서 처리해야 한다. Exception을 제대로 처리하지 않아서 발생하는 문제에 대해서는 사용자에게 책임이 있다.

Thread Interrupt

Thread에 Interrupt를 건다는 것은 동작하고 있는 Thread에 Interrupt Signal을 보내서 현재 진행 중인 동작의 중단을 유도하기 위해 Exception을 발생시켜 이후의 작업을 더 이상 진행하지 않도록 힌트를 주는 것이다. 주로 요청이 블록되어 있거나, 예상한 시간보다 오래 지체되어 있는 경우에 사용될 수 있다.

실제로 Thread에 Interrupt가 걸린다고 해서 해당 Thread가 강제적으로 멈춘다든가, Interrupt를 발생시키는 순간에 바로 효과가 있는 것은 아니다.

JEUS에서는 서블릿 Thread, EJB 리모트 요청 Thread와 System Thread Pool의 수행 중인 Thread에 Interrupt Signal을 보낼 수 있는 기능을 지원한다. 이때 Thread가 JNDI 원격 커넥션이나 EJB operation, JDBC operation, 또는 I/O 작업을 진행 중이면 Interrupt가 걸릴 수 있다.

  • 서블릿 Thread

    서블릿 Thread는 다음의 경우들에 대해 Interrupt가 걸려 있으면 Exception이 발생한다. 이때 발생하는 Exception에 대한 처리는 사용자 애플리케이션에서 해야 한다.

    • JNDI 원격 커넥션을 맺으려고 할 때

    • JNDI 원격 operation을 수행하려고 할 때

    • EJB 호출하려고 할 때

    • JDBC 커넥션을 얻어올 때 또는 커넥션 객체의 메소드를 호출할 때

    콘솔 툴이나 WebAdmin을 통해 관리자가 직접 Interrupt를 걸 수 있으며, 서블릿 Thread의 수행시간을 체크하여 자동으로 Interrupt 되도록 하는 기능을 제공한다. 이 기능에 대한 설정 방법은 “JEUS Web Engine 안내서”의 “4.4. 자동 Thread Pool 관리 설정(Thread 상태 통보)”을 참고한다.

  • EJB 리모트 요청 Thread

    EJB operation의 경우에는 다음의 시점에 Interrupt Status를 체크해서 javax.ejb.EJBException을 발생시킨다.

    • EJB 2.x 방식으로 create와 같은 EJBHome 메소드를 호출할 때(EJB 3.0의 경우 사용자가 EJB Lookup을 하면 EJB 컨테이너 내부적으로 create 처리)

    • EJB 비즈니스 메소드를 호출할 때

    이때 발생하는 Exception에 대해서는 사용자 애플리케이션에서 적절하게 처리해주어야 한다. 만약 EJB 비즈니스 메소드 호출이 이미 들어간 상태에서 Interrupt Signal을 받았다면 Exception이 발생하지 않을 수 있다. 하지만 해당 메소드에서 다른 EJB를 호출한다던가, JDBC operation이나 JNDI operation을 사용하는 경우라면 Interrupt가 걸릴 수도 있다.

  • JDBC

    JDBC operation의 경우에는 다음의 operation을 수행하려고 할 때 Interrupt Signal을 받았다면 java.sql.SQLException이 발생한다. 이때 발생하는 Exception에 대해서는 사용자 애플리케이션에서 적절하게 처리해주어야 한다.

    • DataSource#getConnection()을 통해 Connection Pool에서 커넥션을 가져올 때

    • Connection Pool에서 가져온 java.sql.Connection에 대해서 operation을 수행하려고 할 때

    • JDBC Connection Pool 설정에 use-sql-trace나 stmt-caching-size 옵션을 설정하고 executeQuery와 같은 operation을 수행하려고 할 때(옵션에 대한 자세한 설명은 “6.4.2. Connection Pool 설정”을 참고한다.)

  • JNDI

    JNDI operation을 수행하는 중에도 Interrupt의 효과가 있는 경우가 있다. 다음의 JNDI operation을 수행하려고 할 때 Interrupt Signal을 받았다면 javax.naming.NamingException이 발생한다. 이때 발생하는 Exception에 대해서는 사용자 애플리케이션에서 적절하게 처리해주어야 한다.

    • JNDI 원격 커넥션을 맺을 때(javax.naming.InitialContext를 생성하는 시점)

    • JNDI operation을 하기 위해 원격 메시지를 보낼 때

      Lookup, Bind, Rebind, Rename과 같은 JNDI operation일 경우이다. 단, 로컬(같은 JVM)에 있는 레지스트리에 접근하거나 캐시에 접근하는 경우에는 Interrupt의 효과가 없다.

  • I/O 작업

    I/O 작업을 할 때는 항상은 아니지만 상황에 따라 Interrupt의 효과가 있을 수 있다.

    • java.nio.channels.SocketChannel

      java.nio.channels.SocketChannel을 사용하는 경우에는 Interrupt에 걸리게 된다. java.nio.channels.SocketChannel을 사용해서 연결할 때는 3단계로 분리된다.

      첫 번째 단계인 begin 단계에서는 Thread에 Interrupt Status가 설정되었는지 체크하고 설정되어 있다면 채널을 종료한다. 실제 연결하는 단계에서는 Interrupt Status가 설정되어 있다면 connect()를 진행하지 않고, end 단계에서 Interrupt가 걸려 있다면 java.nio.channels.ClosedByInterruptedException이 발생한다(이후에 Interrupt Status는 clear된다).

    • java.nio.channels.SocketChannel#read()/java.nio.channels.SocketChannel#write()

      java.nio.channels.SocketChannel#read()나 java.nio.channels.SocketChannel#write()하는 경우에도 역시 3단계로 나뉘게 된다.

      첫 번째 단계인 begin 단계에서는 Interrupt Status가 설정되었는지 체크하고 설정되어 있다면 채널을 종료한다. 그리고 실제 IO를 처리하는 단계에서는 Interrupt Status가 설정되어 있다면 실제 Read, Write를 진행하지 않고 마지막 end 단계에서는 java.nio.channels.ClosedByInterruptedException이 발생한다(이후에 Interrupt Status는 clear된다).

      java.nio.channels.ClosedByInterruptedException이 발생한 후 이전에 생성했던 채널을 사용해서 Read, Write를 하려고 하면 I/O 작업이 수행되지 않고 java.nio.channels.ClosedChannelException이 발생한다.

    • java.net.Socket 사용

      java.net.Socket을 사용할 때는 OS, JVM에 따라서 다르다. HP-UX와 Solaris에서는 JVM의 컴파일 옵션에 따라 Socket I/O 작업에 Interrupt를 걸 수 있다.

      Socket의 스트림을 통해 Read나 Write를 하려고 할 때 Interrupt Status가 체크되기 때문에 Interrupt에 걸릴 수 있고 java.net.SocketException이 발생한다(이후에 Interrupt Status는 clear된다). 하지만 이때 실제 소켓이 끊어지는 것은 아니고 Interrupt가 걸린 시점의 다음 operation만 중단된다(다음에 Read, Write를 수행하면 제대로 동작한다).

      그 외 Windows, IBM AIX, Linux 등에서는 Socket I/O 작업을 하는 Thread에 Interrupt를 걸어도 효과가 없다.

  • Object#wait() / Thread#sleep() / Thread#join()

    Thread가 Object#wait(), Thread#sleep() 또는 Thread#join()하고 있는 상태라면 해당 Thread는 Interrupt에 걸리게 된다. 이 경우 해당 Thread는 java.lang.InterruptedException이 발생한다(이후에 Interrupt Status는 clear된다).

참고

자세한 사항은 해당 클래스의 Javadoc API 문서를 참고한다.

Interrupt Signal 전송

JEUS에서는 콘솔 툴과 WebAdmin을 통해 Thread에 Interrupt Signal을 보낼 수 있는 명령을 제공한다.

3.4. 메모리 모니터링 및 제어

JEUS에서는 메모리를 모니터링하고 특정 사용량을 초과한 경우에 서버를 제어할 수 있는 기능을 제공한다.

WebAdmin과 콘솔 툴을 사용해서 메모리 정보를 확인할 수 있다.

WebAdmin 사용

WebAdmin을 통해서 메모리 정보를 확인하는 방법은 도메인 관리 콘솔에서 [상태]의 [Web] 메뉴를 사용하거나 [System Info] 메뉴를 사용하는 방법이 있다.

[Web] 메뉴에서는 간단한 메모리 정보를 확인할 수 있고, [System Info] 메뉴에서 메모리 정보뿐만 아니라 CPU, Process, JVM 정보까지 모두 확인할 수 있다. 본 절에서는 [System Info] 메뉴를 사용한 방법을 설명한다.

다음은 WebAdmin의 [System Info] 메뉴를 사용해서 메모리 정보를 확인하는 방법이다.

  1. WebAdmin의 도메인 관리 콘솔에서 [상태] > [System Info]를 선택하면 메모리를 포함한 시스템 전반적인 모니터링 화면으로 이동한다.

  2. 조회할 서버 이름을 클릭하면 메모리 정보를 확인할 수 있다.

콘솔 툴 사용

콘솔 툴에서 memory-info 명령어를 사용하여 메모리 정보를 확인할 수 있다. memory-info 명령어에 대한 자세한 내용은 “JEUS Reference 안내서”의 “4.2.3. Server Management 관련 명령어”를 참고한다.

[MASTER]domain1.adminServer>memory-info -servers adminServer
Domain [domain1] Memory Information
Memory Information
================================================================================
+-------------+---------------------------+------------------------------------+
|    Server   |   Total Amount of Memory  |    The Current Amount of Memory    |
+-------------+---------------------------+------------------------------------+
| adminServer |                 721420288 |                          315030816 |
+-------------+---------------------------+------------------------------------+
================================================================================

JEUS에서는 자주 사용되는 기능은 아니기 때문에 현재 시스템 프로퍼티를 통해서만 메모리 관련 동작을 제어할 수 있다.

관련된 프로퍼티는 다음과 같다.

프로퍼티설명
jeus.server.memorymonitor.enabled

MemoryMoniterService를 사용할 것인지를 설정한다.

설정이 활성화되어 있지 않다면 나머지 프로퍼티의 속성은 의미가 없다.

(기본값: false)

jeus.server.memorymonitor.ratio

Memory Overflow의 기준치를 설정한다.

만약 0.8을 설정했다면 MAX 메모리를 기준으로 약 80%의 메모리를 사용할 경우 Overflow로 간주한다. (기본값: 0.8)

jeus.server.memorymonitor.interval

메모리 사용량을 측정하는 주기를 설정한다.

(기본값: 2000, 단위: ms)

jeus.server.memorymonitor.duration

Memory Overflow를 판단하는 시간을 설정한다. (기본값: 60000, 단위: ms)

예를 들어 jeus.server.memorymonitor.ratio가 0.8이고 jeus.server.memorymonitor.duration이 1분이라면 MemoryMonitorService에서는 메모리가 80% 이상 1분 넘게 지속될 경우 Memory Overflow로 간주한다.

jeus.server.enable.restart.in.memory.shortageMemory Overflow로 판정된 경우 자동으로 서버를 재기동할지 여부를 설정한다. (기본값: true)

참고

1. Memory Overflow가 발생한 경우 오직 한 번 Heap Dump를 떨어뜨리게 되어 있다. (SERVER_HOME/logs 디렉터리에 생성)

2. IBM JDK의 경우에는 Java를 실행한 위치에 Heap Dump가 떨어지므로 경로를 다르게 설정하려면 -Xdump:heap:file 옵션을 사용해야 한다. IBM Heap Dump에 대한 더 많은 옵션은 관련 홈 페이지를 참조한다.

3. Heap Dump를 남기기 전에 Thread Dump가 로그에 남는다.

이전   다음
제2장 JEUS 설정 처음으로 제4장 JNDI Naming Server