성능 모니터링 시작 가이드http://technet.microsoft.com/ko-kr/library/dd744567%28v=ws.10%29.aspx시스템의 자원은 CPU, 메모리, 디스크, 네트워크 등, 크게 4가지 요소로 이루어져 있습니다.
Processor\%Processor Time (_Total)위에 언급된 모든 카운터는 모두 의미를 담고 있습니다.
Processor\%Privileged Time (_Total) Process\%Processor Time (프로세스명 – W3WP.EXE, SQLSERVR.EXE 등)System\Context Switches/secSystem\System Calls/sec
System\Processor Queue Length
목차 |
| 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를 변경하는 방법을 통해 작업을 수행한다. |
| 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를 줄여주어야 한다. |
| 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]]위의 로그가 의미하는 바는 다음과 같다.
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 정보를 제공한다.
|
| -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가 그만큼 오래 메모리에 머물고 사용 효율이 높아진다. 반면 메모리 점유율이 높아진다. 따라서 Applicaiton에서 Soft Reference를 많이 사용하고, Free Memory가 많지 않은 상황에서는 이 값을 낮출 필요가 있다. 반면 Soft Reference에 기반하여 Cache를 구현하고, Free Memory에 여유가 있는 상황에서는 이 값을 높임으로써 성능 향상을 꾀할 수 있다. |
| -XX:SurvivorRatio=<value> | 5~6(OS/Version마다 다름) | Survivor Space와 Eden Space의 비율을 지정한다. 만일 이 값이 6이면, To Survivor Ratio:From Survivor Ratio:Eden Space = 1:1:6이 된다. 즉, 하나의 Survivor Space의 크기가 Young Generation의 1/8이 된다. Survivor Space의 크기가 크면 Tenured Generation으로 옮겨가지 전의 중간 버퍼 영역이 커지는 셈이다. 따라서 Full GC의 빈도를 줄이는 역할을 할 수 있다. 반면 Eden Space의 크기가 줄어들므로 Minor GC가 자주 발생하게 된다. |
| -XX:+TraceClassLoading | False | Class Loading을 추적하는 메시지를 뿌릴지의 여부를 지정한다. TraceClassUnloading 옵션과 함께 ClassLoader 문제를 추적하고자 할 때 사용된다. |
| -XX:+TraceClassUnloading | False | Class Unloading을 추적하는 메시지를 뿌릴지의 여부를 지정한다. TraceClassLoading 옵션과 함께 ClassLoader 문제를 추적하고자 할 때 사용된다. 이 옵션은 JDK 1.6에서 추가되었다. |
| -XX:+UseAdaptiveSizePolciy | True | Parallel Collector를 사용할 경우 Young Generation의 크기를 Adaptive하게 적용할 지의 여부를 지정한다. Parallel Collector의 목적은 Throughput을 최대화하는 것이며, 이 목적에 따라 Young Generation의 크기를 JVM 스스로 조정한다. (주의) Adaptive Size를 사용하는 경우 Young Generation의 크기가 잘못 계산되어 Full GC를 과잉 유발하는 것과 같은 오동작을 하는 경우가 있다. 이럴 경우에는 이 옵션의 값을 False(-XX:-UseAdaptiveSizePolicy)로 변경해주어야 한다. |
| -XX:+UseCMSCompactAtFullCollection | True | CMS Collector에 의한 Concurrent GC 수행 시 Compaction 작업을 수행할 지의 여부를 지정한다. 이 값이 True이면, Old Generation의 Fragmentation에 의해 Promotion Failure가 발생할 때 Stop The World 방식의 Full GC를 수행하며 Compaction이 이루어진다. JDK 1.4.2부터는 True가 Default 값이다. 좀 더 자세한 내용은 CMSFullGCsBeforeCompaction 파라미터를 참조한다. |
| -XX:+UseCMSInitiatingOccupancyOnly | False | Concurrent Full GC를 수행할 기준으로 최초에 지정된 비율을 고정적으로 사용할지의 여부를 지정한다. 최초의 비율은 CMSInitiatingOccupancyFraction 옵션에 의해 지정된다. CMS Collector를 사용하는 환경에서 Full GC가 자주 발생하는 경우 CMSInitiatingOccupancyFraction 옵션의 값을 낮게(50이하)로 지정하고, 이 옵션의 값을 True로 지정하는 방법을 많이 사용한다. |
| -XX:+UseConcMarkSweepGC | False | CMS Collector를 사용할 지의 여부를 지정한다. GC Pause에 의한 사용자 응답 시간 저하 현상을 줄이고자 할 경우에 사용이 권장된다. |
| -XX:+UseParallelGC | 환경에 따라 다름 | Parallel Collector를 사용할 지의 여부를 지정한다. JDK 1.4까지는 False가 기본값이다. JDK 1.5부터는 서버급 머신인 경우에는 True, 클라이언트급 머신일 경우에는 False가 기본값이다. 서버급 머신이란 CPU가 2개 이상, Physical RAM이 2G 이상인 머신을 의미한다. 큰 크기의 Young Generation이 일반적인 엔터프라이즈 환경에서는 Parallel Collector를 사용함으로써 Minor GC에 의한 GC Pause를 최소화할 수 있다. Parallel Collector는 Young Generation에 대해서만 작동한다는 사실에 주의하자. Old Generation에 대해 Parallel Collection을 사용하고자 하는 경우에는 UseParallelOldGC 옵션을 사용한다. |
| -XX:+UseParallelOldGC | False | Old Generation에 대해 Parallel Collection을 수행할 지의 여부를 지정한다. JDK 1.6에서 추가된 옵션이다. |
| -XX:+UseParNewGC | 환경에 따라 다름 | CMS Collector를 사용하는 경우에 한해서, Young Generation에 대해서 Parallel Collection을 수행할 지의 여부를 지정한다. 이 옵션과 UseParallelGC, UseParallelOldGC 옵션과의 차이를 명확하게 구분해야 한다. |
| -XX:+UseSerialGC | 환경에 따라 다름 | Serial Collector를 사용할 지의 여부를 지정한다. JDK 1.4까지는 Default 값이 True이다. JDK 1.5에서는 UseParallelGC 옵션에서 설명한 것처럼 머신의 등급에 따라 Default 값이 결정된다. |
#My options file
-X<option1>
-X<option2>=\<value1>,\
<value2>
-D<sysprop1>=<value1>
| Option | Description |
| -memorycheck:<optiton> | JVM 내부에서 발생하는 Memory Leak을 추적하기 위한 용도로 사용된다. JVM 기술지원 엔지니어들이 사용하는 용도로 보면 정확한다. JVM 자체는 C/C++로 구현되었다. 따라서 JVM 내부에서 발생하는 Memory Leak은 Java에서 발생하는 것과는 달리 진정한 의미에서는 Memory Leak으로 이해할 수 있다. 다음과 같은 옵션들이 제공된다(IBM JVM Diagnositics Guide에서 발췌)
|
| -showversion | Java의 버전과 기본적인 사용법에 대한 정보를 제공한다. |
| -verbose:<option> | Option에 따라 상세 정보를 출력한다. 다음과 같은 옵션이 제공된다.
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/
< 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> <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>
-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
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 |
| 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의 종류를 결정한다.
|
| -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|-
|
| loainitial | ||
| loamaximum | ||
| loaminimum | ||
| lp | ||
| maxe | ||
| maxf | ||
| maxt | ||
| mca | ||
| mco | ||
| mine | ||
| minf | ||
| mint | ||
| mn | ||
| mns | ||
| mnx | ||
| mo | ||
| moi | ||
| mos | ||
| mox | ||
| mr | ||
| mrx | ||
| ms | ||
| mso | ||
| mx | ||
| noaot | ||
| noclassgc | ||
| nocompactexplicitgc | ||
| nocompactgc | ||
| -Xnojit | False | JIT 컴파일 옵션을 사용하지 않는다. |
| noloa | ||
| nopartialcompactgc | ||
| nosigcatch | ||
| nosigchain | ||
| optionsfile | ||
| oss | ||
| partialcompactgc | ||
| quickstart | ||
| realtime | ||
| rs | ||
| runhprof | ||
| samplingExpirationTime | ||
| scmx | ||
| shareclasses | ||
| sigcatch | ||
| sigchain | ||
| softrefthreshold<number> | ||
| ss | ||
| ssi | ||
| thr | ||
| verbosegclog:<file> |