Study...★/Java2011. 7. 4. 13:47

가비지 콜렉션 소개

참고: 이 기사에서 설명하는 조정 작업을 올바르게 수행하려면 최신 서비스 릴리스의 SDK나 적어도 SR13 이상의 서비스 릴리스를 사용해야 한다.

가비지 콜렉션은 프로세스에서 더 이상 참조 또는 사용하지 않는 오브젝트로 구성된 힙 즉, Java 애플리케이션에서 자원 관리를 위해 사용되는 정의된 메모리 섹션을 제거하는 JVM(JavaTM Virtual Machine)의 동작이라고 간단히 정의할 수 있다.

이 프로세스에는 다음과 같은 표시, 제거 및 압축이라는 세 가지 주요 단계가 있다.

  • 표시 단계에서는 힙의 모든 오브젝트가 비트를 사용하여 "표시"된다. 오브젝트를 검사하여 오브젝트가 참조되고 있으면 비트가 제거된다.
  • 제거 단계에서는 JVM이 힙 전체를 이동하면서 표시 비트가 설정되어 있는 모든 오브젝트를 제거한다. 이러한 오브젝트는 더 이상 참조 또는 사용되지 않는다.
  • 압축 단계는 전체 GC에서만 실행된다. 이 단계에서는 힙의 모든 오브젝트를 힙의 더 작고, 압축되고, 연속적인 공간에 다시 할당한다.

가비지 콜렉션의 작동 방법

힙 사용 상태를 검사하는 최상의 방법은 verbose GC 출력을 분석하는 것이다.

먼저 다음과 같이 verbose GC가 서버에서 사용되고 있는지 확인하자.

  1. IBM WebSphere Application Server 관리 콘솔에서 Application Servers - WebSphere_Portal - Java and Process Management - Process Definition - Java Virtual Machine으로 이동한다.
  2. Verbose garbage collection 옆의 선택란이 선택되어 있는지 확인한 다음 서버를 다시 시작한다.
  3. 이제 native_stderr.log 파일에서 다음과 같은 유사한 항목을 볼 수 있다.
    <AF[177]: Allocation Failure. need 528 bytes, 3602594 ms since last AF>
    <AF[177]: managing allocation failure, action=1 (0/585421800) (29966688/30811672)>
    <GC(177): GC cycle started Fri Sep 21 23:48:29 2007
    <GC(177): freed 218620376 bytes, 40% free (248587064/616233472), in 459 ms>
    <GC(177): mark: 422 ms, sweep: 37 ms, compact: 0 ms>
    <GC(177): refs: soft 0 (age >= 32), weak 11, final 7424, phantom 0>
    <AF[177]: completed in 460 ms>

로그 파일 항목 분석하기

이제 앞의 로그 항목을 섹션별로 살펴보면서 그 의미를 확인해 보자.

먼저 첫 번째 행부터 살펴보자.

<AF[177]: Allocation Failure. need 528 bytes, 3602594 ms since last AF>

이 항목은 할당이 실패했음을 알려주며, 힙에 오브젝트를 할당할 수 있는 연속 공간이 충분하지 않을 경우에 표시된다. 이 오브젝트는 verbose GC 출력에서 가장 일반적으로 볼 수 있는 조치이다. 이 경우에는 528바이트의 작은 오브젝트였다.

또한 이 행에서는 GC 사이클을 마지막으로 실행한 이후 3602594밀리초가 경과되었음을 알 수 있다.

다음으로 마지막 행을 살펴보자.

<AF[177]: completed in 460 ms>

이 행은 GC에서 경과된 시간을 보여 준다. 이 숫자를 사용하면 마지막으로 GC에 있었던 시간의 비율과 GC를 수행한 시간의 백분율(실제 작업 시간이 아님)을 구할 수 있다. 예를 들면, 다음과 같다.

460/3602594 = .000127% of the time was spent in GC

정상 상태의 서버에서는 GC에 사용되는 시간의 백분율이 13% 미만, 이상적으로는 약 7-10%가 되어야 한다.

두 번째 행으로 돌아가자.

<AF[177]: managing allocation failure, action=1 (0/585421800) (29966688/30811672)>

