블로그 이미지
OSSW(Open Source System SoftWare

calendar

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Notice

오픈 소스의 부하테스트 툴인 JMeter를 활용하여 간단한 부하테스트를 수행해 보자.

JMeter 공식 사이트 : http://jmeter.apache.org


1. JMeter를 다운받자. (2014. 12. 02 - 2.12 버전)

2. 다운로드한 apache-jmeter-2.12.zip 파일을 압축 해제한다.

3. apache-jmeter-2.12\bin\jmeter.bat 실행

4. JMeter 메인 화면


5. Thread Group 생성 (Test Plan에 마우스 오른쪽 버튼 > Add > Threads > Thread group 클릭)

    - Thread Group 생성 후 호출 할 virtual user의 숫자나 횟수를 설정한다. (예 : virtual user 1, 횟수 10 설정)

6. HTTP Request 생성(5번에서 생성한 Thread Group 에 마우스 오른쪽 버튼 > Add > Sampler > HTTP Request 클릭)

  - HTTP Request 생성 후 호출할 주소, 포트, Path 등을 설정한다. (예 : 192.168.56.102, 8080, /index.html)


7. 상단에 녹색 play 버튼(녹색 삼각형) 을 누른다.

설정한 횟수만큼 http request가 요청되는 것을 확인할 수 있다. 참~~~ 쉽죠잉~~!!!

by 이환호

posted by lovelywas

특정 폴더 하위의 모든 jar 파일에서 특정 클래스를 찾아보고 싶을 때 사용할 수 있는 쉘 스크립트를 소개합니다.

[실행]

find . -type f -

name '*.jar' | while read LINE; do echo $LINE;jar tvf $LINE | grep WebtInnerConnect

ion;

done

[결과]

./system/local_policy.jar

./system/mail.jar

./system/snmp_agent.jar

./system/sunjce_provider.jar

./system/toolresource.jar

./system/uddi4j.jar

./system/US_export_policy.jar

./system/webt30.jar

25500 Mon Jan 24 10:31:00 KST 2005 tmax/webt/io/WebtInnerConnection.class

./system/xercesImpl.jar

./system/xml-apis.jar

./system/tools.jar


by 이환호

posted by lovelywas

IBM JDK 1.4를 사용하는 JVM에서 자주 발생하는 Heap fragmentation 때문에 자주 곤란한 경우가 있다.

그럼 언제 이와 같은 문제가 발생하는 것이고 원인을 뭘까 고민하던 중 아래 글과 IBM JDK diagnostic 문서를 보면 해결이 가능하다.


Java heap fragmentation의 원인들

 

1. 큰 객체를 할당하는 어플리케이션 (주요원인) --> 어플리케이션 수정

2. 많은 pinned, dosed 객체들 --> pCluster, kCluster 값 변경 (pinned 만 적용됨)

3. JVM fragmentation defect --> 최산 Java를 사용함

4. JNI에서 생성한 객체들 (pinned) --> JNI에서 객체를 제거해주도록 수정

5. Xms = Xmx 인 경우, 장기적으로 fragmentatino이 일어날 수 있음 --> Xms < Xmx 설정

 

Fragmentation is caused by the interaction between objects on the heap that can not be moved and the fact that objects need to be allocated into a single to contiguous area on the heap. These unmovable objects fall into two types:

 

    * Pinned objects:

      These are object that are referenced from a location not with in the Java™ heap. Either by variables in JNI native code or by some part of the JVM's internal structure. These fall into two more sub categories;

          o Class objects, these are referenced from with in the native component of the classloaders and the JIT, or

          o Other pinned objects.

 

      These types of objects tend to be long lived so once allocated they will stay in that location on the heap.

 

    * Dosed objects:

      These are transiently pinned objects. These objects can not be moved during the current GC cycle because references to them are held on the stack of a currently executing thread. This means that they are either temporary local variables to the methods in the call stack or they are parameters that have been passed between methods with in the call stack.

 

      When the call stack returns these objects will be free to be GC'd and/or moved in the next GC cycle assuming they are not dosed again.

출처: http://www-1.ibm.com/support/docview.wss?uid=swg21196072

 

 

How can I prevent Java heap fragmentation?

Note that the following suggestions might not help avoid fragmentation in all cases.

o Start with a small heap. Set -Xms far lower than -Xmx. It might be appropriate to allow -Xms to default, because the default is a low value.

o Increase the maximum heap size, -Xmx.

o If the application uses JNI, make sure JNI references are properly cleared. All objects being referenced by JNI are pinned and not moved during

 

Pinned, Dosed 객체 목록을 보는 방법

-Dibm.dg.trc.print=st_verify,st_verbose_compact 를 사용하면 stderr로 나옴

 

Pinned 객체로 인한 fragmentation인지, Dosed 객체로 인한 fragmentatin인지 확인하는 방법

 

Pinned 객체로 인한 fragmentation일 경우, 조치 방법

st_verify 결과값을 사용해서, kCluster, pCluster 값을 조정한다.

kCluster 권장값은 class 개수 * 1.1

pCluster 권장값은 ......


원문출처 : http://blog.naver.com/bart95/70007480039

by 이환호



posted by lovelywas

JVM의 Heap 메모리 정보 확인 및 Heap dump를 생성하는 명령어

Unix/Linux의 경우 kill -3 <PID> 명령어를 이용하여 JVM의 Heap dump 생성이 가능하지만 Windows의 경우 서비스로 기동되어 있을 경우 command console이 없어 thread dump 및 Heap dump 생성이 어려움

이럴 경우 jmap 명령어를 활용하여 Heap dump를 생성할 수 있다.


- 필요한 환경 

  1. UNIX / Linux / Windows : JAVA 6 이상


- 명령어 위치 ( JAVA_HOME은 JDK 설치 폴더를 의미함)

  $JAVA_HOME/bin/jmap.exe


- 명령어 사용법

  > jps -v 

    ... JVM의 PID를 확인 ...

heapdump 파일 생성

 > jmap -dump:format=b,file=<파일명> <PID>

실시간 heap 메모리 사용 정보 확인

  > jmap -heap <PID>


  예시)

  > jps -v 

    4360 jar -XX:+HeapDumpOnOutOfMemoryError -Xms512m -Xmx512m -XX:NewSize=128m

  > jmap -dump:format=b,file=heapdump.hprof 4360

     ..

  >jmap -heap 4360

Attaching to process ID 4360, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 24.51-b03

using thread-local object allocation.

Parallel GC with 4 thread(s)

Heap Configuration:

  MinHeapFreeRatio = 40

  MaxHeapFreeRatio = 70

  MaxHeapSize      = 536870912 (512.0MB)

  NewSize          = 134217728 (128.0MB)

  MaxNewSize       = 134217728 (128.0MB)

  OldSize          = 5439488 (5.1875MB)

  NewRatio         = 2

  SurvivorRatio    = 8

  PermSize         = 21757952 (20.75MB)

  MaxPermSize      = 85983232 (82.0MB)

  G1HeapRegionSize = 0 (0.0MB)

Heap Usage:

PS Young Generation

Eden Space:

  capacity = 108003328 (103.0MB)

  used     = 48275768 (46.03936004638672MB)

  free     = 59727560 (56.96063995361328MB)

  44.69840781202594% used

From Space:

  capacity = 13107200 (12.5MB)

  used     = 13084416 (12.478271484375MB)

  free     = 22784 (0.021728515625MB)

  99.826171875% used

To Space:

  capacity = 13107200 (12.5MB)

  used     = 0 (0.0MB)

  free     = 13107200 (12.5MB)

  0.0% used

PS Old Generation

  capacity = 402653184 (384.0MB)

  used     = 4650336 (4.434906005859375MB)

  free     = 398002848 (379.5650939941406MB)

  1.154923439025879% used

PS Perm Generation

  capacity = 25690112 (24.5MB)

  used     = 25371360 (24.196014404296875MB)

  free     = 318752 (0.303985595703125MB)

  98.75924246651786% used

13893 interned Strings occupying 1218656 bytes.


by 이환호

정보 출처 : http://docs.oracle.com/javase/6/docs/technotes/tools/index.html#basic

posted by lovelywas

JVM의 상세정보를 확인하는 명령어

JVM의 버전(마이너), 컴파일 버전, 경로, os 타입, 인코딩 정보 등의 상세 내용을 확인할 수 있는 jinfo 명령어에 대해서 알아보자


- 필요한 환경 

  1. UNIX / Linux / Windows: JAVA 5 이상


- 명령어 위치 ( JAVA_HOME은 JDK 설치 폴더를 의미함)

  $JAVA_HOME/bin/jinfo.exe


- 명령어 사용법

  > jps -v 

    ... JVM의 PID를 확인 ...

  > jinfo <PID> > JVMINFO.txt


  예시)

  > jps -v 

    1640 jar -XX:+HeapDumpOnOutOfMemoryError -Xms512m -Xmx512m -XX:NewSize=128m

  > jinfo.exe 1640 > JINFO.txt


JINFO.txt 파일을 확인해 보면 아래와 같은 다양한 정보를 확인해 볼 수 있다.

Java System Properties:

java.runtime.name = Java(TM) SE Runtime Environment

java.vm.version = 24.51-b03

sun.boot.library.path = C:\Program Files\Java\jdk1.7.0_51\jre\bin

java.vendor.url = http://java.oracle.com/

java.vm.vendor = Oracle Corporation

path.separator = ;

file.encoding.pkg = sun.io

java.vm.name = Java HotSpot(TM) 64-Bit Server VM

sun.os.patch.level = Service Pack 1

sun.java.launcher = SUN_STANDARD

user.script = 

user.country = KR

user.dir = D:\util\apache-jmeter-2.12\apache-jmeter-2.12\bin

java.vm.specification.name = Java Virtual Machine Specification

