Java용 IBM 가상 머신 튜닝

애플리케이션 서버는 Java™ 기반 서버이며 실행하는 엔터프라이즈 애플리케이션을 실행하고 지원하기 위해 JVM(Java Virtual Machine) 환경이 필요합니다. 애플리케이션 서버 구성의 일부로, Java SE Runtime Environment를 구성하여 성능 및 시스템 자원 사용을 튜닝할 수 있습니다. 이 주제는 Java용 IBM® 가상 머신에 적용됩니다.

시작하기 전에

참고: 이 주제는 하나 이상의 애플리케이션 서버 로그 파일을 참조합니다. 권장되는 대안은 분배 및 IBM i 시스템에서 SystemOut.log, SystemErr.log, trace.logactivity.log 파일을 사용하는 대신 HPEL(High Performance Extensible Logging) 로그를 사용하고 인프라를 추적하도록 서버를 구성하는 것입니다. 원시 z/OS® 로깅 기능과 연계하여 HPEL을 사용할 수도 있습니다. HPEL을 사용하는 경우 서버 프로파일 바이너리 디렉토리의 LogViewer 명령행 도구를 사용하여 모든 로그에 액세스하고 정보를 추적할 수 있습니다. HPEL 사용에 대한 자세한 정보는 HPEL을 사용한 애플리케이션 문제점 해결 정보를 참조하십시오.
  • 애플리케이션 서버가 실행 중인 JVM의 유형을 판별하십시오.

    [AIX Solaris HP-UX Linux Windows][z/OS]애플리케이션 서버 app_server_root/java/bin 디렉토리에서 java –fullversion 명령을 발행하십시오.

    [AIX Solaris HP-UX Linux Windows]이 명령에 대한 응답으로, Java가 JVM 제공자 정보를 포함한 JVM 관련 정보를 명령을 실행한 창에 기록합니다. 예를 들면, 다음과 같습니다.
    java full version "JRE 1.6.0 IBM Windows 32 build pwi3260sr7-20091217_01 (SR7)"

    [z/OS]이 명령에 대한 응답으로, Java가 JVM 제공자 정보를 포함한 JVM 관련 정보를 stderr에 기록합니다.

    [IBM i]profile_root/bin 디렉토리에서 dspwasinst 명령을 발행하십시오. 이 명령의 출력에는 애플리케이션 서버 프로파일에 사용할 수 있는 JVM에 대한 JAVA_HOME 설정 및 기타 정보가 들어 있습니다.

    [AIX Solaris HP-UX Linux Windows]애플리케이션 서버가 Sun HotSpot JVM에서 실행 중인 경우, Sun HotSpot JVM(Java Virtual Machine)(Solaris & HP-UX) 튜닝 주제를 참조하십시오.

    [IBM i]애플리케이션 서버 프로파일이 다른 JVM을 사용 가능하게 하려면 managesdk 명령을 사용하십시오.

  • [IBM i][AIX Solaris HP-UX Linux Windows]다음을 확인하십시오.
    1. JVM의 가장 최근 지원되는 버전이 시스템에 설치되어 있습니다.
    2. 가장 최근 서비스 업데이트가 시스템에 설치되어 있습니다. 거의 모든 새 서비스 레벨에서 JVM 성능 향상을 확인할 수 있습니다.
  • [z/OS]가장 최근 서비스 업데이트가 시스템에 설치되어 있는지 확인하십시오. 거의 모든 새 서비스 레벨에서 JVM 성능 향상을 확인할 수 있습니다.

이 태스크 정보

각 JVM 벤더는 성능 및 해당 JVM의 튜닝에 대한 자세한 정보를 제공합니다. 이 주제에 제공된 정보와 더불어 시스템에서 실행 중인 JVM과 함께 제공되는 정보를 사용하십시오.

[z/OS]제어기 및 하위(servant)는 모두 JVM을 포함합니다. 이 주제에 포함된 정보는 하위의 JVM에만 적용됩니다. 일반적으로 제어기의 JVM은 튜닝할 필요가 없습니다.

Java SE Runtime Environment는 엔터프라이즈 애플리케이션 및 애플리케이션 서버를 실행하기 위한 환경을 제공합니다. 따라서 Java 구성은 애플리케이션 서버 및 실행하는 애플리케이션에 대한 성능 및 시스템 자원 이용 판별 시 중요한 역할을 합니다.

Java용 IBM 가상 머신 버전 6.0은 최신의 Java EE(Java Platform, Enterprise Edition) 스펙을 포함하며, 이전 버전의 Java에 비해 향상된 성능 및 안정성을 제공합니다.

JVM 튜닝이 사용자가 사용하는 JVM 프로바이더에 의존하지만, 모든 JVM에 적용되는 일부 일반 튜닝 개념이 있습니다. 일반 개념은 다음을 포함합니다.

  • 컴파일러 튜닝. 모든 JVM은 JIT(Just-In-Time) 컴파일러를 사용하여 서버 런타임 중에 Java 바이트 코드를 기본 명령어로 컴파일합니다.
  • Java 메모리 또는 힙 튜닝. JVM 메모리 관리 기능 또는 가비지 콜렉션 튜닝은 VM 성능 향상을 위한 좋은 시작점입니다.
  • 클래스 로딩 튜닝
  • 시작 대 런타임 성능 최적화