여기에서 가장 먼저 살펴볼 내용은 "action=" 값이다. 다음과 같은 7개의 조치가 할당 실패 시 발생할 수 있다.

  • action=0은 pinnedFreeList가 소진되었음을 의미한다.
  • action=1은 우선적 가비지 콜렉션 주기를 의미한다.
  • action=2는 전체 할당 실패를 의미한다.
  • action=3은 힙 확장이 발생했음을 의미한다.
  • action=4는 알려진 모든 소프트 참조가 지워졌음을 의미한다.
  • action=5는 임시 힙의 공간을 가져오는 작업이 완료되었음을 의미한다.
  • action=6은 여유 공간이 매우 적다는 것을 의미한다.

이러한 조치는 심각도 순으로 나열되었으며 가장 심각한 조치는 서버에 여유 메모리가 전혀 없을 때 발생한다(action=6).

이 경우에는 action=1이다. 이 유형의 GC에서는 GC의 표시 및 제거 단계만 실행된다.

이 행에는 다음과 같은 내용도 있다.

(0/585421800) (29966688/30811672)

이 행은 AIX® JVM과 관련되어 있다. 이 행에는 두 개의 기수가 있으며, 두 수를 합한 값은 확장된 힙의 크기이다. 둘 중 작은 수가 자동으로 대형 오브젝트 할당에 사용된다.

참고: 대형 오브젝트는 64KB 이상의 오브젝트를 의미한다.

다른 모든 오브젝트는 힙의 다른 섹션에 저장된다. 대형 오브젝트 섹션이 모두 채워진 상황에서 다른 대형 오브젝트가 할당을 요청할 경우 이 오브젝트는 힙의 다른 기본 섹션에 저장된다. 이 오브젝트는 다른 플랫폼 JVM의 유용한 조정 매개변수일 수 있으며 -Xloratio라고 한다.

다음 행의 내용은 다음과 같다.

<GC(177): GC cycle started Fri Sep 21 23:48:29 2007

이 행은 GC 주기의 시작 시간과 현재 주기 즉, GC(177)를 보고한다. 이는 JVM이 시작된 이후 177번째로 실행된 GC이다.

다음 행의 내용은 다음과 같다.

<GC(177): freed 218620376 bytes, 40% free (248587064/616233472), in 459 ms>

이 행에서는 GC 주기 동안 사용 가능하게 된 바이트 수를 알려 준다. 이 경우에는 JVM이 218620376바이트를 사용 가능하게 할 수 있었다.

또한 힙의 40%가 여유 공간임을 알 수 있다. 즉, 616,233,472바이트의 전체 힙 크기 중 248,587,064바이트가 여유 공간이다.

(248587064/616233472)

마지막으로 GC 주기가 완료되는 데 459밀리초가 소요되었다.

이 행은 힙의 여유 공간 용량을 알려 주고, 정리되어 힙에 고정되지 않은 오브젝트가 있음을 알려 주기 때문에 유용하다.

다음 행의 내용은 다음과 같다.

<GC(177): mark: 422 ms, sweep: 37 ms, compact: 0 ms>

이 행은 이 기사의 뒷부분에서 GC를 구성하여 빠르게 실행되도록 조정할 때(-Xgcpolicy:optavgpause 참조) 사용된다. 하지만 지금은 먼저 다음 사항을 살펴보자.

이 행은 각 주기의 실행 시간을 보여 준다. 표시 단계는 422밀리초, 제거 단계는 37밀리초 그리고 압축 단계는 0밀리초가 소요되었다.

또한 다음 두 가지 사항을 바탕으로 이 GC가 전체 GC가 아님을 알 수 있다.

  • 압축 단계를 완료하는 데 0밀리초가 소요되었다.
  • action=1은 전체 GC가 실행되기 전의 우선적 GC였음을 보여 준다.

마지막으로 살펴볼 행은 다음과 같다.

<GC(177): refs: soft 0 (age >= 32), weak 11, final 7424, phantom 0>

먼저 GC가 오브젝트뿐만 아니라 실제 오브젝트에 대한 별도의 참조 오브젝트도 관리한다는 점을 이해해야 한다. 이러한 참조는 작성 시에 네 큐 중 하나와 연관되며, 이러한 연관은 나중에 변경할 수 없다. 네 개의 큐는 표시 단계 동안 다음과 같은 순서로 표시된다.

  1. Soft
  2. Weak
  3. Final
  4. Phantom

