728x90

IBM JVM 튜닝 - 1

JVM 구조

IBM JVM 구성하는각각의 Component structure 아래와 같이 나뉜다.

 

 영역의 주요 기능은 아래와 같이 요약된다.

 

구분

기능

JVM API

JVM External program 사이의 상호작용에 관여

Diagnostics

JVM 기능에 편리성과 유용성(RAS) 제공

Memory

management

Java application 의한 System memory 효율적인 사용에 관여함

Class loader

Java code 동적 로딩의 편리성 제공

Interpreter

Stack-base bytecode 해석에 관여함

Platform

port layer

다양한 운영시스템에서 JVM native function 사용할  있도록하는 기능제공

[ 1] IBM JVM 구성 요소 설명

 

 

여기서 우리는 ‘Memory management’  중점적으로 다뤄본다.


JIT 컴파일러

흔히, IBM JVM JIT계열의 JVM이라고 표현한다.

JIT 흔히 Just-In-Time 약자로 알려져 있으며이는 JVM  part라기 보다는, SDK 기본 구성요소로 생각하는 것이 맞다.

 

Java Interpreter 언어이고이는 소스가 bytecode 컴파일 되고실행되기 위해서는 다시금 system code 해석되어 수행되어야 하는, performance적인 저하요소를 극복하기 위해 자주 수행되는 Java method 대상으로 미리 system code해석해서, Method call되면 컴파일 과정 없이 바로 서비스를 하는 방식으로 작동한다.

 

 이런 JIT 컴파일러가 때때로 Runtime 문제점이 발생하는 경우는아래의 방법으로 JIT 옵션을 꺼둘 수도 있다.

 

구분

설명

Unix 환경변수 제어방법

Korn  : export JAVA_COMPILER=NONE

Bourne  : JAVA_COMPILER=NONE

export JAVA_COMPILER

 : setenv JAVA_COMPILER NONE

JVM Option 1

-Djava.compiler=NONE

JVM Option 2

-Xint

[ 2] JIT 컴파일러 비활성화

 

 

아래와 같이 JIT 옵션을  수도 있다.

 

구분

설명

Unix 환경변수 제어방법

Korn  : exprt JAVA_COMPILER=jitc

Bourne  : JAVA_COMPILER=jitc

export JAVA_COMPILER

 : setenv JAVA_COMPILER jitc

JVM Option 1

-Djava.compiler=jitc

JVM Option 2

-Xjit

[ 3] JIT 컴파일러 활성화


Garbage Collector

Sun HotSpot 계열의 JVM ‘New/Old/Permanent’등의 세대(Generation)’ 불리는 영역으로 분리된 Heap구조를 가진다.

이에 반해, IBM JVM 영역이 따로 분리되지 않은 하나의 ‘Single Space’ Heap 구성되어 있다.

 

heapbase

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

heaplimit

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

heaptop

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

참고로, IBM JDK 1.5부터는 아래와 같이 세대(Generation)’기반의 Heap 구조를 지원한다.

(GC 알고리즘이 Concurrent Generational Collector  경우의 Heap 구조임)


  

 영역이 어떤 식으로 Garbage Collector 의해 사용되는지 설명하기 위해서,

‘Generational Concurrent Garbage Collection’ 알고리즘에 대해 잠깐 언급하도록 한다.

 

JVM Logic 처리하는 동안새로운 Object들은 당연히 ‘Nursery’영역에 생기게 된다만일새로운 Object 할당되는데 필요한 연속된 메모리 영역 부족하게 되면객체는 ‘Tenured’영역으로 옮겨지게 된다또한, Garbage collection 발생시 옮겨지기도 한다.

 

Nursery 영역은 ‘Allocate Space’ ‘Survivor Space’ 나뉘게 된다.

Object 최초 Allocate Space 생기게 된다만일, Space 부족하게 되는 경우,

Allocation Failure 발생되면 Garbage Collector 작동되고, Scavenge 시작된다.

Scavenge 진행되는 동안, reference 살아있는 Object들은 ‘Survivor Space’ 이동되고이때 reference 없는Object들은 건들지 않는다.

Reference 살아있는 Object들의 이동작업이  끝나게 되면, ‘Allocate Space’ ‘Survivor Space’  역할을 순간적을 바꾸게 된다.

 

