Java용 IBM 가상 머신 튜닝

Application Server는 Java™ 기반 서버이며, 이 서버에서 실행되는 엔터프라이즈 응용프로그램을 실행하고 지원하기 위해 JVM (Java Virtual Machine) 환경이 필요합니다. Application Server 구성의 일부로서 Java SE 런타임 환경을 구성하여 성능 및 시스템 자원 사용을 조정할 수 있습니다. 이 주제는 Java용 IBM® 가상 머신에 적용됩니다.

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

   개발 환경과 같은 일부 환경에서는 런타임 성능보다 Application Server의 시작 성능을 최적화하는 것이 보다 중요합니다. 다른 환경에서는 런타임 성능을 최적화하는 것이 보다 중요합니다. 기본적으로, IBM Java 가상 머신은 런타임 성능을 위해 최적화되는 반면 HotSpot 기반 JVM은 시작 성능을 위해 최적화됩니다.

   Java JIT(Just-in-Time) 컴파일러는 시작 또는 런타임 성능이 최적화되는지 여부에 영향을 줍니다. 컴파일러가 사용하는 초기 최적화 레벨은 클래스 메소드를 컴파일하는 데 필요한 시간 길이 및 서버를 시작하는 데 필요한 시간 길이에 영향을 미칩니다. 빠른 시작을 위해서는 컴파일러가 사용하는 초기 최적화 레벨을 줄이십시오. 그러나 초기 최적화 레벨을 줄이는 경우에는 클래스 메소드가 이제 더 낮은 최적화 레벨에서 컴파일되므로 애플리케이션의 런타임 성능이 줄어들 수 있습니다.

   • -Xquickstart

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

     관리 콘솔을 사용하여 JVM (Java Virtual Machine) 패널에서 이 특성을 설정할 수 있습니다. 자세한 정보는 JVM (Java Virtual Machine) 설정에 대한 정보를 읽으십시오.

     정보	값
     기본값	높은 초기 컴파일러 최적화 수준
     권장	높은 초기 컴파일러 최적화 수준
     사용법	-Xquickstart를 지정하면 서버 시작 시간이 개선됩니다.