java.runtime.version = 1.7.0_51-b13

java.awt.graphicsenv = sun.awt.Win32GraphicsEnvironment

os.arch = amd64

java.endorsed.dirs = C:\Program Files\Java\jdk1.7.0_51\jre\lib\endorsed

line.separator = 

VM Flags:

-XX:+HeapDumpOnOutOfMemoryError -Xms512m -Xmx512m -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50 -XX:MaxTenuringThreshold=2 -XX:+CMSClassUnloadingEnabled


by 이환호


정보 출처 : http://docs.oracle.com/javase/6/docs/technotes/tools/index.html#basic

posted by lovelywas

JVM의 thread dump를 생성하는 명령어.

Unix/Linux의 경우 kill -3 <PID> 명령어를 이용하여 JVM의 thread dump 생성이 가능하지만 Windows의 경우 서비스로 기동되어 있을 경우 command console이 없어 thread dump의 생성이 어려움

이럴 경우 jstack 명령어를 활용하여 thread dump를 생성할 수 있다.


- 필요한 환경 

  1. UNIX / Linux : JAVA 5 이상

  2. Windows : JAVA 6 이상


- 명령어 위치 ( JAVA_HOME은 JDK 설치 폴더를 의미함)

  $JAVA_HOME/bin/jstack.exe


- 명령어 사용법

  > jps -v 

    ... JVM의 PID를 확인 ...

  > jstack <PID> > threadump.txt


  예시)

  > jps -v 

    1640 jar -XX:+HeapDumpOnOutOfMemoryError -Xms512m -Xmx512m -XX:NewSize=128m

  > jstack 1640 > threadump.txt

threaddump.txt 파일 오픈 시 아래와 같이 thread의 stack trace를 확인해 볼 수 있다.

 

2014-12-02 19:21:38

Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode):

"NanoOffset" daemon prio=6 tid=0x00000000096be800 nid=0x2394 waiting on condition [0x000000000dadf000]

   java.lang.Thread.State: TIMED_WAITING (sleeping)

at java.lang.Thread.sleep(Native Method)

at java.lang.Thread.sleep(Thread.java:340)

at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:360)

at org.apache.jmeter.samplers.SampleResult$NanoOffset.getOffset(SampleResult.java:1321)

at org.apache.jmeter.samplers.SampleResult$NanoOffset.run(SampleResult.java:1314)


by 이환호

정보 출처 : http://docs.oracle.com/javase/6/docs/technotes/tools/index.html#basic

posted by lovelywas

JVM의 Process ID를 확인하는 명령어.

Windows에서 "windows 작업관리자"를 이용하여 JVM의 Process ID를 확인하기는 어렵다. 이럴 경우 ProcessExplorer 툴을 설치하여 확인하거나 jps 명령어를 이용하여 확인할 수 있다.


- 필요한 환경 

  1. UNIX/Linux/Windows : JAVA 5 이상


- 명령어 위치 ( JAVA_HOME은 JDK 설치 폴더를 의미함)

  $JAVA_HOME/bin/jstack.exe


- 명령어 사용법

  > jps 

    ... JVM의 PID와 프로그램 명 확인 ..

  > jps -v

    ... JVM의 PID, 프로그램, 옵션 확인 ..


  예시)

  > jps 

   1640 Jmeter

   3336 Jps

  > jps -v

    7204 Jps -Denv.class.path=. -Dapplication.home=C:\Program Files\Java\jdk1.5.0_22 

    1640 jar -XX:+HeapDumpOnOutOfMemoryError -Xms512m -Xmx512m -XX:NewSize=128m

 by 이환호


정보 출처 : http://docs.oracle.com/javase/6/docs/technotes/tools/index.html#basic

posted by lovelywas

JVM(Java Virtual Machine) 성능 조정


출처: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tprf_tunejvm.html

Java 프로세스인 Application Server는 실행하고 서버에서 실행하는 Java 응용프로그램을 지원하기 위해 JVM(Java Virtual Machine)이 필요합니다. Application Server 구성의 일부로서 JVM의 시스템 사용을 개선시키는 설정을 미세 조정할 수 있습니다.

이 타스크 정보

JVM은 Java 기반 응용프로그램을 위한 런타임 실행 환경을 제공합니다. WebSphere Application Server는 JVM 런타임 환경과 Java 기반 서버 런타임의 조합입니다. 다른 JVM 프로바이더의 JVM에서 실행할 수 있습니다. 사용자의 Application Server가 실행 중인 JVM 프로바이더를 판별하려면 WebSphere Application Server app_server_root/java/bin 디렉토리에서 java –fullversion 명령을 발행하십시오. 또한 서버 중 하나에서 SystemOut.log를 검사할 수도 있습니다. Application Server가 시작할 때 WebSphere Application Server는 JVM 프로바이더 정보를 포함한 JVM에 관한 정보를 이 로그 파일에 기록합니다.

JVM 조정 Perspective에서 두 가지 기본 유형의 JVM이 있습니다.
  • IBM JVM
  • Solaris의 Sun HotSpot JVM 및 HP의 HP-UX용 JVM을 포함한 Sun HotSpot 기반 JVM
JVM 조정이 JVM 프로바이더에 따라 다르지만 일반 조정 개념은 모든 JVM에 적용됩니다. 일반 개념은 다음을 포함합니다.
  • 컴파일러 조정. 모든 JVM은 JIT(Just In Time) 컴파일러를 사용하여 서버 런타임 중에 Java 바이트 코드를 기본 명령어로 컴파일합니다.
  • Java 메모리 또는 힙 조정. JVM 메모리 관리 기능 또는 가비지 콜렉션이 JVM 성능 향상을 위한 가장 큰 기회 중 하나를 제공합니다.
  • 클래스 로딩 조정.