이때기존의 reference 없는 Object들은 순간적으로 비워지게 된다그리고다음 Scavenge 발생할  까지는‘Survivor Space’ Object 위한 Allocate 공간 업무를 수행하게 된다.

 


JVM 주요 옵션 소개

GC command-line options

-verbose:gc

garbage collection  정보를 standard out 으로 출력한다.

 

-Xverbosegclog:<file, X, Y>

garbage collection  정보를 파일로 출력한다만약 integer X Y 값을 명시하면 output Y GC Cycle output 포함하는 X 파일로 재지정된다.

) -Xverbosegclog:/user/logs/gclog/gclog.log //로그 경로 설정

 

-Xgcpolicy: <optthruput | optavgpause | gencon | subpool>

 option garbage collector 행동을 제어한다.

-. optthruput

concurrent mark 비활성화 한다만약 application response time 문제가 없다면  option 사용하여 최적의throughput   있다. Optthruput default 값이다.

-. optavgpause

concurrent mark 활성화 한다만약 일반적인 garbage collections  의해 application response time 문제가 있다면 option 사용함으로 문제를 줄일  있다.

-. gencon

Concurrent generational GC 겸용하여 사용함으로 garbage collection 지체 시간을 최소화   있다.

-. subpool

concurrent mark 비활성화 한다이것은 heap 객체들을 배치할   나은 성능을 내기 위해 향상된 object allocation알고리즘을 사용한다 option 16 이상의 processor SMP system에서 실행되며, subpool option AIX, Linux PPC  zSeries, z/OS, i5/OS 에서 가능하다.

 

-Xmx<value>

최대 heap size 지정한다. (Xmx >= Xms)

-Xmx256m // 최대 heap size 256mb  지정한다.


-Xms<value>

최소 heap size 지정한다 Xmo 또한 사용할  있다최소 size 8KB이다.

scavenger  활성화 되어 있을 경우, -Xms >= -Xmn + -Xmo

scavenger  비활성화 되어 있을 경우, -Xms >= -Xmo

-Xms256m // 최소 heap size 256mb  지정한다.


-Xcompactgc

모든 garbage collections(system 또는 global)  대하여 압축을 가능하게 한다.


-Xnocompactexplicitgc

System.gc() 호출에 의한 압축을 불가능하게 한다압축은 만약 –Xcompactgc 명시하거나 또는 compaction triggers 만나면 global garbage collections 에서 발생한다.


-Xcompactexplicitgc          

System.gc() 호출  때마다 모든 GC 시스템에서 압축을 사용 가능하게 한다.


-Xnocompactgc

모든 garbage collections(system 또는 global)  대하여 압축을 사용 불가능하게 한다.


-Xnoclassgc

Class garbage collection  비활성화 한다. JVM 의해서  이상 사용되지 않는 Java class 들과 연관된 storagegarbage collection 끈다 dynamic 클래스 로드 해제를 사용 불가능하게 한다.


-Xclassgc

dynamic 클래스 로드 해제를 사용 가능하게 한다.


-Xalwaysclassgc

global collection 동안 항상 dynamic class load 해제를 수행한다. Default  -Xclassgc  의해 정의된다.

 

-Xmaxf<percentage>

garbage collection  free 되어야 하는 heap 최대 percentage 지정한다만약 free 영역이  값을 초과하면 JVMheap 줄이기 위해 시도한다. Default 0.6(60%) 이다.


-Xminf<percentage>

garbage collection이후 free되어야 하는 heap 최소 percentage 지정한다만약 free영역  값에  미치는 경우 JVM heap 확장하기 위해 시도한다. Default 30%이다.


-Xgcthreads<number>

Garbage Collector  thread 수를 지정한다. Default 물리적인 CPU 수로 지정된다다른 수로 지정하기 위해 (예를 들어 4)  -Xgcthreads4  표기한다.

 

Nonstandard command-line options

-Xss<size>

모든 Java thread 최대 stack size 지정한다. Default 32bit JVM에서 256KB, 64bit JVM에서 512KB 이다.


-Xmso<size>

OS thread stack size 지정한다 

JIT command-line options

-Xint