2. 힙 크기를 구성하십시오.
   주: heapsize 값을 변경하거나 갱신하지 않으면 통합 솔루션 콘솔에 기본 최대 힙 크기가 표시되지 않습니다.

   Java 힙 매개변수는 가비지 콜렉션의 작동에 영향을 줄 수 있습니다. 힙 크기를 늘리면 더 많은 오브젝트 작성을 지원합니다. 힙 크기가 크면 채우는 데 더 오래 걸리므로 애플리케이션은 가비지 콜렉션이 발생하기 전에 더 오랫동안 실행됩니다. 그러나 힙 크기가 크면 압축하는 데에도 시간이 더 오래 걸리므로 가비지 콜렉션이 더 오래 걸립니다.

   JVM은 정의된 임계값을 사용하여 할당된 스토리지를 관리합니다. 임계값에 도달하면 가비지 콜렉터가 호출되어 사용하지 않는 스토리지를 해제합니다. 그러므로, 가비지 콜렉션을 사용하면 Java 성능이 현저히 저하될 수 있습니다. 초기 및 최대 힙 크기를 변경하기 전에 다음 정보를 고려해야 합니다.

   • 대부분의 경우에 최대 JVM 힙 크기를 초기 JVM 힙 크기보다 큰 값으로 설정해야 합니다. 이 설정은 JVM이 초기 힙의 범위 내에서 정상적이고 안정적인 상태 주기 동안에 효율적으로 작동할 수 있도록 해줍니다. 이 설정은 또한 JVM이 트랜잭션 볼륨이 많은 기간 동안에 효율적으로 작동할 수 있도록 해줍니다. JVM은 힙 크기를 최대 JVM 힙 크기에 지정된 값까지 확장할 수 있기 때문입니다. 절대적으로 최적 성능이 요구되는 일부 드문 경우에는 초기 및 최대 힙 크기 둘 모두에 대해 동일한 값을 지정하고 싶을 수도 있습니다. 이 설정은 JVM이 JVM 힙 크기를 확장하거나 수축할 때 발생하는 일부 오버헤드를 제거합니다. JVM 힙 크기를 변경하기 전에 JVM 스토리지 할당이 새 힙 크기를 수용할 만큼 충분히 큰지 확인하십시오.
   • 초기 힙의 크기를 너무 크게 변경하지 마십시오. 처음에는 가비지 콜렉션을 지연하여 성능을 개선할 수 있지만 가비지 콜렉션이 발생하면 콜렉션 프로세스가 오랫동안 실행되어야 하므로 응답 시간에 영향을 미치기 때문입니다.

   힙 크기를 구성하기 위해 관리 콘솔을 사용하려면 다음을 수행하십시오.

   1. 관리 콘솔에서 서버 > 서버 유형 > WebSphere Application Server > server_name을 클릭하십시오.
   2. 서버 인프라 섹션에서 Java및 프로세스 관리 > 프로세스 정의 > JVM (Java Virtual Machine)을 클릭하십시오.
   3. 초기 힙 크기 또는 최대 힙 크기 필드에 새 값을 지정하십시오.

      두 설정을 모두 조정해야 하는 경우에는 두 필드 모두에 값을 지정할 수도 있습니다.

      성능 분석을 위해서는 초기 및 최대 힙 크기가 동일해야 합니다.

      초기 힙 크기 설정은 JVM이 시작될 때 JVM 힙에 할당되는 스토리지의 양(MB)을 지정합니다. 최대 힙 크기 설정은 JVM 힙에 할당할 수 있는 최대 스토리지의 양(MB)을 지정합니다. 이러한 설정은 둘 모두 성능에 상당한 영향을 미칩니다.

      해당 시스템에서 실행 중인 엔터프라이즈 애플리케이션의 작업 세트 크기를 모르는 프로덕션 시스템을 튜닝하는 경우에는 초기 힙 크기에 적합한 시작 값은 최대 힙 크기의 25퍼센트입니다. 그러면 JVM이 힙 크기를 애플리케이션의 작업 세트 크기에 맞도록 합니다.

      다음 그림은 각각 다양한 Java 힙 설정을 사용하여 고정된 워크로드를 실행하는 세 개의 CPU 프로파일을 나타냅니다. 중앙 프로파일에서 초기 및 최대 힙 크기는 128MB로 설정됩니다. 네 개의 가비지 콜렉션이 발생합니다. 가비지 콜렉션의 총 시간은 총 실행의 약 15퍼센트입니다. 힙 매개변수가 첫 번째 프로파일에서와 같이 256MB으로 두 배가 되면 작업 시간 길이는 가비지 콜렉션 사이에서 증가합니다. 세 개의 가비지 콜렉션만이 발생하지만 각 가비지 콜렉션의 길이 또한 증가됩니다. 세 번째 프로파일에서 힙 크기는 64MB로 감소하고 반대의 효과를 나타냅니다. 힙 크기가 더 작으면 가비지 콜렉션 사이의 시간과 각 가비지 콜렉션의 시간 둘 모두가 줄어듭니다. 세 개의 구성 모두에서 가비지 콜렉션의 총 시간은 대략 15퍼센트입니다. 이 예는 Java 힙과, 오브젝트 이용에 대한 힙의 관계에 관한 중요한 개념을 보여 줍니다. 가비지 콜렉션의 비용은 항상 엔터프라이즈 애플리케이션을 실행할 때 존재합니다.

      

      다양한 Java 힙 설정값을 사용하여 일련의 테스트를 실행하십시오. 예를 들어, 128MB, 192MB, 256MB 및 320MB를 사용하여 실험을 실행하십시오. 각 실험마다 총 메모리 사용을 모니터하십시오. 힙을 너무 급격하게 확장하면 페이징이 발생할 수 있습니다.

      vmstat 명령 또는 Windows 성능 모니터를 사용하여 페이징을 확인하십시오. 페이징이 발생하면 힙의 크기를 줄이거나 시스템에 더 많은 메모리를 추가하십시오.

      IBM i WRKSYSSTS 명령을 사용하여 페이징을 확인하십시오. 페이징이 발생하면 힙의 크기를 줄이거나 시스템에 더 많은 메모리를 추가하십시오.

      모든 실행이 완료되면 다음 통계를 비교하십시오.

      • 가비지 콜렉션 호출의 수
      • 단일 가비지 콜렉션 호출의 평균 기간
      • 단일 가비지 콜렉션 호출의 길이와 호출 간의 평균 시간 간의 비율

      애플리케이션이 오브젝트를 과도하게 활용하지 않고 메모리 누수가 없으면 안정적인 메모리 활용 상태에 도달합니다. 가비지 콜렉션은 또한 덜 빈번하게 발생하고 짧은 시간 동안 발생합니다.

      힙 여유 공간이 85퍼센트 이상에서 정착하면, 최대 힙 크기 값을 줄이는 것을 고려하십시오. 애플리케이션 서버 및 애플리케이션이 힙에 할당된 메모리를 충분히 활용하고 있지 않기 때문입니다.

   4. 적용을 누르십시오.
   5. 마스터 구성에 대한 변경사항을 저장하려면 저장 을 클릭하십시오.
   6. 애플리케이션 서버를 중지했다가 다시 시작하십시오.

   이러한 설정을 조정하기 위해 다음 명령행 매개변수를 사용할 수도 있습니다. 이러한 매개변수는 지원되는 모든 JVM에 적용되고 각 Application Server 또는 Application Server 인스턴스의 최소 및 최대 힙 크기를 조정하는 데 사용됩니다.

   • -Xms

     이 매개변수는 Java 힙의 초기 크기를 제어합니다. 이 매개변수를 튜닝하면 가비지 콜렉션의 오버헤드를 줄이고, 이는 서버 응답 시간과 처리량을 개선합니다. 일부 애플리케이션의 경우 이 옵션의 기본 설정이 너무 낮을 수도 있습니다. 이는 대량의 미러 가비지 콜렉션을 초래합니다.

     정보	값
     기본값	50MB
     권장	워크로드에 특정하지만 기본값보다 높습니다.
     사용법	-Xms256m을 지정하면 초기 힙 크기가 256MB로 설정됩니다.

   • -Xmx

     이 매개변수는 Java 힙의 최대 크기를 제어합니다. 이 매개변수를 늘리면 Application Server에 사용 가능한 메모리를 늘리지만 가비지 콜렉션의 빈도를 줄입니다. 이 설정을 늘리면 서버 응답 시간 및 처리량이 개선될 수 있습니다. 그러나 이 설정을 늘리면 또한 가비지 콜렉션이 발생할 때 지속 기간이 늘어납니다. 이 설정은 애플리케이션 서버 인스턴스에 사용 가능한 시스템 메모리보다 높게 증가되지 않아야 합니다. 사용 가능한 시스템 메모리 이상으로 설정을 늘리면 시스템 페이징이 발생하고 성능이 현저히 저하될 수 있습니다.

     정보	값
     기본값	기본적으로 JVM은 시스템에서 사용 가능한 메모리에 따라 동적으로 Java 힙 크기를 계산합니다.
     권장	워크로드 특정적이지만 사용 가능한 실제 메모리의 양에 따라서 기본값보다 높습니다.
     사용법	-Xmx512m을 지정하면 최대 힙 크기가 512MB로 설정됩니다.

     문제점 방지: -Xmx 매개변수의 값을 지정하여 가능한 메모리 부족 문제를 줄이십시오.
   • -Xlp

     16MB페이지와 같은 대형 페이지를 사용할 때 힙을 할당하려면 Java용 IBM 가상 머신과 함께 이 매개변수를 사용하십시오. 이 매개변수를 지정하기 전에 운영 체제가 큰 페이지를 지원하도록 구성되어 있는지 확인하십시오. 큰 페이지를 사용하면 힙 메모리를 추적하는 데 필요한 CPU 오버헤드를 줄일 수 있고 큰 힙의 작성을 허용할 수도 있습니다.

     기본값
     Java 8을 사용하는 경우 64KB

   • -Xlp64k

     이 매개변수는 64KB와 같은 중간 크기 페이지를 사용하는 힙을 할당하는 데 사용할 수 있습니다. 애플리케이션이 요구하는 메모리에 이 가상 메모리 페이지 크기를 사용하면 더 큰 페이지 크기와 연관된 하드웨어 효율성 때문에 애플리케이션의 성능과 처리량이 개선될 수 있습니다.

     i5/OS 및 AIX® 는 64KB페이지가 범용 에서되 제공합,으 - 비슷할십시오을 지원을 다른 64KB페이지에서 제공합니다. 64KB 페이지는 사용으로 설정하기가 쉽고, 64KB 페이지가 사용될 때 애플리케이션이 성능 이점을 받을 수 있습니다. 이 설정은 운영 체제 구성을 변경하지 않고 변경될 수 있습니다. 그러나 64KB 페이지를 사용하는 경우에는 애플리케이션 서버를 별도의 스토리지 풀에서 실행하는 것이 좋습니다.

     권장
     가능할 때마다 64KB 페이지 크기를 사용하십시오. i5/OS POWER5+ 시스템 및 i5/OS 버전 6, 릴리스 1은 64KB페이지 크기를 지원합니다. POWER5+ 시스템 및 AIX 5L 버전 5.3 (5300-04권장 유지보수 패키지 포함) 은 64비트커널을 실행할 때 64KB페이지 크기를 지원합니다.

   • -Xlp4k

     이 매개변수는 4KB 페이지를 사용하여 힙을 할당하는 데 사용할 수 있습니다. 애플리케이션이 요구하는 메모리에 64KB 대신에 이 가상 메모리 페이지 크기를 사용하면 더 작은 페이지 크기와 연관된 하드웨어 비효율성 때문에 애플리케이션의 성능과 처리량에 부정적인 영향을 미칠 수도 있습니다.

     운영 체제 구성을 변경하지 않고 Java힙 할당 설정을 변경할 수 있습니다. 그러나 64KB 페이지를 사용하는 경우에는 애플리케이션 서버를 별도의 스토리지 풀에서 실행하는 것이 좋습니다.

     권장
     가능할 때마다 -Xlp4k 대신 -Xlp64k를 사용하십시오.