프로시저

  • 시작 성능 및 런타임 성능을 최적화하십시오.

    일부 환경에서는 런타임 성능보다 WebSphere Application Server의 시작 성능을 최적화하는 것이 더 중요합니다. 다른 환경에서는 런타임 환경을 최적화하는 것이 더 중요합니다. 기본적으로 IBM JVM은 런타임 환경을 위해 최적화되는 반면 HotSpot 기반 JVM은 시작 성능을 위해 최적화됩니다.

    Java JIT 컴파일러는 시작 또는 런타임 성능이 최적화되는지 여부에 큰 영향을 줍니다. 컴파일러가 사용하는 초기 최적화 레벨은 클래스 메소드를 컴파일하는 데 걸리는 시간과 서버를 시작하는 데 걸리는 시간에 영향을 줍니다. 더 빠른 시작을 위해 컴파일러가 사용하는 초기 최적화 레벨을 줄일 수 있습니다. 이는 클래스 메소드가 이제 더 낮은 최적화 레벨에서 컴파일되기 때문에 응용프로그램의 런타임 성능이 저하될 수 있음을 의미합니다.

    재컴파일이 더 좋은 성능을 제공할 수 있다는 컴파일러의 판단에 따라서 컴파일러가 런타임 실행 중에 클래스 메소드를 다시 컴파일할 수 있기 때문에 특정한 런타임 성능 영향 명령문을 규정하기는 어렵습니다. 궁극적으로 응용프로그램의 지속 기간이 발생하는 런타임 저하의 양에 대한 주요 영향입니다. 짧게 실행하는 응용프로그램은 메소드가 다시 컴파일되는 확률이 더 높습니다. 장기간 실행하는 응용프로그램은 메소드가 다시 컴파일될 가능성이 작습니다. IBM JVM의 기본 설정은 초기 컴파일에 대해 높은 최적화 레벨을 사용합니다. 이 동작을 변경해야 하는 경우 다음 IBM JVM 옵션을 사용할 수 있습니다.

    -Xquickstart

    이 설정은 IBM JVM이 클래스 메소드 컴파일에 대해 더 낮은 최적화 레벨을 사용하는 방법에 영향을 주며, 이는 런타임 성능을 희생하는 대신 더 빠른 서버 시작을 제공합니다. 이 매개변수가 지정되지 않는 경우 IBM JVM은 기본적으로 컴파일에 대해 높은 초기 최적화 레벨로 시작합니다. 이 설정은 서버 시작은 더 느린 대신 더 빠른 런타임 성능을 제공합니다.

    기본값: 높은 초기 컴파일러 최적화 레벨
    권장: 높은 초기 컴파일러 최적화 레벨
    사용법: -Xquickstart는 더 빠른 서버 시작 시간을 제공할 수 있습니다.

    Sun의 Hotspot 기술을 기초로 하는 JVM은 초기에 낮은 최적화 레벨에서 클래스 메소드를 컴파일합니다. 다음 JVM 옵션을 사용하여 이 동작을 변경하십시오.

    -server

    Sun의 Hotspot 기술을 기초로 하는 JVM은 초기에 낮은 최적화 레벨에서 클래스 메소드를 컴파일합니다. 이들 JVM은 단순 컴파일러 및 최적화 JIT 컴파일러를 사용합니다. 일반적으로 단순 JIT 컴파일러가 사용됩니다. 그러나 이 옵션을 사용하여 최적화 컴파일러를 사용되는 컴파일러로 만들 수 있습니다. 이 변경은 서버의 성능을 크게 증가시키지만 최적화 컴파일러가 사용될 때 서버가 시작하는 데 더 오래 걸립니다.

    기본값: 단순 컴파일러
    권장: 최적화 컴파일러
    사용법: -server가 최적화 컴파일러를 사용 가능하게 합니다.
  • 힙 크기를 설정하십시오. 다음 명령행 매개변수가 힙 크기 설정에 유용합니다.
    • -Xms

      이 설정은 Java 힙의 초기 크기를 제어합니다. 이 매개변수를 적절하게 조정하면 가비지 콜렉션의 오버헤드를 줄여서 서버 응답 시간 및 처리량을 개선합니다. 일부 응용프로그램의 경우, 이 옵션에 대한 기본 설정이 너무 낮아서 사소한 가비지 콜렉션의 수가 높아질 수 있습니다.

      기본값: 256 MB
      권장: 워크로드에 특정하지만, 기본값보다 높습니다.
      사용법: -Xms256m은 초기 힙 크기를 256MB로 설정합니다.
    • -Xmx

      이 설정은 Java 힙의 최대 크기를 제어합니다. 이 매개변수를 적절하게 조정하면 가비지 콜렉션의 오버헤드를 줄여서 서버 응답 시간 및 처리량을 개선할 수 있습니다. 일부 응용프로그램의 경우, 이 옵션에 대한 기본 설정이 너무 낮아서 사소한 가비지 콜렉션의 수가 높아질 수 있습니다.

      기본값: 512 MB
      권장: 워크로드에 특정하지만, 기본값보다 높습니다.
      사용법: -Xmx512m은 최대 힙 크기를 512MB로 설정합니다.
    • -Xlp

      이 설정은 IBM JVM과 함께 사용되어 대형 페이지를 사용하는 힙을 할당할 수 있습니다. 그러나 이 설정을 사용하는 경우 운영 체제가 대형 페이지를 지원하도록 구성되어야 합니다. 대형 페이지를 사용하면 힙 메모리를 추적하기 위해 필요한 CPU 오버헤드를 줄일 수 있으며 또한 더 큰 힙의 작성을 허용할 수 있습니다.

      운영 체제 조정에 대한 자세한 정보 운영 체제 성능 조정 의 내용을 참조하십시오.

    사용자가 힙에 대해 지정해야 하는 크기는 시간에 따른 힙 사용량에 따라 다릅니다. 힙 크기가 자주 변경되는 경우에는 Xms 및 Xmx 매개변수에 동일한 값을 지정하는 경우 성능을 향상시킬 수 있습니다.

  • IBM JVM의 가비지 콜렉터를 조정하십시오.

    Java -X 옵션을 사용하여 메모리 옵션의 목록을 참조하십시오.

    • -Xgcpolicy

      gcpolicy를 optthruput으로 설정하면 동시 마크가 사용 불가능합니다. 오류가 있는 응용프로그램 응답 시간으로 표시되는 일시정지 시간 문제점이 있지 않은 경우 이 옵션을 사용하여 최상의 처리량을 가져와야 합니다. gcpolicy를 optavgpause로 설정하면 동시 표시가 기본값과 함께 사용 가능하게 됩니다. 이 설정은 정상 가비지 콜렉션에 의해 유발되는 오류가 있는 응용프로그램 응답 시간을 완화시킵니다. 그러나 이 옵션은 전체 처리량을 줄일 수 있습니다.

      기본값: optthruput
      권장: optthruput
      사용법: Xgcpolicy:optthruput
    • -Xnoclassgc

      기본적으로 JVM은 클래스의 활동하는 인스턴스가 없을 때 메모리에서 해당 클래스를 로드 해제하지만, 이는 성능을 저하시킬 수 있습니다. 클래스 가비지 콜렉션을 끄면 동일한 클래스를 여러 번 로드 및 로드 해제하는 오버헤드를 제거합니다.

      클래스가 더 이상 필요없는 경우 클래스가 힙에서 차지하는 공간은 일반적으로 새 오브젝트의 작성을 위해 사용됩니다. 그러나 클래스의 새 인스턴스를 작성하여 요청을 처리하는 응용프로그램이 있고 해당 응용프로그램에 대한 요청이 임의 시간에 오는 경우, 이전 요청자가 완료될 때 다음 요청이 나타날 때만 클래스를 다시 인스턴스화하기 위해 정상 클래스 가비지 콜렉션이 클래스가 차지했던 힙 공간을 사용 가능하게 해서 이 클래스를 지우는 것이 가능합니다. 이 상황에서는 이 옵션을 사용하여 클래스의 가비지 콜렉션을 사용하지 않을 수 있습니다.

      기본값: 클래스 가비지 콜렉션 사용 가능
      권장: 클래스 가비지 콜렉션 사용 불가능
      사용법: Xnoclassgc가 클래스 가비지 콜렉션을 사용 불가능하게 합니다.
    추가 정보에 대해서는 다음 DeveloperWorks 항목을 확인하십시오.
  • Sun JVM의 가비지 콜렉터를 조정하십시오.

    Solaris 플랫폼에서 WebSphere Application Server는 IBM JVM이 아니라 Sun Hotspot JVM에서 실행합니다. 성능 최적화 기능을 이용하기 위해서는 Sun JVM과 함께 올바른 조정 매개변수를 사용하는 것이 중요합니다.

    Sun HotSpot JVM은 최적 성능을 달성하기 위해 세대별 가비지 콜렉션에 의존합니다. 다음 명령행 매개변수가 가비지 콜렉션 조정에 유용합니다.

    • -XX:SurvivorRatio

      Java 힙은 예전에 생성된(old) 즉, 오브젝트용 섹션과 최근에 생성된(young) 오브젝트용 섹션으로 나뉘어집니다. 최근에 생선된(young) 오브젝트용 섹션은 다시 새 오브젝트가 할당되는 섹션(eden)과 여전히 사용 중인 새 오브젝트가 이전 오브젝트로 승격되기 전에 처음 몇 번의 가비지 콜렉션에서 살아남는 섹션(감독자 공간)으로 나뉘어집니다. 감독자 비율은 힙의 최근에 생선된(young) 오브젝트 섹션에서 감독자 공간에 대한 eden의 비율입니다. 이 설정을 늘리면 높은 오브젝트 작성 및 낮은 오브젝트 보존을 갖는 응용프로그램에 대해 JVM을 최적화합니다. WebSphere Application Server가 다른 응용프로그램보다 더 많은 중간 및 오래 활동하는 오브젝트를 생성하므로, 이 설정은 기본값보다 낮아야 합니다.

      기본값: 32
      권장: 16
      사용법: -XX:SurvivorRatio=16
    • -XX:PermSize

      영구 생성을 위해 예약되는 힙의 섹션은 JVM에 대한 모든 반사 데이터를 보유합니다. 이 크기는 많은 클래스를 동적으로 로드하고 로드 해제하는 응용프로그램의 성능을 최적화하기 위해 늘려야 합니다. 이 설정을 값 128MB로 설정하면 힙의 이 파트를 증가시키는 오버헤드를 제거합니다.

      권장: 128 MB
      사용법: XX:PermSize=128m은 perm 크기를 128MB로 설정합니다.
    • -Xmn

      이 설정은 젋음 세대가 힙에서 소비하도록 허용되는 공간을 제어합니다. 이 매개변수를 적절하게 조정하면 가비지 콜렉션의 오버헤드를 줄여서 서버 응답 시간 및 처리량을 개선할 수 있습니다. 이 옵션에 대한 기본 설정은 일반적으로 너무 낮아서 사소한 가비지 콜렉션의 수를 높게 만듭니다. 이 설정을 너무 높게 설정하면 JVM이 주요(또는 전체) 가비지 콜렉션만 수행하게 만들 수 있습니다. 이들은 대개 몇 초가 걸리며 서버의 전체 성능에 극히 불리합니다. 이 상황을 피하기 위해 이 설정을 전체 힙 크기의 절반 이하로 유지해야 합니다.

      기본값: 2228224 바이트
      권장: 대략 총 힙 크기의 1/4
      사용법: -Xmn256m은 크기를 256MB로 설정합니다.
    • -Xnoclassgc

      기본적으로 JVM은 클래스의 활동하는 인스턴스가 없을 때 메모리에서 해당 클래스를 로드 해제하지만, 이는 성능을 저하시킬 수 있습니다. 클래스 가비지 콜렉션을 끄면 동일한 클래스를 여러 번 로드 및 로드 해제하는 오버헤드를 제거합니다.

      클래스가 더 이상 필요없는 경우 클래스가 힙에서 차지하는 공간은 일반적으로 새 오브젝트의 작성을 위해 사용됩니다. 그러나 클래스의 새 인스턴스를 작성하여 요청을 처리하는 응용프로그램이 있고 해당 응용프로그램에 대한 요청이 임의 시간에 오는 경우, 이전 요청자가 완료될 때 다음 요청이 나타날 때만 클래스를 다시 인스턴스화하기 위해 정상 클래스 가비지 콜렉션이 클래스가 차지했던 힙 공간을 사용 가능하게 해서 이 클래스를 지우는 것이 가능합니다. 이 상황에서는 이 옵션을 사용하여 클래스의 가비지 콜렉션을 사용하지 않을 수 있습니다.

      기본값: 클래스 가비지 콜렉션 사용 가능
      권장: 클래스 가비지 콜렉션 사용 불가능
      사용법: Xnoclassgc가 클래스 가비지 콜렉션을 사용 불가능하게 합니다.

    Sun JVM 조정에 대한 추가 정보는 Performance Documentation for the Java HotSpot VM를 확인하십시오.

  • HP JVM의 가비지 콜렉터를 조정하십시오.

    HP JVM은 최적 성능을 달성하기 위해 세대별 가비지 콜렉션에 의존합니다. 다음 명령행 매개변수가 가비지 콜렉션 조정에 유용합니다.

    • -Xoptgc

      이 설정은 수명이 짧은 많은 오브젝트를 갖는 응용프로그램에 대해 JVM을 최적화합니다. 이 매개변수가 지정되지 않으면 JVM은 대개 주요(전체) 가비지 콜렉션을 수행합니다. 전체 가비지 콜렉션은 수 초가 걸릴 수 있으며 서버 성능을 크게 저하시킬 수 있습니다.

      기본값: off
      권장: on
      사용법: -Xoptgc는 최적화된 가비지 콜렉션을 사용 가능하게 합니다.
    • -XX:SurvivorRatio

      Java 힙은 예전에 생성된(old) 즉, 오브젝트용 섹션과 최근에 생성된(young) 오브젝트용 섹션으로 나뉘어집니다. 최근에 생선된(young) 오브젝트용 섹션은 다시 새 오브젝트가 할당되는 섹션(eden)과 여전히 사용 중인 새 오브젝트가 이전 오브젝트로 승격되기 전에 처음 몇 번의 가비지 콜렉션에서 살아남는 섹션(감독자 공간)으로 나뉘어집니다. 감독자 비율은 힙의 최근에 생선된(young) 오브젝트 섹션에서 감독자 공간에 대한 eden의 비율입니다. 이 설정을 늘리면 높은 오브젝트 작성 및 낮은 오브젝트 보존을 갖는 응용프로그램에 대해 JVM을 최적화합니다. WebSphere Application Server가 다른 응용프로그램보다 더 많은 중간 및 오래 활동하는 오브젝트를 생성하므로, 이 설정은 기본값보다 낮아야 합니다.

      기본값: 32
      권장: 16
      사용법: -XX:SurvivorRatio=16
    • -XX:PermSize

      영구 생성을 위해 예약되는 힙의 섹션은 JVM에 대한 모든 반사 데이터를 보유합니다. 이 크기는 많은 클래스를 동적으로 로드하고 로드 해제하는 응용프로그램의 성능을 최적화하기 위해 늘려야 합니다. 128MB의 값을 지정하면 힙의 이 파트를 증가시키는 오버헤드를 제거합니다.

      기본값: 0
      권장: 128MB
      사용법: -XX:PermSize=128m은 PermSize를 128MB로 설정합니다.
    • -XX:+ForceMmapReserved

      기본적으로 Java 힙은 "지연 스왑" 할당됩니다. 이는 필요할 때 메모리 페이지를 할당하여 스왑 공간을 절약하지만 또한 4KB 페이지의 사용을 강제합니다. 이 메모리 할당은 대형 힙 시스템에서 힙을 수십만개의 페이지에 분산시킬 수 있습니다. 이 명령은 "지연 스왑"을 사용 불가능하게 하고 운영 체제가 더 큰 메모리 페이지를 사용할 수 있게 하여 Java 힙을 구성하는 메모리에 대한 액세스를 최적화합니다.

      기본값: off
      권장: on
      사용법: -XX:+ForceMmapReserved는 "지연 스왑"을 사용 안합니다.
    • -Xmn

      이 설정은 젋음 세대가 힙에서 소비하도록 허용되는 공간을 제어합니다. 이 매개변수를 적절하게 조정하면 가비지 콜렉션의 오버헤드를 줄여서 서버 응답 시간 및 처리량을 개선할 수 있습니다. 이 옵션에 대한 기본 설정은 일반적으로 너무 낮아서 사소한 가비지 콜렉션의 수를 높게 만듭니다.

      기본값: 기본값 없음
      권장: 대략 총 힙 크기의 3/4
      사용법: -Xmn768m은 크기를 768MB로 설정합니다.
    • 가상 페이지 크기

      JVM(Java Virtual Machine) 명령어 및 데이터 페이지 크기를 64MB로 설정하면 성능이 향상될 수 있습니다.

      기본값: 4MB
      권장: 64MB
      사용법: 다음 명령을 사용하십시오. 명령 출력이 프로세스 실행 파일의 현재 운영 체제 특성을 제공합니다.
      chatr +pi64M +pd64M /opt/WebSphere/
      AppServer/java/bin/PA_RISC2.0/
      native_threads/java
    • -Xnoclassgc

      기본적으로 JVM은 클래스의 활동하는 인스턴스가 없을 때 메모리에서 해당 클래스를 로드 해제하지만, 이는 성능을 저하시킬 수 있습니다. 클래스 가비지 콜렉션을 끄면 동일한 클래스를 여러 번 로드 및 로드 해제하는 오버헤드를 제거합니다.

      클래스가 더 이상 필요없는 경우 클래스가 힙에서 차지하는 공간은 일반적으로 새 오브젝트의 작성을 위해 사용됩니다. 그러나 클래스의 새 인스턴스를 작성하여 요청을 처리하는 응용프로그램이 있고 해당 응용프로그램에 대한 요청이 임의 시간에 오는 경우, 이전 요청자가 완료될 때 다음 요청이 나타날 때만 클래스를 다시 인스턴스화하기 위해 정상 클래스 가비지 콜렉션이 클래스가 차지했던 힙 공간을 사용 가능하게 해서 이 클래스를 지우는 것이 가능합니다. 이 상황에서는 이 옵션을 사용하여 클래스의 가비지 콜렉션을 사용하지 않을 수 있습니다.

      기본값: 클래스 가비지 콜렉션 사용 가능
      권장: 클래스 가비지 콜렉션 사용 불가능
      사용법: Xnoclassgc가 클래스 가비지 콜렉션을 사용 불가능하게 합니다.

    HP 가상 시스템 조정에 대한 추가 정보는 Java technology software HP-UX 11i를 확인하십시오.

  • HP-UX를 위해 HP의 JVM을 조정하십시오. 다음 옵션을 설정하여 응용프로그램 성능을 개선하십시오.

    -XX:SchedulerPriorityRange=SCHED_NOAGE 
    -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.DevPollSelectorProvider
    -XX:-ExtraPollBeforeRead
  • 특정 상황에서 수행되는 덤프 수를 제한하십시오.

    특정 오류 상황에서는 복수 Application Server 스레드가 실패하여 JVM이 해당 스레드 각각에 TDUMP를 요청합니다. 이러한 경우 많은 수의 TDUMP가 동시에 수행되어 보조 기억장치 부족과 같은 다른 문제점이 발생할 수 있습니다. JAVA_DUMP_OPTS 환경 변수를 사용하여 특정 상황에서 JVM이 생성할 덤프 수를 표시할 수 있습니다. 그러나 Application Server에서 실행 중인 응용프로그램의 com.ibm.jvm.Dump.SystemDump() 호출로 인해 생성되는 TDUMPS 수에는 영향을 주지 않습니다.

    예를 들어, JAVA_DUMP_OPTS 변수를 다음 옵션과 함께 지정하는 경우 JVM의 역할은 다음과 같습니다.
    • TDUMP 토큰 수를 1로 제한합니다.
    • JAVADUMP 토큰 수를 최대값 3으로 제한합니다.
    • INTERRUPT가 발생하는 경우 문서를 캡처하지 않습니다.
    JAVA_DUMP_OPTS=ONANYSIGNAL(JAVADUMP[3],SYSDUMP[1]),ONINTERRUPT(NONE) 

    JAVA_DUMP_OPTS 환경 변수 사용에 대한 자세한 정보는 IBM 개발자 킷 진단 안내서를 참조하십시오.