Soft 및 weak 참조는 더 이상 참조되지 않을 경우 정리할 수 있다. 종료자(final 큐)가 soft 또는 weak 참조와 연관된 경우에는 soft 또는 weak 참조가 제거된 후에만 종료자가 실행되는 다음 GC 패스에서 제거된다.

지금까지 살펴본 행은 Java SDK 1.4.2의 기본 GC 정책에서 볼 수 있는 기본 행이다. 지금까지의 설명을 바탕으로 JVM의 실행 방법을 살펴보자.


JVM의 라이프 사이클

JVM은 프로세스를 시작하는 선택적 명령행 인수로 시작된다. 이러한 인수는 WebSphere Application Server 관리 콘솔에서 추가되는 일반 JVM 인수이다.

기본적으로 이 명령은 Java 프로세스가 시작할 때 실행된다.

Java –Xmx1024M –Xms256M –Xverbosegc programToRun

여기서 명령행 인수는 다음과 같다.

–Xmx1024M –Xms256M –Xverbosegc

이는 시작 시에 다음과 같은 사항이 발생한다는 것을 의미한다.

  • 최대 힙 크기가 1024MB이다(–Xmx1024M).
  • 최소 힙 크기가 256MB이다(–Xmx256M).
  • Verbose 가비지 콜렉션이 사용된다(–Xverbosegc).

위의 verbose GC 스니펫에서처럼 JVM에 1024MB를 할당하더라도 전체 1024MB를 사용하게 될 것임을 의미하지는 않는다. 예를 들어, verbose 스니펫에서는 616,233,472바이트만 사용했다.

JVM은 최소 256MB가 할당된 상태로 시작되며 이 공간을 사용한다. 그림 1을 보면 사용하도록 설정된 전체 힙의 크기가 1024MB이다(전체 막대). 하지만 음영 처리된 부분인 초기 256MB만 사용하도록 할당되었다.


그림 1. 힙의 그림 표현
Pictorial representation of the heap

256MB를 사용할 수 있으므로 JVM은 programToRun 프로그램을 실행하는 데 필요한 오브젝트를 사용하여 초기 256MB를 채운다. 이러한 오브젝트는 힙에 저장할 다음 오브젝트에 대한 요청을 충족할 수 있는 연속 공간이 없을 때까지 이 공간에 추가된다(그림 2 참조).


그림 2. 다양한 크기의 오브젝트가 로드된 힙
Heap with different-sized objects loaded

이제 다음 오브젝트가 힙의 공간을 요청한다. 하지만 이 요청을 충족할 수 있는 연속 공간이 부족하다(그림 3 참조).


그림 3. 요청 오브젝트의 그림 표현
Pictorial representation of the requesting object

이 요청이 발생하면 JVM이 action=1 상태로 GC를 실행하며 그림 4와 같이 그림 표현이 변경된다.


그림 4. action=1 상태로 GC를 실행 중인 JVM(사용하지 않은 오브젝트가 제거됨)
JVM running GC with action=1 (note the unused object is removed)

다음과 같이 변경된다.



이제 이 요청을 충족할 수 있다.



때때로 이동 또는 정리할 수 없는 오브젝트도 있다. 즉, 여전히 사용 중인 오브젝트 및 클래스 오브젝트가 있다. 이전 요청과 같은 두 개의 요청이 추가로 발생했다고 가정하자. 하지만 이번에는 힙에서 제거할 수 있는 오브젝트가 하나도 없다(그림 5 참조).


그림 5. 사용 중인 힙의 현재 표현
Current representation of the heap in use

이 경우에는 GC가 압축 단계를 실행하려고 시도하는 action=2를 실행한다. 압축 단계에서는 흩어져 있는 여유 공간을 한 곳으로 모아서 현재 요청을 충족하기 위해 힙에 있는 오브젝트가 통합된다.

그림 6에서는 압축 단계가 완료된 힙을 보여 준다.


그림 6. 압축된 힙
Compacted heap

이제 다음 요청을 할당할 수 있다(그림 7 참조).


그림 7. 작동 중인 힙의 작업 재개
Progression of the working heap continues