JVM JIT 사용불가하고, Interpreter 로만 사용한다.


-Xquickstart

최적화를 지연하여 시작 시간을 향상시킨다. 


 분석 기술

GC 알고리즘의 이해

IBM JDK에서는 아래와 같이 주요 4가지 Garbage Collection 옵션을 제공한다.

이들은 아래와 같은 방법으로 설정이 가능하다.

-Xgcpolicy

여기에 설정할  있는 옵션은 다음과 같다.

optthruput GC 알고리즘 설명

구분

설명

옵션 

-Xgcpolicy:optthruput

설명

 옵션은 default GC 알고리즘 이다.

특징으로는작동  일시적으로 정지하는 현상이 발생한다는 점이다.

Object할당을 시도할 , Allocation Failure 발생하게 되면, Garbage Collector reference 끊긴 Object 수집하여 삭제하게 된다.

이때필연적으로 JVM Lock 걸리면서 멈추는 현상이 발생하게 된다.

Application 복잡해지고그에 따라 Heap 커지게 되면역시 GC발생시 멈추게 되는 시간도 증가하게 된다.

장점

Throughput 향상될  있다.
(General GC, Disable concurrent mark)

단점

작동  일시적으로 정지하는 현상이 발생한다.

 

optavgpause GC 알고리즘 설명

구분

설명

옵션 

-Xgcpolicy:optavgpause

설명

위에서 설명한 ‘optthruput’ GC 알고리즘의 단점인 ‘JVM 정지시간 보완하기위한 GC 알고리즘  하나이다.

이는, Application 수행   , Garbage Collection 위한 Thread추가적으로 생성하고 기동시켜서, reference 끊긴 Object들에 대한 scavenge작업을 수행시켜서실제 Garbage Collector 수행될 전체 Heap영역에 대한 Object선별작업을 수행할 필요 없이 reference 끊긴 Object들만을 수거해  있도록 돕는다.

장점

전반적인 응답속도(Response Time) 향상하는 효과를 가져올  있다.

(Enables concurrent mark)

단점

Concurrent Thread 기동에 의한실제 Application 수행에 있어서의

Throughput 감소한다.

 

gencon GC 알고리즘 설명

구분

설명

옵션 

-Xgcpolicy:gencon

설명

해당 옵션이 설정되면, JVM 할당된 Heap 세대(Generation)’기준으로 분류한다이는 위에서 살펴보았듯이, ‘Nursery Space’ ‘Tenured Space’ 말한다.

JVM Logic 처리하는 동안새로운 Object들은 당연히 Nursery’영역에 생기게된다만일새로운 Object 할당되는데 필요한 연속된 메모리 영역이

부족하게 되면 객체는 Tenured 영역으로 옮겨지게 된다.

또한, Garbage collection 발생시 옮겨지기도 한다.

Nursery 영역은 Allocate Space’와 Survivor Space 나뉘게 된다.

Object 최초 Allocate Space 생기게 된다만일, Space 부족하게 되는경우, Allocation Failure 발생되면, Garbage Collector 작동되고, Scavenge 시작된다.

Scavenge 진행되는 동안 reference 살아있는 Object들은 SurvivorSpace 이동되고이때 reference 없는 Object들은 건들지 않는다.

Reference 살아있는 Object들의 이동작업이  끝나게 되면, Allocate Space Survivor Space   역할을 순간적을 바꾸게 된다.

이때기존의 reference 없는 Object들은 순간적으로 비워지게 된다그리고 다음 Scavenge 발생할  까지는 Survivor Space Object 위한 Allocate공간 업무를 수행하게 된다.

장점

전반적인 응답속도(Response Time), Throughput 동시에 평균적으로 향상하는효과를 가져올  있다.
(Enable concurrent mark + General GC)

단점

CPU overhead 상대적으로 발생할  있다.

 

subpool GC 알고리즘 설명

구분

설명

옵션 

-Xgcpolicy:subpool

설명

Heap 공간을 다수의 sub pool 할당하여 Object 관리하는 기법이다.

여기에 LOA(Large Object Area) SOA(Small Object Area) 개념이 들어간다.

장점

상대적으로 높은 성능을 발휘한다.

단점

16 CPU 이상의  사양 서버 환경에서 사용해야 한다.