다음에 수행할 내용

추가 조정 정보는 Java 메모리 성능 조정 팁 의 내용을 참조하십시오. 

 

                                                                                                                                 by 김영준

[

posted by lovelywas

자바 1.7 버전이후 지원하는 G1GC에 대해서 알아보겠습니다.

장점

1. GC에 의한 Pause Time이 없는 compact한 빈공간

2. GC의 Pause Time 예측가능

3. 처리성능 향상

4. heap사용율 감소

옵션

-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

-XX:MaxGCPauseMillis =50 (for a pause time target of 50ms)
-XX:GCPauseIntervalMillis =200 (for a pause interval target of 200ms)

by 김영준

--XX:+UnlockExperimentalVMOptions -XX:+UseG1GCXX:+UnlockExperimentalVMOptions -

posted by lovelywas

JDK를 설치할 경우 1.6 버전부터 기본적인 모니터링 및 분석툴을 제공해 준다.

제공하는 툴 중 JVM의 GC(Gabage Collect) 상태를 Command line에서 알 수 있는 툴에 대해 알아보자

- 툴 이름 : jstat

- 경로 : $JAVA_HOME/bin/jstat

- 메뉴얼 : http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstat.html

 

● 툴 사용법

 jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]]

jstat [일반옵션 | 출력옵션 <vmid> [간격[수행횟수]]]

* 일반옵션

  -help : 도움말

  -options : 표시할 통계의 항목의 리스트를 보여준다.

* 출력옵션

  -t : 출력의 가장 첫번째 컬럼에 timestame 컬럼으로 출력

  -h : 헤드라인의 출력될 라인수( 예 : -h 20  옵션을 지정 시 20번째 라인마다 헤드라인 출력) 

  <vmid> : 모니터링 하고자 하는 JVM의 PID

  <interval> : 모니터링 정보 출력 주기. 단위는 초(default) | 밀리세컨드(s|ms)

  <count> : 모니터링의 횟수

● 툴 사용 예시 (가장 많이 사용되는 gcutil )

C:\Program Files\Java\jdk1.6.0_45\bin>jstat -gcutil -t -h5 1112 10s 15
Timestamp         S0     S1     E      O      P     YGC     YGCT    FGC    FGCT    GCT
         3648.1   0.00  95.62  28.45  64.88  99.44     17    0.095     0    0.000    0.095
         3658.1   0.00  95.62  28.79  64.88  99.44     17    0.095     0    0.000    0.095
         3668.1   0.00  95.62  28.79  64.88  99.44     17    0.095     0    0.000    0.095
         3678.1   0.00  95.62  28.79  64.88  99.44     17    0.095     0    0.000    0.095
         3688.1   0.00  95.62  28.79  64.88  99.44     17    0.095     0    0.000    0.095
