Sun에서 개발된, HP 이식 핫스팟 JVM(Java™ Virtual Machin)의 아키텍처는 IBM에서 개발된
소프트웨어 개발 킷(SDK)과 다르게 진화했습니다. 오래되지 않은 세대 또는 오래된 세대 및 영구적 영역에 대해,
해당되는 내부 구조는 필요에 따라 다른 가비지 콜렉션 뿐만 아니라 세대 가비지 콜렉션을
기본적으로 지원하기 위해 발생합니다.
시작하기 전에
참고: 이 주제는 하나 이상의 애플리케이션 서버 로그 파일을
참조합니다. 권장되는 대안은 분배 및 IBM® i 시스템에서 SystemOut.log, SystemErr.log, trace.log 및 activity.log 파일을 사용하는 대신
HPEL(High Performance Extensible Logging) 로그를 사용하고
인프라를 추적하도록 서버를 구성하는 것입니다. 원시 z/OS® 로깅 기능과 연계하여 HPEL을 사용할 수도 있습니다. HPEL을 사용하는 경우
서버 프로파일 바이너리 디렉토리의 LogViewer 명령행 도구를 사용하여
모든 로그에 액세스하고 정보를 추적할 수 있습니다. HPEL 사용에 대한 자세한 정보는
HPEL을 사용한 애플리케이션 문제점 해결 정보를
참조하십시오.
- 애플리케이션 서버가 실행 중인 JVM의 유형을 판별하십시오.
애플리케이션 서버 app_server_root/java/bin 디렉토리에서 java –fullversion 명령을 발행하십시오. 이 명령에 대한 응답으로,
애플리케이션 서버가 JVM 제공자 정보를 포함한 JVM 관련 정보를 SystemOut.log 파일에 기록합니다. 애플리케이션 서버가 Java용 IBM 가상 시스템에서 실행 중인 경우,
Java용 IBM 가상 시스템 조정 주제를
참조하십시오.
- 사용자 시스템에 대해 다음 문장이 적용되는지 확인하십시오.
- JVM의 가장 최근 지원되는 버전이 시스템에 설치되어 있습니다.
- 가장 최근 서비스 업데이트가 시스템에 설치되어 있습니다. 거의 모든 새 서비스 레벨에서 JVM 성능 향상을 확인할 수 있습니다.
이 태스크 정보
Sun HotSpot JVM을 조정하는 것은 JVM 구성이 개발되고, 데이터가 수집된 후(기본적으로 verbosegc
데이터로부터) 분석되는 대체 프로세스로, 구성 개정은 다음 주기에서 적용됩니다. Sun HotSpot JVM을
조정해야 하는 경우 다음 단계 중 하나 이상을 수행하십시오.
프로시저
- 충분한 Java 힙 메모리를 제공하십시오.
Java 힙 메모리는 예약된 연속 주소 세트입니다. Java 힙 메모리의 크기는 Java 힙이 구성되는 최대 크기입니다. 이 주소는
다른 원시 또는 시스템 메모리 요구에 사용할 수 없으며, JVM에 의해서만
유지보수 및 관리됩니다. Java 힙은 해당 JVM 수명 동안 Java 오브젝트 스토리지에 사용되기 때문입니다.
JVM이 초기화될 때, Java 힙에 대한 보안 자원은 JVM 구성 설정에 따라 확보됩니다.
사용 가능한 메모리가 부족하면 JVM 초기화에 실패합니다. Java 힙에서 부적절한 메모리가 구성되면, 시스템은
OutOfMemory 보고서와 함께 결국 실패합니다. 이 보고서 이전에 보통 중요한
가비지 콜렉션 활동이 있으면 이 때는 어떤 Java 처리도 거의 발생하지 않습니다.
스레드 실행, I/O 데이터 저장, 그리고 맞추기 및
페이지 크기와 같은 요구사항의 충족을 수용하기 위해 프로세스의 다른 컴포넌트의 원시 메모리 필요를
충분히 고려해야 합니다.
Sun HotSpot Java 힙은 최대 Java 힙 크기를 지정할 때 고려해야 하는 물리적으로 독립된 두 개의 파트로
구성됩니다.
- eden, 생존(survivor) 공간 및 tenured 영역으로 추가로 세분화되는
오래되지 않은 세대 영역 및 오래된 세대 영역의 조합인 영구적인 영역.
- 이 시스템의 Java 컴포넌트에 대한 프로비전 메모리.
-XX:MaxPermSize= 및 -Xmx(최대 Java 힙 크기) 매개변수는 각각 영구 영역의 최대 크기(클래스 및 관련 데이터는 논리적으로 오래된 세대 영역의 일부로
표시되지만 물리적으로는 별도로 유지됨)와, Java 오브젝트 및 해당 데이터가 오래되지 않은 세대나 오래된 세대 영역에
저장되는 기본 힙의 최대 크기를 구성합니다. 영구 영역과 기본 힙은 함께 Java 힙을 구성합니다. 이 영역 중 하나에서의 할당 실패는
모든 애플리케이션 코드나 모든 애플리케이션 데이터를 수용할 수 없음을 나타냅니다.
이때 사용 가능한 스토리지를 고갈시키고 OutOfMemory 오류를 야기할 수 있는
두 가지의 터미널 상태가 됩니다.
다음 조정 매개변수를 참조하십시오.
- -XX:MaxPermSize(영구 영역)
- -Xmx(최대 Java 힙 크기)
- 시스템의 소프트웨어 컴포넌트에 도입될 수 있는 불필요하거나
시기를 놓친 주요 가비지 콜렉션 사이클을 제거하려면 명시적 가비지 콜렉션을 사용하지 않도록 설정하십시오.
조정 매개변수
-XX:+DisableExplicitGC를 참조하십시오.
문제점 방지: 기본적으로 JVM은 클래스의 활동하는 인스턴스가
없을 때 메모리에서 해당 클래스를 로드 해제합니다.
-Xnoclassgc
인수를 사용하여 클래스 가비지 콜렉션을 사용 불가능하게 설정할 수 있습니다.
그러나, 클래스 가비지 콜렉션의 성능 영향은 일반적으로 최소이며,
애플리케이션 클래스 로더를 많이 사용하는
Java EE(Java Platform, Enterprise Edition) 기반 시스템에서
클래스 가비지 콜렉션을 끄면 클래스 데이터의 메모리 누수를 효율적으로 작성할 수 있고, JVM에서 메모리 부족 예외가
발생합니다.
-Xnoclassgc 인수를 사용하는 경우,
애플리케이션을 재배치할 때마다 항상 애플리케이션 서버를
다시 시작하여 애플리케이션의 이전 버전의 클래스 및 정적
데이터를 지워야 합니다.
gotcha
-Xnoclassgc 인수를 사용하는 경우,
애플리케이션을 재배치할 때마다 항상 애플리케이션 서버를
다시 시작하여 애플리케이션의 이전 버전의 클래스 및 정적
데이터를 지워야 합니다.
- 가비지 콜렉션 조치를 최적화하기 위해 영역 크기를 조정하십시오.
가비지 콜렉션 조정 시도 의사결정은 가비지 콜렉터의 동작을
기초로 해야 합니다. 애플리케이션의 운영 요구에 적합하도록 올바른 가비지 콜렉션
모드를 식별해야 합니다. 또한 성능 요구사항을 충족하고 있고,
애플리케이션의 요구를 일관되게 충족시키기 위해 충분한 메모리 자원을
효율적으로 재순환하고 있는지 확인해야 합니다. 가비지 콜렉션 매개변수 설정에 대해 작성하는
변경사항은 충분히 다른 결과를 생성하고 핫스팟 Java 힙의 다른 영역을 이용하는 것에서 파생되는 이익을
보여주어야 합니다.
반복적 조정 프로세스는 상당히 반복될 필요가 있는 것처럼
어리석은 선택사항은 일반적으로 조정 프로세스를 늘립니다. 추가 섹션은 추가 조정에 대해
두 가지의 프린시펄 선택사항인 병렬 처리량 또는 동시 low-pause과, 관련 옵션을
표시합니다. 두 모드 모두 고가용성에 대한 잠재성을 제공하지만, 주요 성능 요인은
최적화되는 동작이 모드마다 다르다는 것입니다.
우세한
조정 활동은 필요에 따라 애플리케이션의 할당 활동에 서비스를 제공하고 스토리지 재순환을 위해
효율적인 가비지 콜렉션을 배열하기 위한 자원 활용 제어에 관련됩니다.
필연적으로, 이러한 조정 논의는 사용되는 가비지 콜렉션 모드의 영향을 받습니다. 두 가지 유형의
가비지 콜렉션이 논의됩니다.
- 오래되지 않은 세대에 대해 병렬 scavenge 사본 콜렉션을 수행하는 처리량 콜렉터. 이 유형의 가비지 콜렉션은
다중 프로세서 서버 클래스 시스템에서 기본 유형입니다.
- 동시 low-pause 콜렉터.
이 콜렉터로 조정하는 목적은 할당 패턴과 애플리케이션 시스템의 오브젝트
수명에 가장 적합하고 해당 콜렉션 조치의 효율성을 최대화하는 동작을
전달하는 것입니다.
- 옵션 1: 내장 조정이 사용되는 기본 처리량/병렬 scavenge 콜렉터.
버전 5부터,
Sun HotSPot JVM은 서버가 실행하고 있는 운영 체제의 발견을 제공하고, JVM이 적절한
세대 가비지 콜렉션 모드를 설정하려고 시도합니다. 모드는 여러 프로세서의 존재 여부와 실제 메모리 크기에 따라
병렬 또는 직렬입니다. 제품이 프로덕션 및 프로덕션 이전 모드에서 실행되는
모든 하드웨어는 서버 클래스 시스템에 대해 고려할 요구사항을 충족한다고
예상합니다. 그러나, 일부 개발 하드웨어는 이 기준을 충족하지 않을 수
있습니다.
처리량 가비지 콜렉터의 동작은 자동으로 조정되는지 여부에 관계없이
동일하게 유지되고, 세대 가비지 콜렉션의 이득을 최대화하기 위해 시도하는 대로
Java 애플리케이션 시스템의 실행으로, 사용된 힙의 크기에 비례하는 약간의 중요한
일시정지가 도입됩니다. 그러나, 이 자동 알고리즘은 사용자 워크로드가 해당 조치에 잘 맞는지, 또는
시스템이 필요한지 또는 다른 가비지 콜렉션 전략에 더 맞는지 판별할 수 없습니다.
다음 조정 매개변수를 참조하십시오.
- -XX:+UseParallelGC
- -XX:+UseAdaptiveSizePolicy
- -XX:+AggressiveHeap
- 옵션 2: 기본 처리량/병렬 scavenge 콜렉터를 사용하지만
수동으로 조정합니다.
-XX:+UseAdaptiveSizePolicy 매개변수를 사용하여 설정되는
내장 알고리즘 사용의 단점으로는 -XX:SurvivorRatio 매개변수와 같은, 다른 매개변수가 내장
알고리즘과 결합하여 수행하도록 구성될 수 있는 것을 제한하는 것이 있습니다. 내장 알고리즘을 사용할 때,
실행 동안 사용되는 자원 할당 판별에 대해 일부 제어를 포기합니다.
내장 알고리즘을 사용한 결과가 불만족스러우면, 알고리즘의 조치를 시도하고
조정하기 보다는, 수동으로 JVM 자원을 구성하는 것이 더 쉽습니다. JVM 자원의 수동 구성에는
알고리즘의 조치 조정에 소요되는 옵션의 반을 사용합니다.
다음 조정 매개변수를 참조하십시오.
- -XX:NewRatio=2 VM 모드에 대해 구성된 서버의 기본값입니다.
- -XX:MaxNewSize= 및 -XX:NewSize=
- -XX:SurvivorRatio=
- -XX:+PrintTenuringDistribution
- -XX:TargetSurvivorRatio=
- 옵션 3: 동시 low-pause mark-sweep 콜렉터 사용
이 콜렉터는 핫스팟 아키텍처에 핀(pin)된 세대 가비지 콜렉션 진화의 근본적인 출발로,
전용 낮은 우선순위, 백그라운드 가비지 콜렉션 스레드를 사용하는
애플리케이션 스레드 처리의 겹침을 허용합니다. 애플리케이션 데이터가 기본 처리량 콜렉터의
동작과 호환되지 않는 경우, CMS(concurrent mark-sweep) 콜렉터는 특히
침입적 일시정지의 편협한 애플리케이션 시스템에 대해, 실용적 전략일 수
있습니다. 이 콜렉터는 특히 64비트 JVM에 대해 사용되는 매우 큰 힙이나,
큰 장기 수명 데이터 세트(대형 tenured 세대 라고도 함)를 가지고 있고,
비교적 좋은 캐시 활용을 유지보수하는 애플리케이션에 특히 도움이 됩니다.
전체 힙의 모든 페이지를 통해 백그라운드 스레드가 스캔해야 하는 경우에도, 오래되지 않은 세대의 페이지를
대규모로 유지합니다.
동시 mark-sweep 콜렉터를 중요한 관리 업무 에이전트로 사용하려면,
JVM 구성에 다른 어떤 가비지 콜렉션 모드 대신에 이 옵션을 추가하십시오.
다음 조정 매개변수를 참조하십시오.
- -XX:+UseConcMarkSweepGC
- -XX:CMSInitiatingOccupancyFraction=75
- -XX:SurvivorRatio=6
- -XX:MaxTenuringThreshold=8
- -XX:NewSize=128m
CMS의 조정에 대한 어려움에서, 최악의 경우의 가비지 콜렉션 시간(CMS 주기가
중단될 때)은 몇 초나 걸릴 수 있습니다. 장기 일시정지를 피하기 위해 정확하게
CMS를 사용하는 시스템의 경우에 특히 비용이 소요됩니다. 결국, 서비스 레벨 계약에서는
CMS 사용을 언급할 수 있습니다. 평균 또는 중간 일시정지 시간이
매우 낮기 때문에, CMS 사이클이 중단되지 않도록 신중하게 조정해야 합니다. CMS는
해당되는 예상 트리거에서 충분한 여유 자원이 요구 전에 사용 가능하도록 CMS 주기가 항상 충분히 빨리 시작하도록
하는 경우에만 성공합니다. tenured 세대가 채워지기 전에 CMS 콜렉터가 완료할 수 없으면,
콜렉션은 전체 콜렉션으로 알려진 애플리케이션 스레드를 일시정지하여 완료됩니다.
전체 콜렉션은 CMS 콜렉터가 애플리케이션에 더 제대로 맞도록 하기 위해
추가 조정이 필요하다는 표시입니다.
결국,
압축 단계(Phase)가 있는 다른 가비지 콜렉션 모드와 달리, CMS 사용은 이론상
핫스팟에 대해 발생하는 단편화 위험이 발생합니다.
그러나, 실제로 이는 콜렉션이 힙의 유익한 부분을 복구하는 동안 드물게 발생하는
문제점입니다. CMS가 실패하거나, 콜렉션을 중단하는 경우에,
대안인 압축 가비지 콜렉션이 트리거됩니다. 필연적으로 다른 유형의 가비지 콜렉션은 보통의
CMS 콜렉션과 비교하여 중요한 침입적 일시정지를 초래합니다.
문제점 방지: 처리량 콜렉터에서와 같이,
명시적으로 제어되는 CMS에 대해 사용 가능한 많은 옵션이 있습니다. 그러나 언급된 것은
핫스팟 JVM을 조정할 때 사용하도록 고려해야 할 옵션의 핵심을 나타냅니다.
gotcha
다음에 수행할 작업
일반적으로 verbosegc를 사용하여, 구성을 평가하기 위해 데이터를
수집하고 분석하십시오. JVM이 수행되는 방식에 만족할 때까지
변경을 조정하면서 데이터를 계속 수집하고 분석하십시오.