또한, AIX, z/OS, Linux PPC  특정 플랫폼에서만 사용할  있다.

 

GC Dump 이해

앞에서, GC 알고리즘에 대해 개략적으로 살펴보았다.

여기서는로그가 실제 어떤 식으로 생성되는지 간략한 예를 살펴보도록 한다.

아래는실제로 JEUS 각각의 GC 알고리즘을 적용시켜 생성한 Dump이다.

 

–Xgcpolicy:optthruput GC dump

<af type="tenured" id="4" timestamp="  2 28 10:16:42 2008" intervalms="432.499">

  <minimum requested_bytes="33562648" />

  <time exclusiveaccessms="0.140" />

  <tenured freebytes="158830512" totalbytes="536870912" percent="29" >

    <soa freebytes="136268104" totalbytes="493921280" percent="27" />

    <loa freebytes="22562408" totalbytes="42949632" percent="52" />

  </tenured>

  <gc type="global" id="5" totalid="5" intervalms="434.640">

    <compaction movecount="450409" movebytes="69221728" reason="heap fragmented" />

    <refs_cleared soft="0" threshold="32" weak="0" phantom="0" />

    <finalization objectsqueued="0" />

    <timesms mark="72.584" sweep="5.045" compact="130.030" total="207.766" />

    <tenured freebytes="340455528" totalbytes="536870912" percent="63" >

      <soa freebytes="292138088" totalbytes="488553472" percent="59" />

      <loa freebytes="48317440" totalbytes="48317440" percent="100" />

    </tenured>

  </gc>

  <tenured freebytes="306892880" totalbytes="536870912" percent="57" >

    <soa freebytes="258575440" totalbytes="488553472" percent="52" />

    <loa freebytes="48317440" totalbytes="48317440" percent="100" />

  </tenured>

  <time totalms="208.154" />

</af>

로그 패턴을 보면, Allocation Failure 발생하였고, GC 거쳐 Tenured영역의 Free Space 57% 증가했음을  있다. 

–Xgcpolicy:optavgpause GC dump

<af type="tenured" id="40" timestamp="  2 28 10:17:02 2008" intervalms="223.402">

  <minimum requested_bytes="37748760" />

  <time exclusiveaccessms="36.573" />

  <tenured freebytes="28931592" totalbytes="1073741824" percent="2" >

    <soa freebytes="28931592" totalbytes="1073741824" percent="2" />

    <loa freebytes="0" totalbytes="0" percent="0" />

  </tenured>

  <gc type="global" id="42" totalid="42" intervalms="223.577">

    <refs_cleared soft="0" threshold="32" weak="0" phantom="0" />

    <finalization objectsqueued="0" />

    <timesms mark="28.562" sweep="3.428" compact="0.000" total="32.092" />

    <tenured freebytes="211487536" totalbytes="1073741824" percent="19" >

      <soa freebytes="211487536" totalbytes="1073741824" percent="19" />

      <loa freebytes="0" totalbytes="0" percent="0" />

    </tenured>

  </gc>

  <tenured freebytes="173738776" totalbytes="1073741824" percent="16" >

    <soa freebytes="173738776" totalbytes="1073741824" percent="16" />

    <loa freebytes="0" totalbytes="0" percent="0" />

  </tenured>

  <time totalms="68.845" />

</af>

 
–Xgcpolicy:gencon GC dump

<af type="tenured" id="154" timestamp="  2 29 09:57:50 2008" intervalms="452.265">

  <minimum requested_bytes="37748760" />

  <time exclusiveaccessms="2.137" />

  <nursery freebytes="33161216" totalbytes="33554432" percent="98" />

  <tenured freebytes="242872304" totalbytes="1006632960" percent="24" >

    <soa freebytes="211147296" totalbytes="956301312" percent="22" />

    <loa freebytes="31725008" totalbytes="50331648" percent="63" />

  </tenured>

  <gc type="global" id="226" totalid="1071" intervalms="452.406">

    <refs_cleared soft="0" threshold="32" weak="0" phantom="0" />

    <finalization objectsqueued="8" />

    <timesms mark="26.053" sweep="3.163" compact="0.000" total="29.278" />

    <nursery freebytes="33494840" totalbytes="33554432" percent="99" />

    <tenured freebytes="470984032" totalbytes="1006632960" percent="46" >

      <soa freebytes="439259024" totalbytes="946235392" percent="46" />

      <loa freebytes="31725008" totalbytes="60397568" percent="52" />

    </tenured>

  </gc>

  <nursery freebytes="33494840" totalbytes="33554432" percent="99" />

  <tenured freebytes="433235272" totalbytes="1006632960" percent="43" >

    <soa freebytes="401510264" totalbytes="946235392" percent="42" />

    <loa freebytes="31725008" totalbytes="60397568" percent="52" />

  </tenured>

  <time totalms="31.585" />