3. Java 메모리를 조정하십시오.
   Java 언어로 작성된 엔터프라이즈 애플리케이션은 복잡한 오브젝트 관계를 포함하며 많은 수의 오브젝트를 사용합니다. Java 언어는 오브젝트 라이프사이클과 연관된 메모리를 자동으로 관리하지만 오브젝트에 대한 애플리케이션 사용 패턴을 이해하는 것이 중요합니다. 특히, 다음 조건이 존재하는지 확인하십시오.

   • 애플리케이션이 오브젝트를 과도하게 사용 중이 아닙니다.
   • 애플리케이션이 오브젝트를 누출하고 있지 않습니다.
   • Java 힙 매개변수가 주어진 오브젝트 사용 패턴을 처리하기에 적합하게 설정되었습니다.
   1. 오브젝트의 과다 이용을 확인하십시오.

      Tivoli ® Performance Viewer 보고서에 포함된 JVM 런타임의 카운터를 검토하여 애플리케이션이 오브젝트를 과도하게 사용하는지 판별할 수 있습니다. JVMTI(Java Virtual Machine Profiler Interface) 카운터를 사용 가능하게 설정하려면 JVM 모듈 최대 레벨 뿐만 아니라 -XrunpmiJvmtiProfiler 명령행 옵션을 지정해야 합니다.

      가비지 콜렉션 간의 평균 시간에 대한 최적의 결과는 단일 가비지 콜렉션의 평균 지속 기간의 최소한 5-6배입니다. 이 수를 달성하지 못한 경우에는 애플리케이션은 가비지 콜렉션에 해당 시간의 15퍼센트 이상을 소비하게 됩니다.

      정보가 가비지 콜렉션 병목 현상을 나타내는 경우에는 병목 현상을 정리하기 위한 두 가지 방법이 있습니다. 애플리케이션을 최적화하기 위한 가장 효율적인 방법은 오브젝트 캐시와 풀을 구현하는 것입니다. 대상으로 할 오브젝트를 판별하려면 Java 프로파일러를 사용하십시오. 애플리케이션을 최적화할 수 없는 경우에는 메모리, 프로세서 및 복제본 추가를 시도하십시오. 추가 메모리가 있으면 각 복제본이 이상적인 힙 크기를 유지할 수 있습니다. 추가 프로세서는 복제본이 병렬로 실행할 수 있게 해줍니다.

   2. 메모리 누수를 테스트하십시오.

      Java 언어에서의 메모리 누출은 가비지 콜렉션 병목 현상을 일으키는 위험한 요소입니다. 메모리 누수는 궁극적으로 시스템 불안정성으로 이어지므로 메모리 과다 이용보다 더 해롭습니다. 시간이 지나면서 최종적으로 힙이 고갈되고 Java 코드가 치명적인 메모리 부족 예외와 함께 실패할 때까지 가비지 콜렉션이 더 자주 발생합니다. 사용하지 않은 오브젝트에 결코 해제되지 않는 참조가 있으면 메모리 누수가 발생합니다. 메모리 누수는 해시 테이블 등과 같은 콜렉션 클래스에서 가장 자주 발생합니다. 테이블에는 항상 실제 참조가 삭제된 후에도 항상 오브젝트에 대한 참조가 있기 때문입니다.

      높은 워크로드로 인해 애플리케이션이 프로덕션 환경에서 배치 직후에 충돌할 수 있습니다. 애플리케이션에 메모리 누수가 있으면 높은 워크로드는 누수의 확대를 가속화하고 메모리 할당 실패를 초래할 수 있습니다.

      메모리 누출 테스트의 목표는 숫자를 확대하는 것입니다. 메모리 누수는 가비지 콜렉션될 수 없는 바이트 또는 킬로바이트 양의 관점으로 측정됩니다. 섬세한 태스크는 유용하고 사용 가능한 메모리와 사용 불가능한 메모리의 예상 크기 간에 이러한 양을 구별하는 것입니다. 이 태스크는 수가 확대된 경우 갭이 커지고 불일치를 더 쉽게 식별할 수 있으므로 더욱 쉽게 달성할 수 있습니다. 다음 목록은 메모리 누수 테스트 결과를 해석하는 방법에 대한 통찰을 제공합니다.

      • 장기간 테스트

        따라서 메모리 누수 문제점은 시간 주기 뒤에만 나타날 수 있습니다. 메모리 누수는 장기간 테스트 중에 쉽게 발견됩니다. 단기 실행 테스트는 메모리 누수가 발생하는 위치에 대한 올바르지 않은 표시를 제공할 수도 있습니다. 때로는 Java 언어에서 메모리 누출이 발생하고 있을 때, 특히 주어진 기간 동안 메모리 누출이 겉으로는 갑자기 또는 단조롭게 증가했을 때를 알기가 어렵습니다. 메모리 누수를 발견하는 것이 어려운 이유는 이러한 종류의 증가가 유효하거나 개발자의 의도일 수 있기 때문입니다. 애플리케이션을 더 오랜 기간 동안 실행하여 사용하지 않는 오브젝트와 사용이 지연된 오브젝트를 구별하는 방법을 배울 수 있습니다. 장기 실행 애플리케이션 테스트는 오브젝트의 지연된 사용이 실제로 발생하는지 여부에 대한 더 높은 신뢰성을 제공합니다.

      • 반복적 테스트

        대부분의 경우에 메모리 누수 문제점은 동일 테스트 케이스의 연속된 반복에 의해 발생합니다. 메모리 누수 테스트의 목표는 상대적 크기의 관점에서 사용할 수 없는 메모리와 사용된 메모리 간의 큰 차이를 설정하는 것입니다. 동일 시나리오를 여러 차례 반복하면 간격은 점진적인 방법으로 증가됩니다. 테스트 케이스의 실행으로 인한 누수 수가 너무 작아서 한 번의 실행으로 알아차리기 어려울 정도이면 이 테스트가 도움이 됩니다.

        시스템 레벨 또는 모듈 레벨에서 반복 테스트를 사용할 수 있습니다. 모듈 테스트의 장점은 제어하기 좋다는 것입니다. 모듈이 메모리 사용 등과 같은 외부 부작용을 만들지 않고 개인용 모듈을 유지하도록 설계된 경우에는 메모리 누수 테스트가 더 쉽습니다. 먼저 모듈을 실행하기 전에 메모리 사용이 기록됩니다. 그런 다음 고정된 테스트 케이스 세트가 반복해서 실행됩니다. 테스트 실행의 끝에 현재 메모리 사용이 기록되고 중요한 변경사항이 있는지 확인됩니다. 가비지 콜렉션이 발생하기를 원하는 모듈에 System.gc()를 삽입하여 실제 메모리 사용을 기록할 때 또는 프로파일링 도구를 사용하여 이벤트가 발생하도록 강제할 때 가비지 콜렉션이 제안되어야 함을 기억하십시오.

      • 동시성 테스트

        일부 메모리 누수 문제점은 애플리케이션에서 몇몇 스레드가 실행 중인 경우에만 발생할 수 있습니다. 불행하게도, 동기점은 프로그램 로직에 복잡성을 추가하므로 메모리 누수에 영향을 받기 쉽습니다. 부주의하게 프로그래밍하면 참조가 유지되거나 해제되지 않게 될 수 있습니다. 메모리 누수 사건은 종종 시스템에서 동시성을 늘려서 촉진되거나 가속화됩니다. 동시성을 늘리기 위한 가장 일반적인 방법은 테스트 드라이버에서 클라이언트 수를 늘리는 것입니다.

        메모리 누수 테스트에 사용할 테스트 케이스를 선택할 때 다음 사항을 고려하십시오.

        • 좋은 테스트 케이스는 오브젝트가 작성된 애플리케이션의 영역을 연습합니다. 대부분의 경우 애플리케이션의 지식은 필수입니다. 시나리오의 설명은 새 레코드 추가 등과 같은 데이터 공간 작성, HTTP 세션 작성, 트랜잭션 수행 및 레코드 검색을 제안할 수 있습니다.
        • 오브젝트 콜렉션이 사용되는 영역을 보십시오. 일반적으로 메모리 누수는 동일 클래스 내에서 오브젝트로 구성됩니다. 또한, 벡터와 해시 테이블 등과 같은 콜렉션 클래스는 해당하는 삽입 메소드를 호출하여 오브젝트에 대한 참조가 내재적으로 저장되는 공통 장소입니다. 예를 들어, 해시 테이블 오브젝트의 get 메소드는 검색된 오브젝트에 대한 참조를 제거하지 않습니다.

      Tivoli Performance Viewer를 사용하여 메모리 누출을 찾을 수 있습니다.

      최적의 결과를 얻으려면 1,000, 2,000및 4,000페이지 요청과 같이 지속 기간이 증가하는 실험을 반복하십시오. 사용된 메모리의 Tivoli Performance Viewer 그래프에는 톱니 모양의 선이 있어야 합니다. 그래프에서의 각 낙하는 가비지 콜렉션에 해당됩니다. 다음 조건 중 하나가 그래프에 있으면 메모리 누수가 있습니다.

      • 각 가비지 콜렉션 직후에 사용된 메모리의 양이 현저하게 증가합니다. 이 조건이 발생하면 들쭉날쭉한 패턴은 계단처럼 보입니다.
      • 들쭉날쭉한 패턴에는 불규칙한 선이 있습니다.
      • 할당된 오브젝트의 수와 해제된 오브젝트의 수 사이의 간격은 시간이 지나면서 증가합니다.

      Application Server가 지속적으로 거의 100퍼센트 CPU 활용도인 기간 동안 가능한 누수를 나타내지만 워크로드가 가벼워지거나 유휴에 가깝게 되면 사라지는 힙 이용은 힙 단편화의 표시입니다. 힙 단편화는 JVM이 가비지 콜렉션 주기 중에 메모리 할당 요청을 충족하기 위해 JVM이 충분한 오브젝트를 해제할 수 있지만 JVM이 힙에서 작은 여유 메모리 공간을 더 큰 연속한 공간으로 압축할 시간이 없을 때 발생할 수 있습니다.

      512바이트 미만의 오브젝트가 해제될 때 또 다른 힙 단편화 양식이 발생할 수 있습니다. 오브젝트는 해제되지만 스토리지는 복구되지 않으므로 힙 압축이 발생할 때까지 메모리 단편화가 발생합니다.

      힙 단편화는 압축이 발생하도록 강제 실행하여 줄일 수 있습니다. 그러나 압축을 강제 실행하면 성능에 부작용이 있습니다. 메모리 옵션 목록을 보려면 Java -X 명령을 사용하십시오.