이제 GC 조치 1과 2를 살펴보았으므로 조치 1과 2가 모두 실행된 이후라고 하더라도 다음 오브젝트를 할당할 수 있는 공간이 부족할 경우 어떤 상황이 발생하는지 알 수 있다.

일부 오브젝트를 정리할 수 없다고 가정한 상태에서 힙 작업을 계속할 경우 이러한 공간 부족 현상이 발생한다(그림 8 참조).


그림 8. 할당된 공간이 가득 찬 압축된 힙
Compacted heap with the allocated space full

이 그림을 보면 힙의 모든 용량을 사용하고 있다는 것을 알 수 있다. 이 예제에서는 256MB의 힙이 가득 찼으며, 지금까지 256MB만 사용할 수 있는 힙으로 할당했었다. 그러나 앞에서 최대 힙 크기를 1024MB로 설정했으므로 이 상황이 발생할 경우 사용할 수 있는 여분의 힙 용량이 남아 있다.

이 경우 JVM은 action=3을 수행하여 힙을 65,535바이트 확장한다. 이렇게 되면 사용할 수 있는 힙의 용량이 늘어나며(그림 9 참조) 이에 대한 정보가 verbose GC에 표시된다.


그림 9. 65536바이트 확장된 시스템 힙
System heap expanded by 65536 bytes

다음과 같이 변경된다.



이제 처리 작업을 계속 진행할 수 있다. 새로 할당된 모든 힙은 위와 동일한 조치를 거치게 되며, 마지막으로 전체 1024MB에 도달할 때까지 추가 힙이 할당되는 방식으로 GC 주기가 계속 진행된다.

이 방법에서 알 수 있듯이 힙은 작은 용량의 초기 힙부터 시작하여 순차적으로 확장되며, 압축된 형태의 비교적 양호한 상태로 유지된다.

다음은 전체 GC 이후 힙 확장이 발생하는 verbose GC의 예제이다.

<AF[12]: Allocation Failure. need 8208 bytes, 2272 ms since last AF>
<AF[12]: managing allocation failure, action=2 (3255768/52427264)>
  <GC(12): GC cycle started Wed Dec  2 13:55:07 2009
  <GC(12): freed 9836696 bytes, 24% free (13092464/52427264), in 59 ms>
  <GC(12): mark: 50 ms, sweep: 8 ms, compact: 1 ms>
  <GC(12): refs: soft 0 (age >= 32), weak 0, final 102, phantom 0>
<AF[12]: managing allocation failure, action=3 (13092464/52427264)>
  <GC(12): need to expand mark bits for 61602304-byte heap>
  <GC(12): expanded mark bits by 143360 to 962560 bytes>
  <GC(12): need to expand alloc bits for 61602304-byte heap>
  <GC(12): expanded alloc bits by 143360 to 962560 bytes>
  <GC(12): need to expand FR bits for 61602304-byte heap>
  <GC(12): expanded FR bits by 286720 to 1925120 bytes>
  <GC(12): expanded heap by 9175040 to 61602304 bytes, 36% free>
<AF[12]: completed in 75 ms>

지금까지 힙의 확장 방법과 JVM에서 힙을 사용하는 방법에 대해 살펴보았다. 이제 프로세스가 실행되는 동안 JVM에서 실제로 사용하는 메모리의 용량을 살펴보자.


프로세스에 사용되는 메모리 용량 분석하기

프로세스 또는 포털이 런타임 동안 사용하는 메모리 용량에 대한 오해가 발생할 수 있다. 포털 사용자가 ps avg 명령이나 Microsoft® Windows® 작업 관리자를 사용하여 Java 프로세스에서 사용 중인 메모리 용량을 확인하는 경우가 있는데, 이러한 도구는 Java 프로세스에 할당된 메모리 용량을 보여 준다.

지금까지 살펴본 대로 프로세스에 할당된 메모리 용량과 사용 중인 용량은 그 의미가 서로 다르다.

작업 관리자나 "ps avg"에서 Java 프로세스가 616MB를 사용 중인 것으로 표시된 경우 verbose GC를 보면 해당 용량의 40%만 사용되고 있다는 것을 알 수 있다.

<GC(177): freed 218620376 bytes, 40% free (248587064/616233472), in 459 ms>

OUTOFMEMORY 오류와 힙의 여유 공간