</af>

 

<af type="nursery" id="881" timestamp="  2 29 09:57:50 2008" intervalms="285.580">

  <minimum requested_bytes="37748760" />

  <time exclusiveaccessms="0.110" />

  <nursery freebytes="31100848" totalbytes="33554432" percent="92" />

  <tenured freebytes="433235272" totalbytes="1006632960" percent="43" >

    <soa freebytes="401510264" totalbytes="946235392" percent="42" />

    <loa freebytes="31725008" totalbytes="60397568" percent="52" />

  </tenured>

  <gc type="scavenger" id="846" totalid="1072" intervalms="285.732">

    <flipped objectcount="3460" bytes="171648" />

    <tenured objectcount="0" bytes="0" />

    <refs_cleared soft="0" weak="0" phantom="0" />

    <finalization objectsqueued="0" />

    <scavenger tiltratio="50" />

    <nursery freebytes="33013736" totalbytes="33554432" percent="98" tenureage="3" />

    <tenured freebytes="433235272" totalbytes="1006632960" percent="43" >

      <soa freebytes="401510264" totalbytes="946235392" percent="42" />

      <loa freebytes="31725008" totalbytes="60397568" percent="52" />

    </tenured>

    <time totalms="3.648" />

  </gc>

  <nursery freebytes="33013736" totalbytes="33554432" percent="98" />

  <tenured freebytes="433235272" totalbytes="1006632960" percent="43" >

    <soa freebytes="401510264" totalbytes="946235392" percent="42" />

    <loa freebytes="31725008" totalbytes="60397568" percent="52" />

  </tenured>

  <time totalms="3.923" />

</af>

  

–Xgcpolicy:subpool GC dump

<sys id="1" timestamp="  2 29 10:03:16 2008" intervalms="0.000">

  <time exclusiveaccessms="0.048" />

  <tenured freebytes="373520640" totalbytes="536870912" percent="69" />

  <gc type="global" id="1" totalid="1" intervalms="0.000">

    <classloadersunloaded count="0" timetakenms="0.973" />

    <refs_cleared soft="73" threshold="32" weak="127" phantom="4" />

    <finalization objectsqueued="21" />

    <timesms mark="56.218" sweep="5.343" compact="0.000" total="62.748" />

    <tenured freebytes="491131504" totalbytes="536870912" percent="91" />

  </gc>

  <tenured freebytes="491131504" totalbytes="536870912" percent="91" />

  <time totalms="63.282" />

</sys>

 

Subpool CPU 16 이상인 환경에서 최적화 되어있다고 앞서 말했다.

종종 System Capacity 부족한 환경에서는 아래와 같은 로그가 목격되기도 한다.

Module=/usr/java5_64/jre/bin/libj9gc23.so

Module_base_address=0900000001046000

Target=2_30_20071004_14218_BHdSMr (AIX 5.3)

CPU=ppc64 (4 logical CPUs) (0x1f0000000 RAM)

 

위의 로그와 비슷하게, System.gc() 명시적으로 호출된 경우는 아래와 같은 GC Dump 발생한다.

<sys id="1" timestamp="  2 29 10:03:16 2008" intervalms="0.000">

  <time exclusiveaccessms="0.048" />

  <tenured freebytes="373520640" totalbytes="536870912" percent="69" />

  <gc type="global" id="1" totalid="1" intervalms="0.000">

    <classloadersunloaded count="0" timetakenms="0.973" />

    <refs_cleared soft="73" threshold="32" weak="127" phantom="4" />

    <finalization objectsqueued="21" />

    <timesms mark="56.218" sweep="5.343" compact="0.000" total="62.748" />

    <tenured freebytes="491131504" totalbytes="536870912" percent="91" />

  </gc>

  <tenured freebytes="491131504" totalbytes="536870912" percent="91" />

  <time totalms="63.282" />