4. 가비지 콜렉션을 조정하십시오.

   Java 가비지 콜렉션을 조사하면 응용프로그램의 메모리 이용 방식에 대한 통찰을 얻을 수 있습니다. 가비지 콜렉션은 Java의 장점입니다. Java 응용프로그램은 응용프로그램 작성자로부터 메모리 관리 부담을 덜어서 가비지 콜렉션을 제공하지 않는 언어로 작성된 응용프로그램보다 더 강력해진 경향이 있습니다. 이 강력함은 애플리케이션이 오브젝트를 남용하지 않는 한 적용됩니다. 가비지 콜렉션은 일반적으로 제대로 작동하는 애플리케이션의 총 실행 시간의 5 - 20퍼센트를 소모합니다. 관리되지 않으면 가비지 콜렉션은 애플리케이션의 가장 큰 병목 현상 중 하나입니다.

   고정 워크로드가 실행 중인 동안에 가비지 콜렉션을 모니터링하면 애플리케이션이 오브젝트를 과다 이용 중인지 여부에 대한 통찰력을 제공합니다. 가비지 콜렉션은 메모리 누출이 있는지 확인할 수도 있습니다.

   JVM 설정을 사용하여 가비지 콜렉션의 유형과 동작을 구성할 수 있습니다. JVM이 연속되는 공간의 부족 때문에 현재 힙에서 오브젝트를 할당할 수 없는 경우 더 이상 사용되지 않는 Java 오브젝트에서 메모리를 재생하기 위해 가비지 콜렉터가 호출됩니다. 각 JVM 공급업체는 고유한 가비지 콜렉터 정책 및 튜닝 매개변수를 제공합니다.

   관리 콘솔에서 상세 가비지 콜렉션 설정을 사용하면 가비지 콜렉션 모니터링을 사용할 수 있습니다. 이 설정의 결과물에는 클래스 가비지 콜렉션 통계가 포함됩니다. 생성된 보고서의 형식은 다른 JVM 또는 릴리스 레벨 사이에 표준화되지 않습니다.

   사용자의 JVM 가비지 콜렉션 설정을 조정하려면:

   1. 관리 콘솔에서 서버 > 서버 유형 > WebSphere Application Server > server_name을 클릭하십시오.
   2. 서버 인프라 섹션에서 Java및 프로세스 관리 > 프로세스 정의 > JVM (Java Virtual Machine) 를 클릭하십시오.
   3. 일반 JVM 인수 필드에서 변경할 -X 옵션을 입력하십시오.
   4. 적용을 누르십시오.
   5. 마스터 구성에 대한 변경사항을 저장하려면 저장 을 클릭하십시오.
   6. 애플리케이션 서버를 중지했다가 다시 시작하십시오.

   다음 목록은-X다른 JVM 가비지 콜렉터에 대한 옵션을 사용하십시오.

   JVM 가비지 콜렉터의 IBM 가상 시스템

   Java 가비지 콜렉터의 IBM 구현에 대한 전체 안내서는 IBM SDK, Java Technology Edition, 버전 8사용자 안내서에서 제공됩니다.

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

   • -Xgcpolicy
     IBM Java 가상 머신은 가비지 콜렉션에 대한 네 가지 정책을 제공합니다. 각 정책은 고유한 이점을 제공합니다.

     참고: 각 정책이 고유한 이점을 제공하는 반면, WebSphere Application Server 버전 8.0 이상의 경우 gencon은 기본 가비지 콜렉션 정책입니다. Application Server의 이전 버전은 optthruput이 기본 가비지 콜렉션 정책임을 지정합니다.

     • gencon은 기본 정책입니다. 이 정책은 세대별 가비지 콜렉터와 함께 작동합니다. 세대별 스키마는 가비지 콜렉션 일시정지 시간의 축소와 함께 높은 처리량을 달성하려고 합니다. 이 목표를 달성하기 위해 힙이 새 세그먼트와 오래된 세그먼트로 분할됩니다. 오래 활동한 오브젝트는 오래된 공간으로 승격되는 반면 활동기간이 짧은 오브젝트는 새 공간으로 빠르게 가비지 콜렉트됩니다. gencon 정책은 많은 애플리케이션에 대해 상당한 이점을 제공합니다. 그러나 모든 애플리케이션에 적합하지는 않으며 일반적으로 튜닝하기가 더 어렵습니다.
     • optthruput은 높은 처리량을 제공하지만 가비지 콜렉션 일시정지 시간이 깁니다. 가비지 콜렉션 중에 압축이 필요할 때 모든 애플리케이션 스레드는 표시, 스윕 및 압축을 위해 중지합니다. gencon 정책은 대부분의 애플리케이션에 충분합니다.
     • optavgpause는 애플리케이션이 실행 중인 동안 가비지 콜렉션의 표시와 스윕 단계를 수행하여 가비지 콜렉션 일시정지 시간을 줄이는 정책입니다. 이 정책은 전체적인 처리량에 작은 성능 영향을 미칩니다.
     • subpool은 일반적으로 9개 이상의 프로세서를 사용하는 멀티프로세서 시스템에서 성능을 높이는 정책입니다. 이 정책은 IBM System i ® System p및 System z ® 프로세서에서만 사용 가능합니다. subpool 정책은 힙이 오브젝트 할당을 위해 개선된 확장성을 제공하는 서브풀로 나뉜다는 점을 제외하고는 gencon 정책과 유사합니다.

     정보	값
     기본값	gencon
     권장	gencon
     사용법	Xgcpolicy:gencon을 지정하면 가비지 콜렉션 정책을 gencon으로 설정합니다.

     gcpolicy를 gencon으로 설정하면 동시 표시가 사용 안함으로 설정됩니다. 애플리케이션 응답 시간이 변덕스럽지 않는 한 gencon 정책을 사용할 때 최적의 처리량 결과를 얻어야 합니다. 이는 일시정지 시간 문제점이 있을 수도 있다는 표시입니다.

     gcpolicy를 optavgpause로 설정하면 동시 표시가 기본값으로 사용 가능으로 설정됩니다. 이 설정은 일반 가비지 콜렉션이 초래하는 변덕스러운 애플리케이션 응답 시간을 완화합니다. 그러나 이 옵션은 전체 처리량을 줄일 수 있습니다.

   • -Xnoclassgc

     기본적으로 JVM은 해당 클래스의 활성 인스턴스가 남아 있지 않을 때마다 메모리로부터 클래스를 로드 해제합니다. 동일 클래스를 여러 차례 로드 및 로드 해제하는 오버헤드는 성능을 줄일 수 있습니다.

     문제점 방지: -Xnoclassgc 인수를 사용하여 클래스 가비지 콜렉션을 사용 안함으로 설정할 수 있습니다. 그러나 클래스 가비지 콜렉션의 성능 영향은 일반적으로 최소이며, 응용프로그램 클래스 로더를 많이 사용하는 Java EE(Java Platform, Enterprise Edition) 기반 시스템에서 클래스 가비지 콜렉션을 설정 해제하면 클래스 데이터의 메모리 누수를 효율적으로 작성할 수 있고, JVM에서 메모리 부족 예외가 발생합니다.

     애플리케이션을 재배치할 때마다 이 옵션을 사용하면 이전 버전의 애플리케이션에서 클래스와 정적 데이터를 지우려면 항상 애플리케이션 서버를 다시 시작해야 합니다.

     정보	값
     기본값	클래스 가비지 콜렉션이 사용 가능합니다.
     권장	클래스 가비지 콜렉션을 사용 불가능하게 하지 마십시오.
     사용법	클래스 가비지 콜렉션을 사용 안함으로 설정하려면 Xnoclassgc를 지정하십시오.