OUTOFMEMORY 오류가 발생하고 힙에 여유 공간이 있을 경우 verbose GC를 검사하여 오류의 원인을 파악할 수 있다. 다음 예제는 메모리 부족 오류와 관련된 verbose GC의 출력이다.

<AF[2474]: Allocation Failure. need 16777232 bytes, 114 ms since lastAF>
<AF[2474]: managing allocation failure, action=2(1026078032/1601894912)>
  <GC(2835): GC cycle started Thu Jul 16 11:21:34 2009
  <GC(2835): freed 5827392 bytes, 64% free (1031905424/1601894912), in 2519 ms>
  <GC(2835): mark: 567 ms, sweep: 24 ms, compact: 1928 ms>
  <GC(2835): refs: soft 0 (age >= 32), weak 0, final 6, phantom 0>
  <GC(2835): moved 1711341 objects, 87482984 bytes, reason=1, used 8 more bytes>
<AF[2474]: managing allocation failure, action=3 (1031905424/1601894912)>
  <GC(2835): need to expand mark bits for 1610611200-byte heap>
  <GC(2835): expanded mark bits by 135168 to 25165824 bytes>
  <GC(2835): need to expand alloc bits for 1610611200-byte heap>
  <GC(2835): expanded alloc bits by 135168 to 25165824 bytes>
  <GC(2835): need to expand FR bits for 1610611200-byte heap>
  <GC(2835): expanded FR bits by 270336 to 50331648 bytes>
  <GC(2835): expanded heap fully by 8716288 to 1610611200 bytes, 64% free>
<AF[2474]: managing allocation failure, action=4 (1040621712/1610611200)>
<AF[2474]: clearing all remaining soft refs>
  <GC(2836): GC cycle started Thu Jul 16 11:21:35 2009
  <GC(2836): freed 227346312 bytes, 78% free (1267968024/1610611200), in 1600 ms>
  <GC(2836): mark: 370 ms, sweep: 19 ms, compact: 1211 ms>
  <GC(2836): refs: soft 438 (age >= 32), weak 1178, final 70, phantom 0>
  <GC(2836): moved 1359393 objects, 60973368 bytes, reason=1, used 600 more bytes>
<AF[2474]: managing allocation failure, action=6 (1267968024/1610611200)>
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
JVMDG318: Heap dump file written to
/opt/WebSphere/AppServer/heapdump.20090716.112135.19377.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to
/opt/WebSphere/AppServer/javacore.20090716.112144.19377.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
<AF[2474]: Insufficient space in Javaheap to satisfy allocation request>
<AF[2474]: completed in 19738 ms>

이 예제를 보면 이 인스턴스에 여유 공간이 충분히 있다는 것을 알 수 있다.

<GC(2836): freed 227346312 bytes, 78% free (1267968024/1610611200), in 1600 ms>

하지만 할당 공간을 요청한 오브젝트도 매우 크다.

<AF[2474]: Allocation Failure. need 16777232 bytes, 114 ms since lastAF>

이 유형의 메모리 부족 상황은 k-클러스터(-Xk)를 사용하거나 대형 오브젝트를 위한 힙의 세그먼트를 정의하는 두 가지 방법으로 해결할 수 있다. 여기서, loratio는 대형 오브젝트 비율이다.

-Xkn

이 매개변수는 힙 내에 클래스 오브젝트를 저장할 위치를 별도로 설정한다. 앞의 예제에서 본 것처럼 프로세스에서 사용하고 있는 참조는 이동 또는 정리할 수 없다. 따라서 이러한 참조는 힙의 해당 위치에 "고정"되며 많은 오브젝트가 힙의 다양한 위치에 고정되면 힙이 단편화된다.

이 단편화를 해결하기 위해 –Xkn 매개변수를 사용할 수 있다. 이 매개변수는 힙의 한 섹션을 클래스 오브젝트만을 위한 공간으로 제공한다. 시스템 조정 분석을 위해 WebSphere Portal Support를 사용해야 하기는 하지만 이 매개변수의 n에 적합한 시작 값은 40,000이다.

이 매개변수를 40,000으로 설정하면 JVM이 k-클러스터에 40,000개의 클래스 오브젝트를 저장할 수 있는 공간을 허용한다. 이 k-클러스터가 가득 찰 경우 시스템은 계속해서 정상 상태로 작동하면서 힙의 나머지 부분을 사용하게 된다.