</sys>


Java Thread Dump 분석

Java Thread Dump특정 Java Process 대한 청사진이라 해석될  있다.

IBM 플랫폼에서 Java Thread Dump text형태로 생성된다.

이를직접 열어서 내용을 Trace하는 것도 가능하지만여기서는 Visual Tool 이용한 분석법을 소개한다.

 

JCA 이용한 Java Thread Dump 분석

1. 다운로드 : http://www.alphaworks.ibm.com/tech/jca (파일명:jca*.zip)

2. 실행화면

 

 3. 설명

실제 javacore덤프를 분석한 화면이다.

덤프 생성 당시가용한 메모리가 없었다는 경고와 함께, Worker Thread  하나가

Running 상태였다는 정보를 쉽게   있다.

이와 같이, Worker Thread 상태정보  Heap Memory Usage정보, Thread Monitor 상태정보(dead lock)등의 정보에쉽게 접근이 가능하다.


Java Heap Dump 분석

Java Heap Dump특정 Java Process allocation 되었던 Heap Memory 대한 청사진이라   있다.

IBM 플랫폼에서는 text형태혹은 phd(Portable Heap Dump)포맷으로 생성된다.

Heap Dump 분석에는 주로 아래와 같은 방법이 사용된다.

구분

설명

URL

Text기반

HeapRoots (HR*.jar)

http://www.alphaworks.ibm.com/tech/heaproots/download

Svcdump (svcdump.jar)

http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21190476

GUI 기반

HeapAnalyzer (ha*.jar)

http://www.alphaworks.ibm.com/tech/heapanalyzer/download

 

여기서는 GUI기반의 HeapAnalyzer 소개한다.

HeapAnalyzer 이용한 Java Heap Dump 분석

1. 실행화면 


2. 
설명

실제 Heap Dump 분석한 화면이다.

Heap Dump 생성 당시의 Memory allocation 대한 Stack정보를 계층구조로 보여주고 있어서, Memory 누수 라던지OOM(Out Of Memory)상황이 발생하였을 경우 원인파악에 매우 도움이 되는 화면을 제공한다.

(*주의: Heap Dump Size 매우  경우는서버의 X-Window환경에서 작업하도록 한다통상적인 Heap Dump 분석에는 많은 Memory 필요하기 때문이다.)


GC Dump 분석

GC Dump 분석이란, -verbose:gc –Xverbosegelog:logname.log  결과로 생성된 GC log파일을 분석하는 것을 말한다.

 역시, script 이용하는 방법과 command-line 이용한 명령어 사용방법 등이 있는데여기서는 역시 GUI 기반의 툴인‘GCCollector’ 이용하는 방법을 소개한다.

 

GCCollector 이용한 GC Dump 분석

1. 다운로드: GCCollector 실행하기 위해서는 JFreeChart  다운받아야 한다.           

구분

URL

GCCollector

http://www.alphaworks.ibm.com/tech/gcdiag/download (파일:GCCollector.zip)

JFreeChart

http://www.jfree.org/jfreechart/index.html

 

2. GCCollector 실행파일에 오류가 발생할 경우 아래와 같이 작성한다.

javaw -Xmx300m –classpath lib/GCCollector.jar;lib/jfreechart-1.0.0-rc1.jar;lib/jcommon-1.0.0-rc1.jar it.imperato.jvmperf.GCCollector

3. 실행화면

 

4. 설명

실제 GC Dump 분석한 화면이다. (-Xgcpolicy:optthruput or –Xgcpolicy:optavgpause)

GCCollector 통해 판단할  있는 항목은 아래와 같다.

l     GC Interval

l     GC Duration (Mark, Sweep, Compact, Total)

l     Allocation Failure: 실제 Garbage Collector 작동된 count 같다고 생각하면 된다.


이럴  이렇게

표준 설정 옵션

표준 옵션

-Xms512m -Xmx1024m

-verbose:gc   

-Xverbosegclog:/user/logs/gclog/gclog.log