5. localhost 이름 캐싱 사용
   기본적으로 Java용 IBM SDK에서 정적 메소드 java/net/InetAddress.getLocalHost 는 해당 결과를 캐시하지 않습니다. 이 메소드는 WebSphere Application Server전체에서 사용되지만 특히 Deployment Manager및 Node Agent와 같은 관리 에이전트에서 사용됩니다. 프로세스의 localhost 주소는 실행 중인 동안에는 변경되지 않는 경우에는 com.ibm.cacheLocalHost 시스템 특성을 true 값으로 설정하여 localhost 검색에 기본 제공 캐시를 사용하는 것이 바람직합니다. 다양한 유형의 프로세스에서 JVM 사용자 정의 특성 설정에 대한 지시사항은 문서의 JVM (Java Virtual Machine) 사용자 정의 특성 주제를 참조하십시오.

   문제점 방지: DHCP를 사용하여 구성된 서버의 주소가 시간에 따라 변경됩니다. 서버에서 정적으로 지정된 IP 주소를 사용하지 않으면 이 특성을 설정하지 마십시오.

   정보	값
   기본값	com.ibm.cacheLocalHost = false
   권장	com.ibm.cacheLocalHost = true(설명 참조)
   사용법	-Dcom.ibm.cacheLocalHost=true를 지정하면 getLocalHost 캐시가 사용 가능하게 됩니다.