관리 콘솔에서 –Xk를 일반 JVM 인수에 추가하려면 다음 단계를 수행한다.

  1. WebSphere Application Server V6.0에서 Servers - Application Servers - server_name - Java and Process Management - Process definition - Java Virtual Machine - Generic JVM Arguments를 선택한다.

    또는

    WebSphere Application Server V5.0 및 V5.1에서 Servers - Application Servers - server_name - Process Definition - Java Virtual Machine - Generic JVM Arguments를 선택한다.
  2. –Xk40000을 입력하고 이 구성을 저장한 후 서버를 다시 시작한다.

–Xloration

이 설정을 사용하면 힙의 한 섹션을 대형 오브젝트 즉, 64KB 이상의 오브젝트로 정의된 오브젝트에 사용하기 위해 별도로 설정할 수 있다.

그림 예제에서 보았듯이 오브젝트를 사용하려면 힙에 할당할 수 있는 연속 공간이 있어야 한다. 분명 1,000,000바이트의 연속 공간보다는 528바이트의 연속 공간을 더 쉽게 찾을 수 있다.

대형 오브젝트가 힙의 특정 세그먼트에 유지된다면 이러한 오브젝트를 더 쉽게 할당할 수 있으며, 더 나아가 소형 오브젝트가 힙을 사용하기 위해 대형 오브젝트와 경쟁하지 않아도 된다.

이 매개변수의 값은 구현 후 verbose GC를 모니터링하여 조정할 수 있다. 이 매개변수의 값 n은 해당 시점에 확장된 전체 힙에 대한 백분율로 지정된다. 이 예제의 경우에는 –Xloratio0.2라는 값을 사용하자.

이 값이 서버에 추가되면 verbose GC 출력에 다음과 같은 새 행이 추가된다.

<GC(2): heap layout: (424744560/429495496) (107373880/107373880) /0>

다음은 –Xloratio0.2가 활성화된 verbose GC의 블록이다.

<AF[2]: Allocation Failure. need 536 bytes, 235 ms since last AF>
<AF[2]: managing allocation failure, action=0 (423162736/429495496) 
(107373880/107373880)>
  <GC(2): GC cycle started Sat Aug 15 17:07:25 2009
  <GC(2): heap layout:  (424744560/429495496) (107373880/107373880)  /0>
  <GC(2): freed 1581824 bytes, 99% free (532118440/536869376), in 18 ms>
  <GC(2): mark: 9 ms, sweep: 9 ms, compact: 0 ms>
  <GC(2): refs: soft 0 (age >= 32), weak 0, final 0, phantom 0>
<AF[2]: completed in 18 ms>

이제 힙 레이아웃을 볼 수 있으므로 이 행은 이 n 값을 조정하는 방법을 보여 준다.

<GC(2): heap layout: (424744560/429495496) (107373880/107373880) /0>

첫 번째 비율은 힙의 일반 영역이며(일반 작업 처리를 위해 80% 사용), 두 번째 비율은 대형 오브젝트를 위해 정의된 영역이다(대형 오브젝트 할당을 위해 20% 사용).

각 섹션의 여유 공간 용량이 표시된다. 이 출력을 보면 모든 대형 오브젝트 섹션이 사용 가능하며, 사용 중인 대형 오브젝트가 없다는 것을 알 수 있다.

이 추세가 지속될 경우에는 대형 오브젝트 영역을 20%에서 10%로 낮춰서 일반 작업 처리에 사용할 공간을 늘릴 수 있다. 이제 –Xloratio0.1을 새 값으로 사용한다. 적합한 초기 값은 10% 또는 0.1이다.

관리 콘솔에서 –Xloratio를 일반 JVM 인수에 추가하려면 다음 단계를 수행한다.

  1. WebSphere Application Server V6.0에서 Servers - Application Servers - server_name - Java and Process Management - Process definition - Java Virtual Machine - Generic JVM Arguments를 선택한다.

    또는

    WebSphere Application Server V5.0 및 V5.1에서 Servers - Application Servers - server_name - Process Definition - Java Virtual Machine - Generic JVM Arguments를 선택한다.
  2. –Xloratio0.1을 입력하고 이 구성을 저장한 후 서버를 다시 시작한다.