전체적인 GC Time 너무 길고, Response Time 너무 나오지 않습니다.

상황

GC 수행시간 그래프를 보면수행시간이 오래 걸리는 GC들의 peak 자주 목격됩니다.

Response Time 역시 너무  나옵니다.

조치

대부분, GC 있어서 Full heap collection 혹은 compaction 소요되는 시간이 너무  경우 발생할  있습니다.

 경우, -Xgcpolicy:optavgpause 옵션을 적용하면, concurrent 하게 heap collection 발생하게 되고, GC 따른 pause시간이 감소하여전체적인 Response Time 향상을 기대할  있습니다.

적용 옵션

-Xgcpolicy:optavgpause

Throughput 너무 적게 나옵니다.

상황

CPU  Memory등의 capacity 좋은 장비임에도 불구하고, WAS 서비스의 전체적인

Throughput 너무 나오지 않습니다.

조치

 경우, -Xgcpolicy:optthruput 옵션을 적용하면, concurrent  mark&sweep 작업을 막음으로써대부분의 ThreadBusiness Service 수행하는데 사용되도록 유도하여 전체적인 Throughput 향상시키는데 도움이   있습니다.

만일, CPU 16 이상인  사양 환경의 경우 –Xgcpolicy:subpool 옵션이 좀더 효과적인 성능을 발휘   있습니다.

 

적용 옵션

일반적인 경우 : -Xgcpolicy:optthruput

16 이상의 CPU 환경 : -Xgcpolicy:subpool

Garbage Collection 너무 자주 발생합니다.

상황

GC Interval 매우 좁게 나타나며, GC count 너무 높게 나옵니다.

조치

Application 특성에 비해 Heap Size 너무 작게 설정되어 있을  있습니다.

또한 경우 –Xgcpolicy:optthruput 옵션이 도움이   있습니다.

적용 옵션

-Xmx 늘림

-Xgcpolicy:optthruput

설정된 Heap Size 실제 사용량의 차이가 너무 심하게 납니다.

상황

실제 WAS JVM 할당한 Heap Size 사용되는 Heap Size 등락폭이 너무 심하게 자주 바뀝니다.

조치

Heap Size 너무 크게 설정되어 있을  있습니다.

Heap Size 줄이고, Generation Heap Space 설정된 경우 ‘Nursery’영역의 Size 좀더

할당해 주는 것도 도움이   있습니다.

적용 옵션

-Xmx 줄임

-Xgcpolicy:optthruput

CPU 16 이상의 환경에서 WAS 운영하는 경우권장 GC 정책은 무엇인가요?

상황

CPU 16 이상의 AIX장비의 IBM JDK 1.5 이상 환경에서 WAS 운영하고자 합니다.

권장 GC 정책은 무엇 인가요.

조치

 경우 -Xgcpolicy:subpool 옵션을 권장합니다.

하지만 Business Application 성격에 따라 다른 결과가 나올  있음으로다른 GC 정책과의 비교 Test 필요합니다.

적용 옵션

-Xgcpolicy:subpool

 Heap Size 넉넉하게 설정하였음에도 불구하고, Allocation Failure 자주 발생합니다.

상황

Heap Size 넉넉하게 설정하였습니다. Application에서 사용하는 Object들도 매우  경우는 별로 발견되지 않는데잦은AF(Allocation Failure) 발생하고 있습니다.

조치

메모리 단편화(Memory Fragmentation) 의심해   있습니다.
WAS
 JVM -Dibm.dg.trc.print=st_verify  설정하여, kCluster/pCluster 설정이 필요합니다또한, -Xloratio옵션을주어 LOA 영역에 대한 사이즈 조절도 때때로 유효한 경우가 있습니다.

적용 옵션

-Xk –Xp 설정 (-Dibm.dg.trc.print=st_verify 설정 로그 분석을 통한 Size 설정)
stdout 로그에 verbosegc정보에 pinned=xxx 라는 형식으로정 보가 남게된다.

-Xloratio 설정

 

반응형

'UNIX & LINUX > AIX' 카테고리의 다른 글

AIX 에서 FTP 접속 Log를 남기려  (0) 2016.08.23
AIX wget 설치  (0) 2015.10.20

+ Recent posts