6. 캐시에서 클래스 공유를 사용 가능하게 하십시오.

   캐시에서 클래스를 공유하면 시작 시간이 개선되고 메모리 풋프린트가 감소합니다. Application Server, 노드 에이전트 및 배치 관리자와 같은 프로세스는 공유 클래스 옵션을 사용할 수 있습니다.

   문제점 방지: 클래스 공유 및 연관된 설정은 Solaris 또는 HP-UX에서 지원되지 않습니다.

   이 옵션은 기본적으로 Application Server에서 사용할 수 있습니다.

   캐시를 지우려면 모든 서버 프로세스를 중지하고 app_server_root/bin/clearClassCache 스크립트를 호출하거나 Application Server를 중지하여 캐시를 지운 후 Application Server를 다시 시작하십시오.

   이 옵션을 사용하는 경우 서버 프로세스가 사용 중이지 않으면 캐시를 지우십시오. 캐시를 지우려면 모든 서버 프로세스를 중지한 후 app_server_root\bin\clearClassCache.bat 스크립트를 호출하거나 애플리케이션 서버를 중지하여 캐시를 지운 후 애플리케이션 서버를 다시 시작하십시오.

   이 옵션을 사용하는 경우 서버 프로세스가 사용 중이지 않으면 캐시를 지우십시오. 캐시를 지우려면 모든 서버 프로세스를 중지한 후 app_server_root/bin/clearClassCache.sh 스크립트를 호출하거나 애플리케이션 서버를 중지하고 애플리케이션 서버를 다시 시작하여 캐시를 지우십시오.

   참고: clearClassCache 를 사용하여 전체 캐시를 지우는 경우 연결된 모든 JVM을 중지해야 합니다.

   프로세스에 대해 공유 클래스 옵션을 사용 안함으로 설정해야 하는 경우 해당 프로세스에 대해 일반 JVM 인수 -Xshareclasses:none 를 지정하십시오.

   1. 관리 콘솔에서 서버 > 서버 유형 > WebSphere Application Server > server_name을 클릭하십시오.
   2. 서버 인프라 섹션에서 Java및 프로세스 관리 > 프로세스 정의 > JVM (Java Virtual Machine) 를 클릭하십시오.
   3. 일반 JVM 인수 필드에 -Xshareclasses:none 를 입력하십시오.
   4. 확인을 누르십시오.
   5. 마스터 구성에 대한 변경사항을 저장하려면 저장 을 클릭하십시오.
   6. 애플리케이션 서버를 중지했다가 다시 시작하십시오.

   정보	값
   기본값	캐시 옵션의 고유 클래스가 사용으로 설정됩니다.
   권장	캐시 옵션의 공유 클래스를 사용 가능 상태로 둡니다.
   사용법	-Xshareclasses:none을 지정하면 캐시 옵션에서 공유 클래스가 사용 안함으로 설정됩니다.