Timestamp         S0     S1     E      O      P     YGC     YGCT    FGC    FGCT    GCT
         3698.2   0.00  95.62  28.79  64.88  99.44     17    0.095     0    0.000    0.095
         3708.2   0.00  95.62  29.12  64.88  99.44     17    0.095     0    0.000    0.095
         3718.2   0.00  95.62  29.12  64.88  99.44     17    0.095     0    0.000    0.095
         3728.2   0.00  95.62  29.12  64.88  99.44     17    0.095     0    0.000    0.095
         3738.2   0.00  95.62  29.12  64.88  99.44     17    0.095     0    0.000    0.095
Timestamp         S0     S1     E      O      P     YGC     YGCT    FGC    FGCT    GCT
         3748.2   0.00  95.62  29.12  64.88  99.44     17    0.095     0    0.000    0.095
         3758.2   0.00  95.62  29.12  64.88  99.44     17    0.095     0    0.000    0.095
         3768.2   0.00  95.62  29.46  64.88  99.44     17    0.095     0    0.000    0.095
         3778.2   0.00  95.62  29.46  64.88  99.44     17    0.095     0    0.000    0.095
         3788.2   0.00  95.62  29.46  64.88  99.44     17    0.095     0    0.000    0.095

● 헤드라인의 각 항목별 설명

Timestamp : JVM이 기동된 시간부터의 Timestamp
S0 : Survivor 0 영역
S1 : Survivor 1 영역
E : Eden 영역, Young Area (Miner GC)
O : Old 영역, (Mager GC)
P : Permanent Area
YGC : Young GC Count
YGCT : Young GC Time Total
FGC : Full GC Count
FGCT : Full GC Time Total
GCT : Young GC + Full GC 

jstat 툴을 이용하면 Windows환경 또는 GC 로그를 설정해 놓지 않은 환경에서 JVM의 상태를 확인 할 수 있어서 자주 사용하는 툴이므로 사용방법을 꼭~~ 기억해 두자

by 이환호

posted by lovelywas

Sun Hotspot JVM 반드시 Command Line에서 JVM Option 지정해주어야 하는 반면, IBM JVM에서는 다음과 같은 가지 방법으로 Option 지정할 있다.

*   Command Line: java -Xgcpolicy:optthruput 같은 형태로 지정

*   Options File: –Xoptionsfile 옵션을 이용해서 Option 모아둔 Text File 지정. Optionsfile 다음과 같은 형태이다.

#My options file

-X<option1>

-X<option2>=\<value1>,\

      <value2>

-D<sysprop1>=<value1>

*   IBM_JAVA_OPTIONS 환경변수: IBM_JAVA_OPTIONS 환경변수에 값을 지정(: IBM_JAVA_OPTIONS=-X<option1> -X<option2>=<value1>)

 

Standard Options

Option

Description

-memorycheck:<optiton>

JVM 내부에서 발생하는 Memory Leak 추적하기 위한 용도로 사용된다. JVM 기술지원 엔지니어들이 사용하는 용도로 보면 정확한다. JVM 자체는 C/C++ 구현되었다. 따라서 JVM 내부에서 발생하는 Memory Leak Java에서 발생하는 것과는 달리 진정한 의미에서는 Memory Leak으로 이해할 있다. 다음과 같은 옵션들이 제공된다(IBM JVM Diagnositics Guide에서 발췌)

*   all - The default if just -memorycheck is used. Enables checking of all allocated and freed blocks on every free and allocate call. This check of the heap is the most thorough and should cause the JVM to exit on nearly all memory-related problems very soon after they are caused. This option has the greatest impact on performance.

*   quick - Enables block padding only. Used to detect basic heap corruption. Pads every allocated block with sentinel bytes, which are verified on every allocate and free. Block padding is faster than the default of checking every block, but is not as effective.

*   nofree - Keeps a list of already used blocks instead of freeing memory. This list is checked, along with currently allocated blocks, for memory corruption on every allocation and deallocation. Use this option to detect a dangling pointer (a pointer that is "dereferenced" after its target memory is freed). This option cannot be reliably used with long-running applications (such as WAS), because "freed" memory is never reused or released by the JVM.

*   failat=<number of allocations> - Causes memory allocation to fail (return NULL) after <number of allocations>. Setting <number of allocations> to 13 will cause the 14th allocation to return NULL. Deallocations are not counted. Use this option to ensure that JVM code reliably handles allocation failures. This option is useful for checking allocation site behavior rather than setting a specific allocation limit.

*   skipto=<number of allocations> - Causes the program to check only on allocations that occur after <number of allocations>. Deallocations are not counted. Used to speed up JVM startup when early allocations are not causing the memory problem. As a rough estimate, the JVM performs 250+ allocations during startup.

*   callsite=<number of allocations> - Prints callsite information every <number of allocations>. Deallocations are not counted. Callsite information is presented in a table with separate information for each callsite. Statistics include the number and size of allocation and free requests since the last report, and the number of the allocation request responsible for the largest allocation from each site. Callsites are presented as sourcefile:linenumber for C code and assembly function name for assembler code. Callsites that do not provide callsite information are accumulated into an "unknown" entry.

*   zero - Newly allocated blocks are set 0 instead of being filled with the 0xE7E7xxxxxxxxE7E7 pattern. Setting to 0 helps you to determine whether a callsite is expecting zeroed memory (in which case the allocation request should be followed by memset(pointer, 0, size)).

-showversion

Java 버전과 기본적인 사용법에 대한 정보를 제공한다.

-verbose:<option>

Option 따라 상세 정보를 출력한다. 다음과 같은 옵션이 제공된다.

*   class - Class Loading 정보를 Standard Err 출력한다. 출력 예는 아래와 같다.

class load: java/io/FilePermission

class load: java/io/FilePermissionCollection

class load: java/security/AllPermission

...

class load: test

class load: test from: file:/C:/Documents/Java_Test/GC%20dump/

*  dynload - Class Loading 대한 매우 상세한 정보를 제공한다. 클래스명, 클래스 크기, 로딩 시간등의 정보를 포함한다. 출력 예는 아래와 같다.

<  Class size 6594; ROM size 7056; debug size 0>

<  Read time 128 usec; Load time 126 usec; Translate time 222 usec>

<Loaded java/security/BasicPermissionCollection from c:\IBM\WebSphere\AppServer\java\jre\lib\core.jar>

<  Class size 4143; ROM size 3264; debug size 0>

<  Read time 103 usec; Load time 81 usec; Translate time 117 usec>

<Loaded java/security/Principal from c:\IBM\WebSphere\AppServer\java\jre\lib\core.jar>

<  Class size 239; ROM size 248; debug size 0>

<  Read time 44 usec; Load time 23 usec; Translate time 20 usec>

<Loaded test>

<  Class size 370; ROM size 448; debug size 0>

<  Read time 0 usec; Load time 28 usec; Translate time 39 usec>

*  gc - GC 작업에 대한 정보를 제공한다. 자세한 내용은 GC Dump 참조한다.

*  jni - JNI 호출에 대한 정보를 제공한다. 출력 예는 아래와 같다.

<JNI ReleaseStringChars: buffer=41EC45B8>

