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 개발자 킷 진단 안내서를 참조하십시오.