7. 64비트환경에서 압축 참조를 사용하십시오.

   AIX 64, Linux® PPC 64, zLinux 64및 Microsoft Windows AMD64, Linux AMD64와 같은 64비트환경에서 압축 참조를 사용할 수 있습니다.

   IBM i 64비트 환경(예: IBM i 버전 6.1)에서 압축 참조를 사용 가능하게 설정할 수도 있습니다.

   64비트 JRE (Java SE Runtime Environment) 버전 6.0 의 IBM 구현의 압축 참조 옵션을 사용하면 모든 메모리 참조를 32비트크기로 제한할 수 있습니다. 일반적으로 64비트 JVM은 32비트 JVM보다 더 많은 힙 공간을 사용합니다. 이들은 주소 메모리에 대해 64비트 너비의 메모리 참조를 사용하기 때문입니다. 64비트 참조에 의해 주소 지정 가능한 힙은 32비트 힙보다 큰 크기 순서이지만 실제 세계에서는 주소 지정을 위해 모든 64비트를 필요로 하는 힙은 일반적으로 필요하지 않습니다. 참조를 압축하면 주소의 크기가 줄어들고 힙의 사용을 보다 효율적으로 만듭니다. 이러한 참조를 압축하면 또한 프로세서 캐시 및 버스 활용도가 개선되므로 따라서 성능이 개선됩니다.

   압축된 참조 기능은 다음에서는 지원되지 않습니다.

   • HP-UX 64비트 JVM
   • iSeries Classic 64비트 JVM

   힙 크기가(-Xmx 매개변수에 의해 제어됨) 특정 힙 크기 아래에 설정되면(플랫폼에 따라 약 25GB) 제품은 기본적으로 지원되는 플랫폼에서 포인터 압축을 자동으로 사용 가능으로 설정하고, 그렇지 않은 경우에는 압축되지 않은 참조로 기본 설정됩니다. 사용자는 다음 명령행 옵션을 사용하여 이러한 기본값을 대체할 수 있습니다.

   주: Java 8 SR2 FP10또는 z/OS Java 8 SR3의 경우 -Xcompressedrefs 옵션은 기본적으로 최대 57GB 까지 사용 가능하며 플랫폼에 따라 더 높은 값으로 사용할 수 있습니다.

   다음 명령행 옵션은 압축된 참조 기능을 제어합니다.

   -Xcompressedrefs

   이 명령행 옵션은 압축된 참조 기능을 사용 가능으로 설정합니다. JVM이 이 명령행 옵션으로 실행되면 힙을 주소 지정하기 위해 32비트 너비의 메모리 참조를 사용합니다. 이 기능은 -Xmx 매개변수에 의해 제어되는 특정 힙 크기(플랫폼에 따라 약 29GB)까지 사용될 수 있습니다.

   -Xnocompressedrefs

   이 명령행 옵션은 압축된 참조 기능을 명시적으로 사용 안함으로 설정합니다. JVM이 이 명령행 옵션으로 실행되면 힙을 주소 지정하기 위해 전체 64비트 너비의 메모리 참조를 사용합니다. 이 옵션은 필요한 경우 포인터 압축의 기본 사용을 대체하기 위해 사용자에 의해 사용될 수 있습니다.