<JNI GetStaticMethodID: gc_dump.main ([Ljava/lang/String;)V>

<JNI GetMethodID: java/lang/reflect/Method.getModifiers ()I>

<JNI GetMethodID: java/lang/String.<init> ([B)V>

<JNI FindClass: java/lang/Object>

<JNI GetMethodID: java/lang/Object.finalize ()V>

<JNI FindClass: java/lang/ref/Reference>

<JNI GetMethodID: java/lang/ref/Reference.enqueueImpl ()Z>

*   sizes - Memory 사용과 관련된 설정값을 출력한다. 출력 예는 아래와 같다.

 -Xmca32K              RAM class segment increment

 -Xmco128K            ROM class segment increment

 -Xmns0K                initial new space size

 -Xmnx0K                maximum new space size

 -Xms4M                 initial memory size

 -Xmos4M               initial old space size

 -Xmox1047608K     maximum old space size

 -Xmx1047608K       memory maximum

 -Xmr16K               remembered set size

 -Xmso32K             OS thread stack size

 -Xiss2K                java thread stack initial size

 -Xssi16K              java thread stack increment

 -Xss256K             java thread stack maximum size

 -Xscmx16M          shared class cache size

*   stacks - Thread 별로 Java/C Stack 사용 크기를 출력한다. 출력 예는 아래와 같다.

JVMVERB000I Verbose stack: "Thread-1" used 188/3756 bytes on Java/C stacks

JVMVERB000I Verbose stack: "Thread-2" used 516/3756 bytes on Java/C stacks

JVMVERB000I Verbose stack: "main" used 1368/0 bytes on Java/C stacks

JVMVERB000I Verbose stack: "Finalizer thread" used 456/2308 bytes on Java/C stacks

JVMVERB000I Verbose stack: "Gc Slave Thread" used 232/3060 bytes on Java/C stacks

Non-Standard Options

Option

Default

Description

-Xalwaysclassgc

-Xclassgc 옵션에 의해 결정됨

Global Collection 발생할 Class GC 수행할 지의 여부를 지정한다. classgc 옵션과 동일한 값이며, Default True이다.

-Xbootclasspath

Sun JVM bootclasspath 옵션과 동일

-Xcheck:jni

False

Sun JVM check:jni 옵션과 동일

-Xclassgc

True

Classloader 변했을 때만 Class GC 수행할 지의 여부를 결정한다.

-Xcodecache<size>

OS/Hardware Architecture 따라 결정됨

-Xcomp

-Xjit:count=0 옵션을 사용한 것과 동일. z/OS에서만 사용되며, deprecated 옵션이다.

-Xcompactexplicitgc

False

System.gc() 호출에 의한 Explicit GC 발생했을 경우 항상 Compaction 수행할 지의 여부를 결정한다. Sun Hotspot JVM 경우에는 System.gc() 호출이 발생할 경우 반드시 Full GC 수행한다. 반면 IBM JVM 경우에는 이전 GC 작업에서 Compaction 발생하지 않은 경우에만 Compaction 수행한다.

-Xcompactgc

False

System GC Global GC 발생할 때마다 Compaction 수행한다.

-Xconcurrentbackground

1

Response Time Collector에서 Concurrent Mark 수행할 Background Thread 개수를 지정한다. Concurrent Background Thread Application Thread 성능을 다소 저하시킬 있으므로 하나만 구동하는 것이 바람직하다. , Concurrent Mark 작업이 진행되지 않아 문제가 생기는 경우에는 값을 키우는 것이 해결책이 있다.

-Xconcurrentlevel<value>

-Xconmeter<option>

-Xdisableexcessivegc

False

GC 작업에 지나치게 많은(Excessive) 시간이 소요된 경우에 Out Of Memory Error 유발하지 않도록 지정한다.

-Xdisableexplicitgc

False

System.gc() 호출에 의한 GC 작업을 비활성화한다. 옵션을 사용하면 System.gc() 호출하더라도 GC 작업이 발생하지 않는다. RMI 의한 불필요한 GC 작업이나 사용자의 실수에 의한 강제적인 GC 작업을 방지하고자 하는 목적으로 사용된다.

-Xdisablejavadump

False

Java Dump 생성을 비활성화시킨다. IBM JVM 치명적인 Error Signal 받으면 Java Dump 생성함으로써 사후 문제를 디버깅할 있도록 한다. 특정 문제로 인해 지나치게 많은 Dump 생성될 옵션을 비활성시키는 경우가 있다.

-Xdisablestringconstantgc

False

Interned String 대한 GC 작업을 비활성화한다.

-Xenableexcessivegc

True

GC 작업에 지나치게 많은(Excessive) 시간이 소요된 경우에 Out Of Memory Error 유발하도록 지정한다. disableexcessivegc 반대의 역할을 한다.

-Xenablestringconstantgc

True

Interned String 대한 GC 작업을 활성화한다. disablestringconstantgc 옵션과 반대의 역할을 한다.

-Xgcpolicy<option>

optthruput

Garbage Collector 종류를 결정한다.

*  optthruput: Throughput Collector 사용한다. 처리량(Throughput) 최적화할 목적으로 사용되며, Default Collector이다.

*  optavgpause: Response Time Collector 사용한다. 응답시간(Response Time) 최적화할 목적으로 사용된다. GC 의한 Pause Time 최소하기 위해 Concurrent Mark/Sweep 작업을 수행한다. Throughput Collector 비해 처리량으로 다소(5~10%) 떨어진다.

*  gencon: Concurrent Generational Collector 사용한다. IBM JDK 1.5에서 추가되었다. Sun Hotspot JVM CMS Collector 거의 동일한 방식으로 동작하다.

*  subpool: Subpool Collector 사용한다.

-Xgcthreads<value>

CPU#

Throughput Collector Mark & Sweep 작업을 Parallel하게, 동시에 여러 Thread 사용해서 수행한다. 옵션을 통해 Parallel GC 수행할 Thread 수를 지정한다. 기본적으로 CPU 개수를 모두 활용한다. 만일 하나의 Machine에서 여러 JVM 구동하거나, 다른 종류의 Application JVM 공존하는 경우에는 값을 줄임으로써 Context Switching 의한 성능 저하를 피할 있다.

gcworkpackets

int

iss

-Xjit:<options>

True(JIT 컴파일을 사용함)

JIT 컴파일 옵션을 결정한다. <options> 지정되지 않으면 단순히 JIT 컴파일을 활성화한다. 옵션은 JIT 컴파일러의 버그로 인해 JVM 장애에 대해 Workaround 많이 활용된다.

JIT 컴파일러의 버그에 의한 JVM Crash 발생할 경우에는 다음과 같은 유형의 Error Stacktrace 기록된다.

...

TR_GlobalRegisterAllocator::perform()

TR_OptimizerImpl::performOptimization()

TR_OptimizerImpl::performOptimization()

TR_OptimizerImpl::optimize()

...

경우에는 다음과 같은 옵션을 이용해서 JIT 컴파일을 제어할 있다.

# Inlining 비활성화한다.

-Xjit:disableInlining

-Xjit:{java/lang/Math.max(II)I}(disableInlining)

 

# 특정 메소드를 Optimization에서 제외한다.

-Xjit:exclude={java/lang/Math.max(II)I} ...

아래 옵션들은 JIT 컴파일러에 문제가 발생한 경우 이를 쉽제 추적하고자 사용된다.

count=<n>

   <n> 수행에서 Method JIT 컴파일한다. JIT 문제를 추적할 때는 "0" 값을 사용함으로써 보다 빨리 컴파일이 이루어지도록 한다.   

optlevel=[noOpt | cold | warm | hot | veryHot | scorching]

   [비최적화 ~ 최고 최적화]까지 JIT 컴파일에 의한 최적화 레벨을 지적한다.

verbose

   JIT 컴파일 과정에서 사용된 정보와 컴파일 과정을 출력한다.

아래에 -Xjit:verbose 옵션의 출력 예가 있다. count 값은 1000, optlevel 값은 warm 기본값임을 있다.

JIT type: Testarossa (Full)

JIT options specified:

    verbose

options in effect:

    bcount=250

    catchSamplingSizeThreshold=1100

    classLoadPhaseInterval=500

    classLoadPhaseThreshold=155

    code=512 (KB)

    codepad=0 (KB)

    codetotal=0 (KB)

    count=1000

    ...

    stack=256

    target=ia32-win32

    verbose=1

 

+ (warm) java/lang/Double.doubleToRawLongBits(D)J @ 0x41630014-0x41630030

+ (warm) java/lang/System.getEncoding(I)Ljava/lang/String; @ 0x41630054-0x41630145

+ (warm) java/lang/String.hashCode()I @ 0x4163017C-0x4163024A

+ (warm) java/util/HashMap.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; @ 0x4163027C-0x416304AF

+ (warm) java/util/Locale.toLowerCase(Ljava/lang/String;)Ljava/lang/String; @ 0x416304DC-0x416307FF

...

+ (warm) java/io/FileOutputStream.writeBytes([BIILjava/io/FileDescriptor;)V @ 0x41636C34-0x41636D45|-

 

posted by DB,MW,OS OSSW(Open Source System SoftWare
TAG IBM, jvm
출처 : http://wiki.ex-em.com/index.php/JVM_Options
Standard Options
Option Description
-client Client HotSpot JVM을 사용한다. Client HotSpot JVM은 Desktop용 Application을 구동하는데 유리하다. 성능 최적화(Optimization) 과정을 간략화함으로써 Application의 시작 시간을 최소화한다.
-server Server HotSpot JVM을 사용한다. Server HotSpot JVM은 Server용 Application을 구동하는데 유리하다. 성능 최적화(Optimization)에 필요한 모든 과정을 최대한으로 수행한다. Application의 시작 시간은 느리지만, 일정 시간이 흐르면 Client HotSpot JVM에 비해 훨씬 뛰어난 성능을 보장한다.

(참고)Jdk 1.5부터는 Server-Class 머신인 경우에는 -server 옵션이 기본 적용된다. Server-Class 머신이란 2장 이상의 CPU와 2G 이상의 메모리를 갖춘 머신을 의미한다.

-d32 32bit JVM을 사용한다. 32bit JVM은 메모리를 최대 2G까지만 사용할 수 있다. 반면 일반적인 수행 성능 64bit JVM에 비해 뛰어난 경우가 많다. 따라서 큰 크기의 Java Heap을 사용하지 않는 경우에는 비록 64bit 머신이라고 하더라도 32bit JVM을 사용하는 것이 권장된다.
-d64 64bit JVM을 사용한다. 64bit JVM에서 사용가능한 메모리의 크기에는 사실상 제한이 없다. 대형 Application들의 경우 수G ~ 수십G의 Java Heap을 사용하는 경우가 많다.
-agentlib:<libname>[=<options>] Native Agent Library를 로딩한다. Native Agent Library란 JVMPI/JVMTI를 구현한 Library를 의미하며 C/C++로 구현된다. JVM은 Unix/Linux에서는 lib<libname>.so 파일이, Windows에서는 <libname>.dll 파일을 탐색한다. 해당 파일은 현재 Directory나 PATH 변수에 등록된 Directory에 존재해야 한다.

(참조) JDK 1.4까지는 HProf를 실행시키기 위해 -Xrunhprof:option=value 옵션을 사용한다. JDK 1.5부터는 -Xagentlib:hprof=option=value 옵션이 권장된다. -Xrunhprof 옵션은 차후 없어질 수 있다.

-agentpath:<pathname>[=<options>] -agentlib 옵션과 동일한 기능이다. Library 이름 대신 Full Path 명을 준다.
-javaagent:<jarpath>[=<options>] Java Agent Library를 로딩한다. Java Agent는 Native Agent가 C/C++로 구현되는 것과 달리 Java로 구현된다. java.lang.instrument Package를 통해 Java Agent를 구현하는 필요한 Interface가 제공된다. Java Agent는 BCI를 통해 Runtime에 Class들의 Bytecode를 변경하는 방법을 통해 작업을 수행한다.

Non-Standard Options (-X)

Option Description
-Xbootclasspath[/a|/p]:<path> Boot class path를 제어한다. /a 옵션은 Boot class path의 제일 뒤에 Append, /p 옵션은 제일 앞에 Prepend한다. 일반적인 환경에서는 Boot class path를 제어할 필요가 없다. Java Core Library(rt.jar 등)등에 대해 Reverse Engineering을 수행하고 행동 방식을 변경하고자 할 경우에 주로 활용된다.
-xcheck:jni
-Xint Intepreter 모드로만 ByteCode를 실행한다. Interpreter 모드로 실행될 경우에는 JIT Compile 기능이 동작하지 않는다. 이 옵션을 활성화하면 실행 속도이 다소 저하될 수 있다. 따라서 HotSpot Compiler의 버그로 문제가 생길 때만 사용이 권장된다.
-Xnoclassgc Class Garbage Collection을 수행하지 않는다.
-Xloggc:<file> GC Log를 기록할 파일명을 지정한다. 파일명을 지정하지 않으면 Standard Out이나 Standard Error 콘솔에 출력된다. 주로 -XX:+PrintGCTimeStamps, -XX:+PrintGCDetails 옵션과 같이 사용된다.
-Xmixed Mixed 모드로 ByteCode를 실행한다. HotSpot JVM의 Default 동작 방식이며, -Xint 옵션과 상호 배타적인 옵션이다.
-Xmn<size> Young Generation이 거주하는 New Space의 크기를 지정한다. 대개의 경우 이 옵션보다는 -XX:NewRatio 옵션이나 -XX:NewSize 옵션을 많이 사용한다.
-Xms<size> Java Heap의 최초 크기(Start Size)를 지정한다. Java Heap은 -Xms 옵션으로 지정한 크기로 시작하며 최대 -Xmx 옵션으로 지정한 크기만큼 커진다. Sun HotSpt JVM 계열에서는 최초 크기와 최대 크기를 동일하게 부여할 것을 권장한다. 크기의 동적인 변경에 의한 오버 헤드를 최소화하기 위해서이다.
-Xmx<size> Java Heap의 최대 크기(Maximum Size)를 지정한다. Java Heap은 -Xms 옵션으로 지정한 크기로 시작하며 최대 -Xmx 옵션으로 지정한 크기만큼 커진다. Sun HotSpt JVM 계열에서는 최초 크기와 최대 크기를 동일하게 부여할 것을 권장한다. 크기의 동적인 변경에 의한 오버 헤드를 최소화하기 위해서이다.
-Xrunhprof[:help][:option=value,...] HProf(Heap and CPU Profiling Agent)를 실행한다. HProf는 JVMPI/JVMTI를 이용해 구현된 Sample Profiler이다. 비록 Sample에 불과하지만, 많은 경우 HProf만으로도 상당히 유용한 정보들을 얻을 수 있다.
-Xrs OS Signal사용을 최소화한다. 가령 이 옵션을 켜면 kill -3 [pid] 명령을 수행해도 Thread dump가 발생하지 않는다.
-Xss<size> 개별 Thread의 Stack Size를 지정한다. 예를 들어 Thread Stack Size가 1M이고, Thread가 최대 100개 활성화된다면, 최대 100M의 메모리를 사용하게 된다. 대부분의 경우 기본값(Default)을 그대로 사용하는 것이 바람직하다. 많은 수의 Thread를 사용하는 Application의 경우 Thread Stack에 의한 메모리 요구량이 높아지며 이로 인해 Out Of Memory Error가 발생할 수 있다. 이런 경우에는 -Xss 옵션을 이용해 Thread Stack Size를 줄여주어야 한다.

Non-Standard Options (-XX)

-XX 옵션 Boolean 유형은 접두어로 + 붙이면 활성화(Enable), - 붙이면 비활성화(Disable) 의미한다.

Option

Default

Description

-XX:+AggressiveHeap

False

그대로 Heap Aggressive(공격적)하게 사용하는 옵션이다. 옵션이 활성화되면 JVM 현재 Application Memory-Intensive 것으로 간주하고 Heap 공간을 최대한 사용하게끔 관련된 다른 옵션 값들을 결정한다. 가령 UseParallelGC 옵션을 활성화시키고, Java Heap 크기를 Physical Memory 최대치에 가깝게 설정한다.
옵션은 비록 사용하기는 간편하지만, 일반적으로 사용되지는 않는다. 대부분의 경우, 개별적인 옵션들을 이용해 세밀한 튜닝을 시도한다.

-XX:+CMSClassUnloadingEnabled

False

CMS Collector Permanent Generation 대해 GC 작업을 수행하지 않으며, Class 메타데이터에 대한 Unloading 작업 또한 수행하지 않는다. 따라서 Application 특성상 많은 수의 Class 동적으로 생성하고 Loading하는 경우에는 Permanent Generation에서 Out Of Memory Error 발생할 있다. 이런 경우에는 옵션과 함께 CMSPermGenSweepingEnabled 옵션을 사용해서 Permanent Generation 대한 GC 작업과 Class Unloading 작업을 활성화한다. JDK 1.5까지는 옵션을 모두 활성화해야 Class Unloading 이루어진다. JDK 1.6부터는 CMSPermGenSweepingEnabled 옵션을 활성화하지 않아도 옵션이 작동한다.

-XX:CMSFullGCsBeforeCompaction=<value>

-1

CMS Collector에서 Compaction(압축) 수행하기 전에 Full GC 수행할 회수를 지정한다. 일반적인 Full GC Compaction 작업을 수반한다. 반면에 CMS Collector Full GC Compaction 수행하지 않는다. 이로 인해 Heap Fragmentation 발생할 있지만, Full GC 의한 Pause Time 최소화할 있다는 장점이 있다.

옵션은 Compaction 발생 시점을 제어하는 역할을 한다. 예를 들어 값이 "1" 경우, Concurrent Full GC 아직 종료되지 않은 시점에 새로운 Concurrent Full GC 작업이 시작되면(1), Compaction 수반된다. 만일 값이 "0" 경우에는 Concurrent Full GC "항상" Compaction 수반한다. 따라서 CMS Collector 사용하는 환경에서 Heap Fragmentation 의한 문제가 발생하는 경우에는 "0" 값을 부여하는 것이 Workaround 있다.

-XX:+CMSIncrementalMode

False

Full GC 작업을 Incremental하게 진행한다. 일반적으로 CMS Collector Old Generation 어느 정도 이상 점유되면 Concurrent Full GC 작업을 시작한다. 반면 옵션이 활성화되면 Old Generation 사용률과 무관하게 백그라운드에서 점진적으로(Incremental) Old Generation 대한 GC 작업을 수행한다. 옵션을 사용하면 CMSInitiatingOccupancyFraction 옵션은 무시된다.

옵션을 활성화하면 Throughput 다소 줄어들고, Response Time 개선되는 경향이 있다. 따라서 GC 작업 Pause 줄이고 싶을 경우에 사용할 있다.

-XX:CMSInitiatingOccupancyFraction=<value>

-1

CMS Collection 시작되는 임계값을 결정한다. 만일 값이 "50"이면 Old Generation 50% 이상 사용되면 Concurre Full GC 시작된다. 값의 기본값은 "-1"이다. 경우에는 CMSTriggerRatio 옵션과 MinHeapFreeRatio 옵션이 임계치로 사용된다. 임계치의 계산 공식은 다음과 같다.

Start Ratio = 100-MinHeapFreeRatio(=40) + MinHeapFreeRatio(=40) * (CMSTriggerRatio(=80)/100) = 92
, CMSInitiatingOccupancyFraction 옵션이 지정되지 않으면 Old Generation 92% 정도 사용될 Concurrent Full GC 시작된다.
옵션을 지정하면 50%에서 시작하여, 옵션으로 지정된 값까지 점진적으로 임계값을 조정한다. 만일 임계값을 고정하고자 경우에는 UseCMSInitiatingOccupancyOnly 옵션을 활성화해야 한다.
옵션의 값이 작으면 CMS Collection 그만큼 빨리 동작하기 때문에 Promotion Failure 의한 Stop The World GC 작업이 발생할 확률이 그만큼 줄어든다.

-XX:+CMSPermGenSweepingEnabled

False

CMS Collector 기본적으로 Permanent Generation 대해 Collection 수행하지 않는다. 따라서 많은 수의 Class Loading하는 경우 Out Of Memory Error 발생할 있다. 옵션을 활성화하면 Permanent Generation 대한 Collection 수행한다. JDK 1.5까지는 옵션과 함께 CMSClassUnloadingEnabled 옵션을 활성화해야 동작한다.

-XX:CompilerCommandFile=<file>

.hotspot_compiler

Compiler Command File 위치를 지정한다.

-XX:+DisableExplicitGC

False

System.gc 호출에 의한 Explicit GC 비활성화한다. RMI 의한 Explicit GC Application에서의 Explicit GC 원천적으로 방지하고자 경우에 사용된다.

-XX:GCHeapFreeLimit=<Percentage>

5

Parallel Collector 사용할 GC도중 Out Of Memory Error 발생을 방지하는데 도움을 준다. GC 확보해야할 Free Space 하한선을 결정한다. 값은 Max Heap 크기에 대한 Free 공간 크기의 비율이며 기본값은 "5"이다. Parallel Collection 확보해야할 Free 공간 크기가 적어도 Max Heap 크기의 5% 이상이 되도록 보장하는 것이다.

-XX:GCTimeLimit=<Percentage>

90

Parallel Collector 사용할 GC도중 Out Of Memory Error 발생을 방지하는데 도움을 준다. 전체 JVM 수행시간 대비 Parallel Collection 수행 시간의 상한선를 결정한다. 기본값은 "90"이다. Parallel Collection 전체 수행 시간의 90%까지 사용할 있게 된다.

-XX:+HeapDumpOnOutOfMemoryError

False

Out Of Memory Error 발생하면 Heap Dump File 기록한다. JDK 1.6 부터 지원되는 옵션이다.

-XX:MaxGCMinorPauseMillis=<Value>

None

Minor GC 의한 Pause Time <value>ms 이하가 되게끔 Heap 크기와 기타 옵션들을 자동으로 조정하는 기능을 한다. 값은 목표값(Target)이지 고정값이 아니다. Minor GC 의한 Pause Time 경우에 Workaround 사용할 있다.

-XX:MaxGCPauseMillis=<Value>

None

GC 의한 Pause Time <value>ms 이하가 되게끔 Heap 크기와 기타 옵션들을 자동으로 조정하는 기능을 한다. MaxGCMinorPauseMillis 옵션과 마찬가지로 목표값으로서의 역할을 한다. GC 의한 Pause Time 경우에 Workaround 사용할 있다.

-XX:MaxHeapFreeRatio=<Value>

70

Heap Shrinkage 수행하는 임계치를 지정한다. 예를 들어 값이 70이면 Heap Free 공간이 70% 이상이 되면 Heap 크기가 축소된다. MinHeapFreeRatio 옵션과 함께 Heap 크기 조정을 담당한다.

-XX:MaxNewSize=<Value>

None

Young Generation 최대 크기를 지정한다. Young Generation 시작 크기는 NewSize 옵션에 의해 지정된다.

-XX:MaxPermSize=<Value>

None

Permanent Generation 최대 크기를 지정한다. Permanent Generation 시작 크기는 PermSize 옵션에 의해 지정된다. 많은 수의 Class Loading하는 Application PermSize MaxPermSize 옵션을 이용해 Permanent Generation 크기를 크게 해주는 것이 좋다. Permanent Generation 크기가 작을 경우에는 Out Of Memory Error 발생할 있다.

-XX:MinHeapFreeRatio=<Value>

40

Heap Expansion 수행하는 임계치를 지정한다. 예를 들어 값이 40이면 Heap Free 공간이 40% 미만이 되면 Heap 크기가 확대된다. MaxHeapFreeRatio 옵션과 함께 Heap 크기 조정을 담당한다.

-XX:NewRatio=<Value>

OS/JDK Version마다 다름

Young Generation Old Generation 비율을 결정한다. 예를 들어 이값이 2이면 Young:Old = 1:2 되고, Young Generation 크기는 전체 Java Heap 1/3 된다.

-XX:NewSize=<Value>

OS/JDK Version마다 다름

Young Generation 시작 크기를 지정한다. Young Generation 크기는 NewSize 옵션(시작 크기) MaxNewSize 옵션(최대 크기) 의해 결정된다.

-XX:OnError=<Command>

None

Fatal Error 발생할 경우(: Native Heap에서의 Out Of Memory Error), <Command> 지정된 OS 명령문을 수행한다. 비정상적인 JVM 장애 현상을 자세하게 분석하고자 경우에 주로 사용된다.

-XX:OnError="pmap %p"

 --> JVM에서 Fatal Error 발생하면 Process ID 대해 pmap 명령을 수행한다.

-XX:OnOutOfMemoryError=<Command>

None

Out Of Memory Error 발생할 경우, <Command> 지정된 OS 명령문을 수행한다. JDK 1.6 추가된 옵션으로, Out Of Memory Error Java에서 얼마나 보편적으로 발생하는지를 있다.

-XX:OnOutOfMemoryError="pmap %p"

 --> JVM에서 Fatal Error 발생하면 Process ID 대해 pmap 명령을 수행한다.

-XX:ParallelGCThreads=<value>

CPU 개수

Parallel Collector 사용할 경우, GC작업을 수행할 Thread 개수를 지정한다. 기본값은 CPU 개수이다. , Parallel GC 작업을 수행하기 위해 시스템 전체의 CPU 최대한 활용한다. 하나의 Machine 여러 개의 JVM 구동하는 환경이나, 하나의 Machine 여러 종류의 Application 공유해서 사용하는 환경에서는 옵션의 값을 낮게 설정해서 GC Thread 개수를 줄임으로써 성능 개선을 꾀할 있다. Context Switching 의한 성능 저하를 막을 있기 때문이다.

-XX:PermSize=<size>

Permanent Generation 최초 크기를 지정한다. Permanent Generation 최대 크기는 MaxPermSize 옵션에 의해 지정된다. 많은 수의 Class 로딩하는 Application 크기의 Permanent Generation 필요로 한며, Permanent Generation 크기가 작아서 Class 로딩하는 못하면 Out Of Memory Error 발생한다.

-XX:PretenureSizeThreshold=<value>

0

일반적으로 Object Young Generation 최초 저장된 시간이 흐름에 따라 Tenured Generation으로 Promotion된다. 하지만, Object 크기가 Young Generation보다 경우 JVM Old Generation Object 직접 저장하기도 한다. PretenuredSizeThreshold 옵션을 이용하면 Young Generation 거치지 않고 직접 Old Generation 저장하게끔 있다. 가령 옵션의 값이 1048576(1M)이면, 1M 크기 이상의 오브젝트는 Old Generation 바로 저장된다.

크기의 오브젝트를 Old Generation 직접 저장함으로써 불필요한 Minor GC 줄이고자 하는 목적으로 사용된다.

-XX:+PrintGCApplicationStoppedTime

False

Application에서 Stop 발생한 경우 소요된 시간 정보를 기록한다. 시간은 GC 작업 자체에 의한 Stop 뿐만 아니라 JVM 내부적인 이유로 Application Thread들을 Stop 시킨 경우를 포함한다.

-XX:+PrintGCDetails

False

GC 발생시 Heap 영역에 대한 비교적 상세한 정보를 추가적으로 기록한다. 추가적인 정보는 {GC 후의 Young/Old Generation 크기, GC 후의 Permanent Generation 크기, GC 작업에 소요된 시간} 등이다. Minor GC 발생한 경우 PrintGCDetails 옵션의 적용 예는 아래와 같다.

[GC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K->133633K(261184K), 0.0459067 secs]]

위의 로그가 의미하는 바는 다음과 같다.

*   GC 전의 Young Generation Usage = 64M, Young Generation Size = 64M

*   GC 전의 Total Heap Usage = 196M, Total Heap Size = 260M

*   GC 후의 Young Generation Usage = 9.5M

*   GC 후의 Total Heap Usage = 133M

*   Minor GC 소요 시간 = 0.0457646

Major GC 발생한 경우 PrintGCDetails 옵션의 적용 예는 아래와 같다.

111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]

111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]

위의 로그는 Minor GC 정보 외에 다음과 같은 Major GC 정보를 제공한다.

*  GC 전의 Tenured Generation Usage = 18M, Tenured Generation Size = 24M

*  GC 후의 Tenured Generation Usage = 2.3M

*  Major GC 소요시간 = 0.12

(참고) PrintGCDetails + PrintGCTimeStamps 옵션의 조합이 가장 보편적으로 사용된다.

-XX:+PrintGCTimeStamps

False

GC 발생한 시간을 JVM 최초 구동 시간 기준으로 기록한다.

(참고) PrintGCDetails + PrintGCTimeStamps 옵션의 조합이 가장 보편적으로 사용된다.

-XX:+PrintHeapAtGC

Fasle

GC 발생 전후의 Heap 대한 정보를 상세하게 기록한다. PrintHeapAtGC 옵션과 PrintGCDetails 옵션을 같이 사용하면 GC 의한 Heap 변화 양상을 매우 정확하게 파악할 있다. 아래에 PrintHeapAtGC 옵션의 적용 예가 있다.

0.548403: [GC {Heap before GC invocations=1:

Heap

par new generation total 18432K, used 12826K [0xf2800000, 0xf4000000, 0xf4000000]

eden space 12288K, 99% used<1> [0xf2800000, 0xf33ff840, 0xf3400000]

from space 6144K, 8% used<2> [0xf3a00000, 0xf3a87360, 0xf4000000]

to space 6144K, 0% used<3> [0xf3400000, 0xf3400000, 0xf3a00000]

concurrent mark-sweep generation total 40960K, used 195K<4>[0xf4000000, 0xf6800000, 0xf6800000]

CompactibleFreeListSpace space 40960K, 0% used [0xf4000000, 0xf6800000]

concurrent-mark-sweep perm gen total 4096K, used 1158K<5> [0xf6800000, 0xf6c00000, 0xfa800000]

CompactibleFreeListSpace space 4096K, 28% used [0xf6800000, 0xf6c00000]

0.549364: [ParNew: 12826K<6>->1086K<7>(18432K<8>), 0.02798039 secs] 13022K->1282K(59392K)

Heap after GC invocations=2:

Heap

par new generation total 18432K, used 1086K [0xf2800000, 0xf4000000, 0xf4000000]

eden space 12288K, 0% used<10> [0xf2800000, 0xf2800000, 0xf3400000]

from space 6144K, 17% used<11> [0xf3400000, 0xf350fbc0, 0xf3a00000]

to space 6144K, 0% used<12> [0xf3a00000, 0xf3a00000, 0xf4000000]

concurrent mark-sweep generation total 40960K, used 195K<13> [0xf4000000, 0xf6800000, 0xf6800000]

CompactibleFreeListSpace space 40960K, 0% used [0xf4000000, 0xf6800000]

concurrent-mark-sweep perm gen total 4096K, used 1158K<14> [0xf6800000, 0xf6c00000, 0xfa800000]

CompactibleFreeListSpace space 4096K, 28% used [0xf6800000, 0xf6c00000]

} , 0.0297669 secs]

-XX:SoftRefLRUPolicyMSPerMB=<value>

1000(ms)

Soft Reference Java Heap에서 밀려나는 주기를 설정한다. 기본값이 1000ms(1)이다. JDK 1.3.1까지는 Soft Reference GC 작업 발생시 항상 메모리에서 해제되었다. 하지만 이후 버전에서는 Free Memory 비례해 일정 시간 정도 메모리에 보관하게끔 변경되었다. 가령 값이 1000(1)이면, Heap Free Memory 1M마다 바로 직전에 참조된 시간에서 1초가 지나지 않았다면 메모리에서 해제하지 않는다.

값을 크게 부여하면 Soft Reference 그만큼 오래 메모리에