Java SDK 1.4.2를 위한 추가 조정

다중 프로세서

둘 이상의 스레드를 사용하여 GC를 수행할 수 있다. 스레드 수는 시스템의 프로세서 수보다 작아야 한다. 예를 들어, 네 개의 프로세서로 구성된 시스템일 경우 세 개의 스레드를 GC에 사용할 수 있다. 이 값을 얻기 위해 다음 매개변수를 구현한다.

–Xgcthreadsn
네 개의 프로세서로 구성된 시스템에서 세 개의 스레드를 설정하려면 다음 단계를 수행하여 관리 콘솔에서 –Xgcthreads 매개변수를 일반 JVM 인수에 추가한다.

  1. WebSphere Application Server V6.0에서 Servers - Application Servers - server_name - Java and Process Management - Process definition - Java Virtual Machine - Generic JVM Arguments를 선택한다.

    또는

    WebSphere Application Server V5.0 및 V5.1에서 Servers - Application Servers - server_name - Process Definition - Java Virtual Machine - Generic JVM Arguments를 선택한다.
  2. –Xgcthreads3을 입력하고 이 구성을 저장한 후 서버를 다시 시작한다.

SR12 이후

GC 성능을 향상시킬 수 있는 또 하나의 방법은 동시 표시 매개변수를 사용하는 것이다. Verbose GC 출력을 모니터링하여 살펴보았듯이 대부분의 GC 주기의 표시 단계에서 대부분의 시간이 소요된다. 예를 들면, 다음과 같다.

<AF[1640]: Allocation Failure. need 536 bytes, 154266 ms since last AF>
<AF[1640]: managing allocation failure, action=1 (0/879124880) 
(215122200/219781232)>
  <GC(1718): GC cycle started Wed Aug 19 13:16:24 2009
  <GC(1718): heap layout:  (308539208/879124880) (215136552/219781232)  /0>
  <GC(1718): freed 308553560 bytes, 47% free (523675760/1098906112), 
  in 684 ms>
  <GC(1718): mark: 607 ms, sweep: 77 ms, compact: 0 ms>
  <GC(1718): refs: soft 1 (age >= 32), weak 19, final 582, phantom 3>
<AF[1640]: completed in 685 ms>

이 경우에는 총 685밀리초 중 607밀리초가 표시 단계에서 소요되었다. 이 소요 시간을 줄이기 위해 JDK의 SR13 이상 버전에서 올바르게 작동하는 것으로 검증된 다음 매개변수를 사용할 수 있다.

–Xgcpolicy:optavgpause
이 매개변수는 표시 단계에 소요되는 시간을 줄이고 GC 주기가 처리되지 않고 있더라도 표시 단계를 실행 상태로 유지한다.

관리 콘솔(Java SDK 1.4.2의 SR13 이상)에서 –Xgcpolicy:optavgpause 매개변수를 일반 JVM 인수에 추가하려면 다음 단계를 수행한다.

  1. WebSphere Application Server V6.0에서 Servers - Application Servers - server_name - Java and Process Management - Process definition - Java Virtual Machine - Generic JVM Arguments를 선택한다.

    또는

    WebSphere Application Server V5.0 및 V5.1에서 Servers - Application Servers - server_name - Process Definition - Java Virtual Machine - Generic JVM Arguments를 선택한다.
  2. –Xgcpolicy:optavgpause를 입력하고 이 구성을 저장한 후 서버를 다시 시작한다.

결론

지금까지 verbose 가비지 콜렉션을 읽는 방법과 이 도구를 사용하여 andaddress WebSphere Portal 서버 메모리 관련 정보를 분석하는 방법에 대해 살펴보았다.


참고자료

필자소개

Matt Munse는 2002년부터 메모리, 중지, 충돌, 성능을 포함한 WebSphere Portal 런타임 문제와 WebSphere Portal 검색 엔진 문제를 담당하고 있는 Support Engineer이다. WebSphere Portal 서버 성능 문제를 해결하는 지원 업무 외에도 IBM의 특허 관련 업무와 내부용 Java 및 J2EE 애플리케이션 개발 업무도 맡고 있다.


원문 : http://www.ibm.com/developerworks/kr/library/1003_munse/1003_munse.html

Posted by 달콤한녀석

댓글을 달아 주세요