다음 단계는 각 JVM에 대한 다음 유형의 튜닝을 수행하는 방법에 대한 지시사항을 제공합니다. 단계는 특정 순서로 수행될 필요가 없습니다.

프로시저

  1. [z/OS]특정 상황에서 수행되는 덤프 수를 제한하십시오.

    특정 오류 상황에서는 다중 애플리케이션 서버 스레드가 실패하여 JVM이 해당 스레드 각각에 TDUMP를 요청합니다. 상당수의 스레드가 동시에 실패하는 경우, 동시에 발생한 TDUMP 수로 인해 보조 스토리지 부족과 같은 다른 시스템 문제점이 발생할 수 있습니다. JAVA_DUMP_OPTS 환경 변수를 사용하여 특정 상황에서 JVM이 생성할 덤프 수를 지정하십시오. 이 변수에 지정된 값은 애플리케이션 서버에서 실행 중인 애플리케이션의 com.ibm.jvm.Dump.SystemDump() 호출로 인해 생성되는 TDUMPS 수에 영향을 주지 않습니다.

    예를 들어, 다음과 같은 JVM을 구성하려는 경우,
    • 발생하는 TDUMP 수를 한 개로 제한함
    • 발생하는 JAVADUMP 수를 최대 세 개로 제한함
    • INTERRUPT가 발생하는 경우 문서를 캡처하지 않음
    JAVA_DUMP_OPTS 변수를 다음 값으로 설정하십시오.
    JAVA_DUMP_OPTS=ONANYSIGNAL(JAVADUMP[3],SYSDUMP[1]),ONINTERRUPT(NONE) 
  2. 시작 및 런타임 성능을 최적화하십시오.

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

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

    • -Xquickstart

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

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

      정보
      기본값 높은 초기 컴파일러 최적화 레벨
      권장사항 높은 초기 컴파일러 최적화 레벨
      사용법 -Xquickstart를 지정하면 서버 시작 시간이 향상됩니다.
    [z/OS]JVM 초기화의 속도를 빠르게 하고 서버 시작 시간을 향상시키려면 구성 탭의 일반 특성 섹션에서 일반 JVM 인수 필드에 다음 명령행 인수를 지정하십시오.
    -Xquickstart
    -Xverify:none
  3. 힙 크기를 구성하십시오.

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

    JVM은 할당된 저장영역을 관리하는 데 정의된 임계값을 사용합니다. 임계값에 도달하면, 가비지 콜렉터가 호출되어 사용되지 않은 저장영역을 사용 가능하게 합니다. 그러므로, 가비지 콜렉션을 사용하면 Java 성능이 현저히 저하될 수 있습니다. 초기 및 최대 힙 크기를 변경하기 전에 다음 정보를 고려해야 합니다.
    • 대부분의 경우, 최대 JVM 힙 크기를 초기 JVM 힙 크기보다 큰 값으로 설정해야 합니다. 이 설정은 사용하면 초기 힙 제한 내의 정상적이며 정적인 상태 기간 동안 JVM을 효과적으로 운영할 수 있도록 합니다. 또한 이 설정은 JVM이 최대 JVM 힙 크기에 지정된 값까지 힙을 확장할 수 있으므로 높은 트랜잭션 볼륨 기간 중에도 JVM을 효과적으로 운영할 수 있도록 합니다. 최적화된 성능이 필요한 이례적인 경우에도, 초기 및 최대 힙 크기에 대해 동일한 값을 지정하려고 할 수 있습니다. 이 설정은 JVM을 확장하거나 JVM 힙 크기를 제한해야 할 때 발생하는 일부 오버헤드를 없애줍니다. JVM 힙 크기를 변경하기 전에 JVM 저장영역 할당이 새 힙 크기를 수용할 수 있는 충분히 크기인지 확인하십시오.
    • 초기 힙 크기를 너무 크게 작성하지 마십시오. 그러면 가비지 콜렉션을 지연시켜 초기에는 성능이 향상되지만, 가비지 콜렉션이 발생하면 프로세스가 장시간 실행되어야 하므로 콜렉션 프로세스가 응답 시간에 영향을 미칩니다.

    [z/OS]Java 힙 정보는 SMF 레코드에 포함되어 있으며, DISPLAY,JVMHEAP 콘솔 명령을 사용하여 동적으로 볼 수 있습니다.

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

    1. 관리 콘솔에서 서버 > 서버 유형 > WebSphere 애플리케이션 서버 > server_name을 클릭하십시오.
    2. [AIX Solaris HP-UX Linux Windows][IBM i]서버 인프라 섹션에서 Java 및 프로세스 관리 > 프로세스 정의 > JVM(Java Virtual Machine)을 클릭하십시오.
    3. [z/OS]서버 인프라 섹션에서 Java 및 프로세스 관리 > 프로세스 정의를 클릭하십시오.
    4. [z/OS]제어 또는 하위를 선택한 다음 JVM(Java Virtual Machine)을 선택하십시오.
    5. 초기 힙 크기 또는 최대 힙 크기 필드에 새 값을 지정하십시오.

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

      성능 분석을 위해 초기 및 최대 힙 크기가 같아야 합니다.

      초기 힙 크기 설정은 JVM을 시작할 때 JVM 힙에 할당되는 저장영역 크기(MB)를 지정합니다. 최대 힙 크기 설정은 JVM 힙에 할당할 수 있는 최대 저장영역 크기(MB)를 지정합니다. 이 설정 모두 성능에 상당한 영향을 미칩니다.

      실행 중인 엔터프라이즈 애플리케이션의 작업 세트 크기를 모르는 프로덕션 시스템을 튜닝하는 경우, 초기 힙 크기의 시작 값이 최대 힙 크기의 25%가 되도록 하는 것이 좋습니다. 그러면 JVM이 힙 크기를 애플리케이션의 작업 세트 크기에 맞도록 합니다.

      다음 그림은 각각 다양한 Java 힙 설정을 사용하여 고정된 워크로드를 실행하는 세 개의 CPU 프로파일을 나타냅니다. 중간 프로파일에서, 초기 및 최대 힙 크기는 128MB로 설정됩니다. 네 번의 가비지 콜렉션이 발생합니다. 가비지 콜렉션의 총 시간은 총 실행의 약 15%입니다. 최상위 프로파일에서 힙 매개변수를 두 배인 256MB로 설정하면 가비지 콜렉션 사이의 작업 시간이 늘어납니다. 세 번의 가비지 콜렉션만이 발생하지만, 각 가비지 콜렉션의 길이도 늘어납니다. 세 번째 프로파일에서, 힙 크기가 64MB로 줄어들고 역효과가 나타납니다. 더 작은 힙 크기를 사용하면 가비지 콜렉션 사이의 시간과 각 가비지 콜렉션의 시간이 더 짧아집니다. 세 가지 구성 모두 가비지 콜렉션의 총 시간은 약 15%입니다. 이 예는 Java 힙과 오브젝트 이용에 대한 힙의 관계에 관한 중요한 개념을 보여줍니다. 가비지 콜렉션의 비용은 엔터프라이즈 애플리케이션을 실행하는 경우 항상 존재합니다.

      다양한 Java 힙 설정값

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

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

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

      [z/OS]페이징이 발생하면, 힙의 크기를 줄이거나 더 많은 메모리를 시스템에 추가하십시오.

      모든 실행이 완료되면 GCStats의 다음 통계를 비교하십시오.
      • 가비지 콜렉션 호출 수
      • 단일 가비지 콜렉션 호출의 평균 지속 기간
      • 단일 가비지 콜렉션 호출 길이와 호출 사이의 평균 시간 사이의 비율

      애플리케이션이 오브젝트를 과도하게 사용하지 않고 메모리 누수도 없는 경우 안정된 메모리 이용 상태에 도달합니다. 가비지 콜렉션도 드물게 그리고 짧은 지속 기간 동안 발생합니다.

      힙 여유 공간이 85% 이상으로 고정되는 경우, 애플리케이션 서버와 애플리케이션이 힙에 할당된 메모리를 적게 이용하고 있으므로 최대 힙 크기 값을 줄이는 것이 좋습니다.

      [z/OS]64비트 모드에서 실행하도록 구성된 서버가 있는 경우에는 기본 설정보다 훨씬 큰 서버에 JVM 최대 힙 크기를 지정할 수 있습니다. 예를 들어, 서버가 64비트 모드에서 실행되도록 구성된 경우에는 제어기 및 하위(servant)에 초기 최대 힙 크기를 1844MB로 지정할 수 있습니다.

    6. 적용을 클릭하십시오.
    7. 저장을 클릭하여 변경사항을 마스터 구성에 저장하십시오.
    8. 애플리케이션 서버를 중지했다가 다시 시작하십시오.

    또한 다음 명령행 매개변수를 사용하여 이들 설정을 조정할 수 있습니다. 이러한 매개변수는 지원되는 모든 JVM에 적용되며 각 애플리케이션 서버 또는 애플리케이션 서버 인스턴스에 대한 최소 및 최대 힙 크기를 조정하는 데 사용됩니다.

    • -Xms

      이 매개변수는 Java 힙의 초기 크기를 제어합니다. 이 매개변수를 튜닝하면 가비지 콜렉션의 오버헤드가 줄어들고, 서버 응답 시간 및 처리량이 개선됩니다. 일부 애플리케이션의 경우 이 옵션에 대한 기본 설정이 너무 낮아서 사소한 가비지 콜렉션의 수가 높아질 수 있습니다.

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

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

      정보
      기본값 기본적으로, JVM은 시스템에서 사용 가능한 메모리에 따라 동적으로 Java 힙 크기를 계산합니다.
      권장사항 워크로드에 따라 다르지만, 사용 가능한 실제 메모리의 양에 따라 기본값보다 더 큽니다.
      사용법 -Xmx512m을 지정하면 최대 힙 크기가 512MB로 설정됩니다.
      참고: 메모리 부족 문제 발생을 방지하려면 -Xmx 매개변수에 값을 지정하십시오.
    • [AIX][Windows][IBM i]-Xlp

      Java용 IBM 가상 머신과 함께 이 매개변수를 사용하여 대형 페이지(예: 6MB 페이지)를 사용할 때 힙을 할당하십시오. 이 매개변수를 지정하기 전에 운영 체제가 대형 페이지를 지원하도록 구성되었는지 확인하십시오. 대형 페이지를 사용하면 힙 메모리를 추적하기 위해 필요한 CPU 오버헤드를 줄일 수 있으며 또한 더 큰 힙의 작성을 허용할 수 있습니다.

      기본값
      Java 8을 사용 중인 경우 64KB
    • [IBM i][AIX]–Xlp64k

      이 매개변수는 중간 크기 페이지(예: 64KB)를 사용하는 힙을 할당하는 데 사용될 수 있습니다. 애플리케이션에 필요한 메모리에 대해 이 가상 메모리 페이지 크기를 사용하면 더 큰 페이지 크기와 연관되는 하드웨어 효율성으로 인해 애플리케이션의 성능과 처리량을 향상시킬 수 있습니다.

      [IBM i][AIX]i5/OS™ 및 AIX®는 64KB의 페이지가 일반 용도의 페이지로 설계되었으므로 64KB 정도의 페이지를 충분히 지원합니다. 64KB 페이지는 손쉽게 사용 가능하게 설정할 수 있으며, 애플리케이션은 64KB 페이지가 사용될 때 성능 혜택을 받을 수 있습니다. 이 설정은 운영 체제 구성을 변경하지 않고 변경될 수 있습니다. 그러나 64KB 페이지를 사용하는 경우에는 애플리케이션 서버를 별도의 스토리지 풀에서 실행하는 것이 좋습니다.

      권장사항
      가능하면 64KB 페이지 크기를 사용하십시오.

      [IBM i]i5/OS POWER5+ 시스템 및 i5/OS 버전 6, 릴리스 1은 64KB 페이지 크기를 지원합니다.

      [AIX]POWER5+ 시스템 및 5300-04 권장 유지보수 패키지가 포함된 AIX 5L™ 버전 5.3은 64비트 커널을 실행할 때 64KB 페이지 크기를 지원합니다.

    • [IBM i][AIX]–Xlp4k

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

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

      권장사항
      가능하면 -Xlp4k 대신 -Xlp64k를 사용하십시오.
  4. Java 메모리를 튜닝하십시오.
    Java 언어로 작성된 엔터프라이즈 애플리케이션은 복잡한 오브젝트 관계를 포함하며 많은 수의 오브젝트를 사용합니다. Java 언어가 자동으로 오브젝트 라이프 사이클과 연관되는 메모리를 관리하는 경우에도 오브젝트에 대한 애플리케이션 사용 패턴을 이해하는 것이 중요합니다. 특히 다음 조건이 존재하는지 확인하십시오.
    • 애플리케이션이 오브젝트를 과도하게 이용하고 있지 않습니다.
    • 애플리케이션이 오브젝트를 누출하지 않고 있습니다.
    • Java 힙 매개변수가 주어진 오브젝트 사용 패턴을 처리하기에 적합하게 설정되었습니다.
    1. 오브젝트가 과도하게 사용되는지 검사하십시오.

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

      [IBM i][AIX Solaris HP-UX Linux Windows]가비지 콜렉션 사이의 평균 시간에 대한 최적의 결과는 최소한 단일 가비지 콜렉션의 평균 지속 시간의 5 - 6배입니다. 이 수치에 도달하지 않는 경우, 애플리케이션은 가비지 콜렉션에서 해당 시간의 15%를 초과하여 사용합니다.

      [z/OS]JVM 런타임에 대한 카운터를 관찰하여 애플리케이션이 오브젝트를 과도하게 사용 중인지를 확인할 수 있습니다. JVMTI(Java Virtual Machine Profiler Interface) 카운터를 사용 가능하게 설정하려면 JVM 모듈 최대 레벨뿐만 아니라 -XrunpmiJvmtiProfiler 명령행 옵션도 지정해야 합니다. 가비지 콜렉션 사이의 평균 시간에 대한 최적의 결과는 최소한 단일 가비지 콜렉션의 평균 지속 시간의 5 - 6배입니다. 이 수치에 도달하지 않는 경우, 애플리케이션은 가비지 콜렉션에서 해당 시간의 15%를 초과하여 사용합니다.

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

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

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

      높은 워크로드는 종종 생산 환경에서의 배치 직후에 애플리케이션이 손상되는 원인이 됩니다. 애플리케이션에 메모리 누수가 있는 경우, 워크로드가 많으면 누수 확대가 가속화될 수 있으며 이렇게 되면 메모리 할당에 실패합니다.

      메모리 누수 테스트의 목적은 숫자를 늘리는 것입니다. 메모리 누수는 가비지 콜렉션을 수행할 수 없는 바이트 또는 킬로바이트 크기로 측정됩니다. 어려운 태스크는 이러한 양을 사용 가능한 메모리와 사용 불가능한 메모리의 예상 크기를 구분하는 것입니다. 이 태스크는 숫자가 증대되어 그 결과로 차이가 더 커지고 불일치를 더 쉽게 식별할 수 있게 되는 경우 보다 쉽게 완료됩니다. 다음 목록은 메모리 누수 테스트의 결과를 해석하는 방법에 대한 정보를 제공합니다.
      • 장기 실행 테스트

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

      • 반복적인 테스트

        많은 경우에 메모리 누수 문제점은 같은 테스트 사례에 대해 연속해서 반복적으로 발생합니다. 메모리 누수 테스트의 목적은 상대적인 크기에 따라 사용되지 않는 메모리와 사용된 메모리 사이에 큰 차이를 만드는 것입니다. 다시 같은 시나리오를 반복함으로써 매우 점진적인 방법으로 차이를 배가시킵니다. 이 테스트는 테스트 사례의 실행에 의해 유발되는 누출 수가 한 번의 실행에서 알기 어려울 만큼 작은 경우에 도움이 됩니다.

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

      • 동시성 테스트

        일부 메모리 누수 문제점은 여러 스레드가 해당 애플리케이션에서 실행되는 경우에만 발생할 수 있습니다. 불행히도 프로그램 논리에 복잡성이 추가되었기 때문에 동기화 지점에서 메모리 누수 생성 가능성이 매우 높습니다. 주의하지 않고 프로그래밍하면 보존되거나 해제되지 않은 참조를 유발할 수 있습니다. 메모리 누수 사고는 시스템에서 동시성 증가로 인해 쉽게 발생하거나 가속화됩니다. 가장 일반적인 동시성 증가 방법은 테스트 드라이버의 클라이언트 수를 늘리는 것입니다.

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

      [AIX Solaris HP-UX Linux Windows][IBM i]Tivoli Performance Viewer를 사용하여 메모리 누수를 찾을 수 있습니다.

      [IBM i][AIX Solaris HP-UX Linux Windows]최적의 결과를 얻기 위해서는 1,000, 2,000 및 4,000 페이지 요청과 같이 기간을 늘려 실험을 반복해야 합니다. 사용되는 메모리의 Tivoli Performance Viewer 그래프에는 톱니 모양이 있어야 합니다. 그래프에서의 각 낙하는 가비지 콜렉션에 해당됩니다. 다음 조건 중 하나가 그래프에 표시되면 메모리 누수가 있습니다.
      • 각 가비지 콜렉션 바로 다음에 사용되는 메모리 양이 현저하게 증가합니다. 이 조건이 발생하면, 톱니 모양의 패턴이 더 계단 같이 보입니다.
      • 톱니 모양 패턴의 형태가 불규칙합니다.
      • 할당된 오브젝트 수와 해제된 오브젝트 수 사이의 차이로 초과 시간이 증가합니다.

      애플리케이션 서버가 일관적으로 거의 100%의 CPU를 사용하는 동안 가능한 누수를 나타내지만 워크로드가 가볍거나 거의 유휴 상태가 될 때는 나타나지 않는 힙 이용은 힙 단편화의 표시입니다. 힙 단편화는 JVM이 가비지 콜렉션 주기 동안 메모리 할당 요청을 충족시키기 위해 충분한 오브젝트를 사용 가능하게 만들 수 있지만 JVM이 힙의 작은 사용 가능 메모리 영역들을 더 큰 연속 공간으로 압축할 시간이 없는 경우 발생할 수 있습니다.

      또 다른 힙 단편화 양식은 512바이트 미만인 오브젝트가 사용 가능한 경우에 발생합니다. 오브젝트가 사용 가능하게 되지만, 저장영역이 복구되지 않아서 힙 압축이 발생할 때까지 메모리 단편화를 가져옵니다.

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

  5. 가비지 콜렉션 튜닝

    [z/OS]JVM은 병렬 가비지 콜렉터를 사용하여 대부분의 가비지 콜렉션 주기 동안 SMP를 완전히 배치합니다.

    Java 가비지 콜렉션을 조사하면 애플리케이션의 메모리 이용 방식에 대한 통찰을 얻을 수 있습니다. 가비지 콜렉션은 Java의 장점입니다. Java 애플리케이션은 애플리케이션 작성자로부터 메모리 관리 부담을 덜어서 가비지 콜렉션을 제공하지 않는 언어로 작성된 애플리케이션보다 더 강력해진 경향이 있습니다. 이 견고함은 애플리케이션이 오브젝트를 남용하지 않는 한 적용됩니다. 가비지 콜렉션은 보통 적절하게 기능하는 애플리케이션의 총 런타임의 5 - 20%를 사용합니다. 관리하지 않을 경우, 가비지 콜렉션은 애플리케이션의 가장 큰 병목 현상 중 하나입니다.

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

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

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

    JVM 가비지 콜렉션 설정을 조정하려면 다음을 수행하십시오.

    1. 관리 콘솔에서 서버 > 서버 유형 > WebSphere 애플리케이션 서버 > server_name을 클릭하십시오.
    2. [AIX Solaris HP-UX Linux Windows][IBM i]서버 인프라 섹션에서 Java 및 프로세스 관리 > 프로세스 정의 > JVM(Java Virtual Machine)을 클릭하십시오.
    3. [AIX Solaris HP-UX Linux Windows][IBM i]일반 JVM 인수 필드에 변경하려는 –X 옵션을 입력하십시오.
    4. [z/OS]서버 인프라 섹션에서 Java 및 프로세스 관리 > 프로세스 정의 > 하위(servant)를 클릭하십시오.
    5. [z/OS]추가 특성 아래에서 환경 항목을 클릭하십시오.
    6. [z/OS]다음과 같이 IBM_JAVA_OPTIONS에 대한 환경 항목을 추가 또는 업데이트하십시오.
      1. 기존 환경 항목 IBM_JAVA_OPTIONS가 표시되는 경우, 추가할 –X Java 옵션을 기존 값에 첨부하도록 편집하십시오.
      2. 그렇지 않으면, 새로 작성을 클릭하여 새 환경 항목을 작성하십시오. 양식의 각 필드에 다음 값을 입력하십시오.
        정보
        이름: IBM_JAVA_OPTIONS
        값: 추가할 –X Java 옵션
        설명: 해당 옵션에 대한 설명

      [z/OS]이 프로시저는 WebSphere Application Server 구성 디렉토리에 있는 was.env 파일을 업데이트합니다. 변경은 설정값을 모든 하위(servant), 제어 및 부속 영역에 적용합니다.

    7. 적용을 클릭하십시오.
    8. 저장을 클릭하여 변경사항을 마스터 구성에 저장하십시오.
    9. 애플리케이션 서버를 중지했다가 다시 시작하십시오.

    다음 목록에서는 다른 JVM 가비지 콜렉터에 대한 –X 옵션에 대해 설명합니다.

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

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

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

      gcpolicygencon으로 설정하면 동시 표시가 사용 불가능합니다. 일시정지 시간 문제점이 있음을 나타내는 오류가 있는 애플리케이션 응답 시간이 발생하지 않으면 gencon 정책을 사용할 때 최상의 처리량 결과를 얻게 됩니다.

      gcpolicyoptavgpause로 설정하면 기본값을 갖는 동시 표시가 사용 가능합니다. 이 설정은 일반 가비지 콜렉션에 의해 유발되는 오류가 있는 애플리케이션 응답 시간을 완화시킵니다. 그러나 이 옵션은 전체 처리량을 줄일 수 있습니다.

    • -Xnoclassgc

      기본적으로 JVM은 클래스의 활동하는 인스턴스가 없을 때 메모리에서 해당 클래스를 로드 해제합니다. 동일한 클래스를 여러 번 로드 및 로드 해제하는 오버헤드는 성능을 감소시킵니다.

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

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

      정보
      기본값 클래스 가비지 콜렉션이 사용 가능합니다.
      권장사항

      클래스 가비지 콜렉션을 사용 불가능하게 하지 마십시오.

      사용법 Xnoclassgc를 지정하여 클래스 가비지 콜렉션을 사용 불가능하게 하십시오.
  6. localhost 이름 캐싱 사용 기본적으로 Java용 IBM SDK에서 정적 메소드 java/net/InetAddress.getLocalHost는 해당 결과를 캐싱하지 않습니다. 이 메소드는 WebSphere Application Server를 통해 특히, 배치 관리자 및 노드 에이전트와 같은 관리 에이전트에서 사용됩니다. 프로세스의 localhost 주소가 프로세스가 실행 중인 동안 변경되지 않는 경우, com.ibm.cacheLocalHost 시스템 특성 값을 true로 설정하여 localhost 검색에 대해 내장 캐시를 사용하도록 권장합니다. 다양한 유형의 프로세스에 JVM 사용자 정의 특성을 설정하는 데 대한 지시사항은 Information Center의 JVM(Java Virtual Machine) 사용자 정의 특성 주제를 참조하십시오.
    참고: DHCP 변경을 사용하여 구성된 서버의 주소는 시간이 경과함에 따라 변경됩니다. 서버에서 정적으로 지정된 IP 주소를 사용하지 않으면 이 특성을 설정하지 마십시오.
    정보
    기본값 com.ibm.cacheLocalHost = false
    권장사항 com.ibm.cacheLocalHost = true(설명 참조)
    사용법 -Dcom.ibm.cacheLocalHost=true에서 getLocalHost 캐시를 사용하도록 지정
  7. 캐시에서 클래스 공유를 사용 가능하게 하십시오.

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

    [IBM i]이 옵션은 애플리케이션 서버에서 기본적으로 사용 가능합니다. 캐시를 지우려면 app_server_root/bin/clearClassCache 유틸리티를 호출하거나, 애플리케이션 서버를 중지한 다음 다시 시작하십시오.

    [z/OS][AIX Solaris HP-UX Linux Windows]이 옵션을 사용하면 프로세스가 사용 중이지 않을 때 캐시를 지워야 합니다. 캐시를 지우려면 app_server_root/bin/clearClassCache.bat/sh 유틸리티를 호출하거나 프로세스를 중지한 후 프로세스를 다시 시작하십시오.

    참고: clearclasscache를 사용하는 경우 전체 캐시를 지우려면 첨부된 모든 JVM을 중지해야 합니다.

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

    1. 관리 콘솔에서 서버 > 서버 유형 > WebSphere 애플리케이션 서버 > server_name을 클릭하십시오.
    2. [AIX Solaris HP-UX Linux Windows][IBM i]서버 인프라 섹션에서 Java 및 프로세스 관리 > 프로세스 정의 > JVM(Java Virtual Machine)을 클릭하십시오.
    3. [z/OS]서버 인프라 섹션에서 Java 및 프로세스 관리 > 프로세스 정의를 클릭하십시오.
    4. [z/OS]제어 또는 하위를 선택한 다음 JVM(Java virtual machine을 선택하십시오.
    5. 일반 JVM 인수 필드에 -Xshareclasses:none를 입력하십시오.
    6. 확인을 클릭하십시오.
    7. 저장을 클릭하여 변경사항을 마스터 구성에 저장하십시오.
    8. 애플리케이션 서버를 중지했다가 다시 시작하십시오.
    정보
    기본값 캐시 옵션의 공유 클래스가 사용 가능합니다.
    권장사항 캐시에서 클래스 공유 옵션을 사용 가능으로 두십시오.
    사용법 -Xshareclasses:none은 캐시에서 클래스 공유 옵션을 사용 불가능하게 설정합니다.
  8. [AIX Solaris HP-UX Linux Windows][z/OS]64비트 환경에서 압축 참조를 사용 가능하게 설정하십시오.

    [z/OS][AIX Solaris HP-UX Linux Windows]64비트 환경(예: AIX 64, Linux PPC 64, zLinux 64 및 Microsoft Windows AMD64, Linux AMD64)에서 압축 참조를 사용 가능하게 설정할 수 있습니다.

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

    IBM 64비트 JRE(Java SE Runtime Environment) 버전 6.0 구현의 압축 참조 옵션을 사용하면 모든 메모리 참조를 32비트 크기로 제한할 수 있습니다. 일반적으로 64비트 JVM은 64비트 와이드 메모리 참조를 사용하여 메모리의 주소를 지정하므로 32비트 JVM보다 더 많은 힙 크기를 사용합니다. 64비트 참조로 주소 지정 가능한 힙은 32비트 힙보다 큰 개략 산정이지만, 실제로 주소 지정에 64비트가 모두 필요한 힙은 일반적으로 필요하지 않습니다. 참조를 압축하면 주소 크기가 줄어들고, 힙 사용을 보다 효율적으로 만듭니다. 또한 이러한 참조를 압축하면 프로세서 캐시 및 버스 활용이 향상되므로 성능도 향상됩니다.

    유의:
    압축 참조 기능은 다음에서 지원되지 않습니다.
    • HP-UX 64비트 JVM
    • iSeries Classic 64비트 JVM
    [z/OS]64비트 JVM을 압축 참조 모드에서 실행할 수 있도록 설정하려면 WebSphere Application Server 구성에서 새 환경 변수를 지정해야 합니다. 관리 콘솔에서:
    1. 서버 > 서버 유형 > WebSphere 애플리케이션 서버 > server_name을 클릭하십시오.
    2. 구성 탭을 클릭하십시오. 서버 인프라 아래에서 Java 및 프로세스 관리 > 프로세스 정의 > 하위(servant)를 클릭하십시오.
    3. 추가 특성 아래에서 환경 항목을 클릭하십시오.
      다음과 같이 IBM_JAVA_OPTIONS에 대한 환경 항목을 추가 또는 업데이트하십시오.
      1. 기존 환경 항목 IBM_JAVA_OPTIONS가 표시되는 경우, 기존 값에 Java 옵션을 추가하도록 편집하십시오.
      2. 그렇지 않으면, 새로 작성을 클릭하여 새 환경 항목을 작성하십시오. 양식의 각 필드에 다음 값을 입력하십시오.
        정보
        이름: IBM_JAVA_OPTIONS
        값: -Xcompressedrefs
        설명: 64비트 압축 참조 모드를 사용 가능하게 설정
    [z/OS]이 프로시저는 WebSphere Application Server 구성 디렉토리에 있는 was.env 파일을 업데이트합니다. 변경은 설정값을 모든 하위(servant), 제어 및 부속 영역에 적용합니다.
    유의: Xcompressedrefs를 일반 JVM 인수로 제공하면, 지원되지 않는 Java 옵션 오류로 인해 WebSphereApplication Server가 시작되지 않습니다. 애플리케이션에 30GB보다 큰 Java 힙이 필요한 경우, 64비트 기본 모드를 사용해야 합니다.

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

    [z/OS]참고: WebSphere Application Server for z/OS는 포인터 압축기를 사용으로 자동 설정하지 않습니다. 사용자가 명령행 옵션을 사용하여 포인터 압축을 수동으로 사용 가능하게 할 것을 권장합니다.
    참고: Java 8 SR2 FP10 또는 z/OS Java 8 SR3의 경우, -Xcompressedrefs 옵션은 기본적으로 최대 57GB까지 사용 가능하며 플랫폼에 따라 더 높은 값으로 사용할 수 있습니다.
    다음 명령행 옵션은 압축 참조 기능을 제어합니다.
    -Xcompressedrefs
    이 명령행 옵션은 압축 참조 기능을 사용 가능으로 설정합니다. 이 명령으로 JVM을 실행하면 힙을 주소 지정하는 데 32비트 와이드 메모리 참조가 사용됩니다. 이 기능은 -Xmx 매개변수로 제어되는 특정 힙 크기(플랫폼에 따라 약 29GB)까지 사용될 수 있습니다.
    -Xnocompressedrefs
    이 명령행 옵션은 압축 참조 기능을 명시적으로 사용 불가능하게 설정합니다. 이 명령으로 JVM을 실행하면 힙을 주소 지정하는 데 전체 64비트 와이드 메모리 참조가 사용됩니다. 사용자는 필요에 따라 이 옵션을 사용하여 포인터 압축의 기본 사용을 대체할 수 있습니다.
  9. 대형 셀 구성의 구성 업데이트 프로세스를 튜닝하십시오.
    큰 셀 구성에서는 구성 업데이트 성능이 보다 중요한지 또는 일관성 점검이 보다 중요한지 여부를 결정해야 할 수도 있습니다. 배치 관리자는 전체 셀에 대한 마스터 구성 저장소를 유지보수합니다. 기본적으로 구성이 변경되면 제품은 작업공간의 구성을 마스터 저장소와 비교하여 작업공간 일관성을 유지보수합니다. 그러나 일관성 확인 프로세스는 구성 변경을 저장하거나 많은 수의 애플리케이션을 배치하는 데 필요한 시간을 늘리는 원인이 될 수 있습니다. 다음 요소는 필요한 시간량에 영향을 미칩니다.
    • 셀에 정의된 애플리케이션 서버 또는 클러스터가 많을수록 구성 변경을 저장하는 데 많은 시간이 소요됩니다.
    • 셀에 배치된 애플리케이션이 많을수록 구성 변경을 저장하는 데 많은 시간이 소요됩니다.
    구성 변경을 변경하는 데 필요한 시간이 불충분한 경우, JVM 설정에 config_consistency_check 사용자 정의 특성을 추가하고 이 특성 값을 false로 설정할 수 있습니다.
    1. 관리 콘솔에서 시스템 관리 > 배치 관리자를 클릭하십시오.
    2. 서버 인프라에서 Java 및 프로세스 관리를 선택한 다음 프로세스 정의를 클릭하십시오.
    3. 추가 특성 아래에서 JVM(Java Virtual Machine) > 사용자 정의 특성 > 새로 작성을 클릭하십시오.
    4. 이름 필드에 config_consistency_check를 입력하고 값 필드에 false를 입력하십시오.
    5. 확인을 클릭한 후 저장을 클릭하여 마스터 구성에 이러한 변경사항을 적용하십시오.
    6. 서버를 다시 시작하십시오.
    지원된 구성 지원된 구성: config_consistency_check 사용자 정의 특성은 배치 관리자 프로세스에만 영향을 미칩니다. 이는 노드 에이전트를 포함한 다른 프로세스 및 애플리케이션 서버 프로세스에는 영향을 미치지 않습니다. 이러한 프로세스에서는 일관성 점검이 수행되지 않습니다. 그러나 해당 프로세스에 대한 SystemOut.log 파일 내에 일관성 점검이 사용 불가능하다는 메시지가 있을 수 있습니다. 이러한 비배치 관리자 프로세스의 경우, 이 메시지를 무시할 수 있습니다.sptcfg

    로컬 모드에서 wsadmin 명령 wsadmin -conntype none을 사용하는 경우, 이 명령을 발행하기 전에 config_consistency_check 특성을 false로 설정해야 합니다.

다음에 수행할 작업

JVM이 수행되는 방식에 만족할 때까지 변경을 튜닝하면서 데이터를 계속 수집하고 분석하십시오.

주제 유형을 표시하는 아이콘 태스크 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tprf_tunejvm_v61
파일 이름:tprf_tunejvm_v61.html