프로그래밍 관련/언어들의 코딩들 C++ JAVA C# 등..

JAVA 실행 시 Heap 설정 메모리 설정 관련

AlrepondTech 2016. 6. 1. 13:57

=================================

출처: http://egloos.zum.com/jimbo73/v/1486455

java application 실행 시, 옵션을 주어 가용한 초기 및 최대치의 heap memory 설정을 변경해보자.

옵션은 -Xms와 -Xmx로, 전자는 application 실행 시 초기의 heap memory의 크기를 설정하며, 후자의 경우는 application 사용중 최대 이용할 수 있는 heap memory의 크기를 설정하는 옵션이다.

이 옵션을 안주었을 경우는 가상머신을 제작하는 밴더에 따라 다르지만, 평균적으로 초기시는 1~2M, 최대치는 64M를 할당한다고 한다.

사용 범례는 java -Xms64m -Xmx128m test

초기 최소 메모리는 64M를, 최대 메모리는 128M로 설정한것이다.

덧글

=================================

출처: http://wkqqn.tistory.com/entry/JAVA-%EC%8B%A4%ED%96%89-%EC%8B%9C-Heap-%EC%84%A4%EC%A0%95

오랜만에 콘솔로 컴파일과 실행 패키징을 하다보니..넘 오래되서

인터넷 검색으로 옵션을 찾아야 했다..-_-;

맨날 bat 파일이나 ant 로 전에 만들어 놓은거 copy & paste 하니깐...

콘솔에서 손가락이 순간 순간 마비되는 느낌이다..

아련한 기억 속에 남아있는 MANIFEST.MF 를 작성하는 경우에도

속성: 값

이부분에서 : 다음 띄워쓰기해야 하는 것도 까먹어서..왜 jar 시

에러가 나는지도 한 참을 생각하다 검색으로 찾았다..ㅠㅠ

암튼 JVM 의 메모리 설정을 하는 부분을 찾다가 이런 옵션이 있는 줄 첨 알았다.

java -Xms512m -Xmx1024m -jar MemoryDump.jar

최소 메모리 값과 최대 메모리 값 설정 후 jar 파일을 실행시키는 부분이다.

암튼 안 쓰고 안 보면 금방 기억 속에서 사라진다.

기본 내공이 부족해서 그런가...

=================================

출처: https://hetzer7.wordpress.com/2015/07/09/java-jvm-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EC%84%A4%EC%A0%95/

JVM(Java Virtual Machine) 성능 조정

Application Server는 Java 기반 프로세스이며 Application Server에서 실행하는 Java 응용프로그램을 실행하고 지원하기 위해 JVM(Java Virtual Machine)이 필요합니다. Java 런타임 환경을 구성하여 성능 및 시스템 자원 사용도를 조정할 수 있습니다. 이 주제는 IBM Technology for Java Virtual Machine에 적용됩니다. i5/OS 제품에 제공되는 IBM Developer Kit for Java를 사용할 경우 Classic JVM 조정 주제를 참조하십시오.

시작하기 전에

Application Server가 실행 중인 JVM의 유형을 판별하십시오.Application Serverapp_server_root/java/bin 디렉토리에서 java –fullversion 명령을 발행하십시오. 이 명령에 대한 응답으로 Application Server가 JVM 프로바이더 정보를 포함한 JVM 관련 정보를 SystemOut.log파일에 기록합니다.
다음을 확인하십시오.
1. JVM의 가장 최근 지원되는 버전이 시스템에 설치되어 있습니다.
2. 가장 최근 서비스 갱신이 시스템에 설치되어 있습니다. 거의 모든 새 서비스 레벨에서 JVM 성능 향상을 확인할 수 있습니다.

이 타스크 정보

Java 런타임 환경은 WebSphere Application Server 같은 Java 기반 응용프로그램 및 서버를 위한 실행 환경을 제공합니다. 그러므로 Java 구성이 제품 및 실행하는 응용프로그램에 대한 성능 및 시스템 자원 이용을 판별할 때 중요한 역할을 합니다.

지원되는 JVM은 다른 JVM 프로바이더에서 사용할 수 있습니다. 여기에는 다음이 포함됩니다.

Java용 IBM 가상 시스템.IBM Java 5.0 이상의 버전에는 IBM의 이전 Java 실행 기술 이상의 중대한 성능 및 서비스 가능성 향상을 제공하기 위해 가상 시스템 기술의 중요한 개선사항이 포함됩니다. 새로운 기술에 대한 자세한 정보는http://www.ibm.com/software/webservers/appserv/was/performance.html 웹 사이트를 참조하십시오.
HotSpot 기반 JVM(예: Solaris의 the Java HotSpot VM)
HP-UX의 Java용 HP 가상 시스템

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

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

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

프로시저

시작 및 런타임 성능을 최적화하십시오.개발 환경 같은 일부 환경에서는 런타임 성능보다 Application Server의 시작 성능을 최적화하는 것이 더 중요합니다. 다른 환경에서는 런타임 환경을 최적화하는 것이 더 중요합니다. 기본적으로, IBM 가상 시스템은 런타임 환경을 위해 최적화되는 반면 HotSpot 기반 JVM은 시작 성능을 위해 최적화됩니다.Java JIT(Just-In-Time) 컴파일러는 시작 또는 런타임 성능이 최적화되는지 여부에 큰 영향을 줍니다. 컴파일러가 사용하는 초기 최적화 레벨이 클래스 메소드를 컴파일하는 데 걸리는 시간과 서버를 시작하는 데 걸리는 시간에 영향을 줍니다. 더 빠른 시작을 위해 컴파일러가 사용하는 초기 최적화 레벨을 줄여야 합니다. 그러나 초기 최적화 레벨을 줄이는 경우 클래스 메소드가 이제 더 낮은 최적화 레벨에서 컴파일되기 때문에 응용프로그램의 런타임 성능이 저하될 수 있습니다.
- -Xquickstart이 설정은 IBM 가상 시스템이 클래스 메소드 컴파일에 대해 더 낮은 최적화 레벨을 사용하는 방법에 영향을 줍니다. 낮은 최적화 레벨은 더 빠른 서버 시작을 제공하지만 런타임 성능이 낮아집니다. 이 매개변수가 지정되지 않는 경우, IBM 가상 시스템은 기본적으로 컴파일에 대해 높은 초기 최적화 레벨로 시작하며, 이는 더 빠른 런타임 성능을 제공하지만 서버 시작이 더 느립니다.
  
  기본값: 높은 초기 컴파일러 최적화 레벨
  
  권장: 높은 초기 컴파일러 최적화 레벨
  
  사용법: -Xquickstart는 더 빠른 서버 시작을 제공합니다.
핫스팟 기반 JVM은 초기에는 낮은 최적화 레벨로 클래스 메소드를 컴파일합니다. 이 JVM 옵션을 사용하여 동작을 변경하십시오.
특정 상황에서 수행되는 덤프 수를 제한하십시오.특정 오류 상황에서는 복수 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 개발자 킷 진단 안내서를 참조하십시오.

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

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

대부분의 경우 최대 JVM 힙 크기를 초기 JVM 힙 크기보다 큰 값으로 설정해야 합니다. 이것은 최대 JVM 힙 크기까지 힙을 확장하여 초기 힙 제한 내의 정상적이며 정적인 기간 중에 JVM을 효과적으로 운영하는 것 뿐만 아니라 높은 트랜잭션 볼륨 기간 중에도 효과적으로 운영할 수 있도록 해줍니다. 절대적인 최적 성능이 필요한 일부 드믄 경우에도 초기 및 최대 힙 크기에 대해 동일한 값을 지정하고자 할 수 있습니다. 이것은 JVM을 확장해야 하거나 JVM 힙 크기를 제한해야 할 때 발생하는 일부 오버헤드를 없애줍니다. 영역이 지정된 JVM 힙을 보유할만큼 충분한 크기인지 확인하십시오.
초기 힙 크기를 너무 크게 설정해서는 안 됩니다. 처음에는 대형 힙 크기가 가비지 콜렉션을 지연시켜 성능을 향상시킬 수 있지만, 결과적으로 가비지 콜렉션이 실제로 작동되면 콜렉션 프로세스에 오랜 시간이 소요되므로 결국 대형 힙 크기가 응답 시간에 영향을 줍니다.

developerWorks 웹 사이트에서 구할 수 있는

IBM Developer Kit and Runtime Environment, Java2 Technology Edition, Version 5.0 Diagnostics Guide

가 힙 크기 조정에 대한 추가 정보를 제공합니다.

관리 콘솔에서, 서버 > Application Servers > server를 클릭하십시오.
서버 인프라 섹션에서 Java 및 프로세스 관리 > 프로세스 정의 > JVM(Java Virtual Machine)을 클릭하십시오.
초기 힙 크기 또는 최대 힙 크기 필드에 새 값을 지정하십시오.또한 두 설정을 모두 조정해야 하는 경우 두 필드에 값을 지정할 수 있습니다.
bestprac: 성능 분석을 위해 초기 및 최대 힙 크기가 같아야 합니다.
초기 힙 크기 설정은 JVM을 시작할 때 JVM 힙에 할당되는 기억장치 크기(MB)를 지정합니다. 최대 힙 크기 설정은 JVM 힙에 할당할 수 있는 최대 기억장치 크기(MB)를 지정합니다. 이 설정 모두 성능에 상당한 영향을 미칩니다.
다양한 Java 힙 설정을 사용하여 일련의 테스트 실험을 실행하십시오. 예를 들어, 128MB, 192MB, 256MB 및 320MB를 사용하여 실험을 실행하십시오. 각 실험마다 총 메모리 사용을 모니터하십시오. 힙을 너무 크게 확장하면 페이징이 발생할 수 있습니다. 페이징을 확인하려면vmstat 명령 또는 Windows 2000/2003 성능 모니터를 사용하십시오. 페이징이 발생하면, 힙의 크기를 줄이거나 더 많은 메모리를 시스템에 추가하십시오. 모든 실행이 완료되면 GCStats의 다음 통계를 비교하십시오.
- 가비지 콜렉션 호출 수
- 단일 가비지 콜렉션 호출의 평균 지속 기간
- 단일 가비지 콜렉션 호출 길이와 호출 사이의 평균 시간 사이의 비율
응용프로그램이 오브젝트를 과도하게 사용하지 않고 메모리 누수도 없는 경우 안정된 메모리 이용 상태에 도달합니다. 가비지 콜렉션도 드물게 그리고 짧은 지속 기간 동안 발생합니다.
힙 여유 공간이 85% 이상으로 고정되는 경우, Application Server와 응용프로그램이 힙에 할당된 메모리를 적게 이용하고 있기 때문에 최대 힙 크기 값을 줄이는 것을 고려하십시오.
위의 그림은 각각이 다양한 Java 힙 설정을 사용하여 고정된 워크로드를 실행하는 세 개의 CPU 프로파일을 나타냅니다. 중간 프로파일에서, 초기 및 최대 힙 크기가 128MB로 설정됩니다. 네 번의 가비지 콜렉션이 발생합니다. 가비지 콜렉션의 총 시간은 총 실행의 약 15%입니다. 맨 위 프로파일에서 힙 매개변수를 256MB로 두 배 설정하면 가비지 콜렉션 사이의 작업 시간이 증가됩니다. 세 번의 가비지 콜렉션만이 발생하지만, 각 가비지 콜렉션의 길이도 늘어납니다. 세 번째 프로파일에서, 힙 크기가 64MB로 줄어들고 역효과가 나타납니다. 더 작은 힙 크기를 사용하면 가비지 콜렉션 사이의 시간과 각 가비지 콜렉션의 시간이 더 짧아집니다. 세 가지 구성 모두 가비지 콜렉션의 총 시간은 약 15%입니다. 이 예는 Java 힙과, 오브젝트 이용에 대한 힙의 관계에 관한 중요한 개념을 보여 줍니다. Java 응용프로그램에는 항상 가비지 콜렉션에 대한 비용이 존재합니다.
Java 응용프로그램의 작업 세트 크기를 모르는 생산 시스템을 조정할 때, 시작 값으로 초기 힙 크기가 최대 힙 크기의 25%가 되도록 하는 것이 좋습니다. 그러면 JVM이 힙 크기를 응용프로그램의 작업 세트 크기에 맞도록 합니다.
적용 또는 확인을 클릭하십시오.
마스터 구성에 변경사항을 저장하십시오.
Application Server를 중지했다가 다시 시작하십시오.

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

-Xms이 설정은 Java 힙의 초기 크기를 제어합니다. 이 매개변수를 적절하게 조정하면 가비지 콜렉션의 오버헤드를 줄여서 서버 응답 시간 및 처리량을 개선합니다. 일부 응용프로그램의 경우, 이 옵션에 대한 기본 설정이 너무 낮아서 사소한 가비지 콜렉션의 수가 높아질 수 있습니다.

기본값:	50MB. 이 기본값은 31비트 및 64비트 구성 모두에 적용됩니다.
권장:	워크로드에 특정하지만, 기본값보다 높습니다.
사용법:	-Xms256m은 초기 힙 크기를 256MB로 설정합니다.

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

기본값:	256MB. 이 기본값은 31비트 및 64비트 구성 모두에 적용됩니다.
권장:	워크로드에 특정하지만, 사용 가능한 실제 메모리의 양에 따라서 기본값보다 높습니다.
사용법:	-Xmx512m은 최대 힙 크기를 512MB로 설정합니다.

-Xlp이 설정은 IBM 가상 시스템과 함께 사용되어 대형 페이지(16MB)를 사용할 때 힙을 할당합니다. 그러나 이 설정을 사용하는 경우 운영 체제가 대형 페이지를 지원하도록 구성되어야 합니다. 대형 페이지를 사용하면 힙 메모리를 추적하기 위해 필요한 CPU 오버헤드를 줄일 수 있으며 또한 더 큰 힙의 작성을 허용할 수 있습니다.운영 체제 조정에 대한 자세한 정보운영 체제 성능 조정의 내용을 참조하십시오.

–Xlp64k이 설정은 IBM 가상 시스템과 함께 사용되 64KB 페이지 크기(중간 페이지)를 사용하는 힙을 할당할 수 있습니다. 응용프로그램에 필요한 메모리에 대해 이 가상 메모리 페이지 크기를 사용하면 더 큰 페이지 크기와 연관되는 하드웨어 효율성 때문에 응용프로그램의 성능과 처리량을 향상시킬 수 있습니다.64KB 페이지 크기를 지원하려면 관리 콘솔에서 서버 > Application Server > server_name > 프로세스 정의 > 환경 항목 > 새로 작성을 클릭한 후 이름 필드에 LDR_CNTRL을 지정하고 값 필드에DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K를 지정하십시오.AIX는 64KB 페이지 근처에서 풍부한 지원을 가지며, 64KB 페이지가 범용으로 사용되기 위한 것입니다. 64KB 페이지가 사용하기가 매우 쉽고, 많은 응용프로그램이 기본 4KB 페이지보다 64KB 페이지를 사용할 때 성능상 이점을 확인할 것으로 예상됩니다. 이 설정은 운영 체제 구성을 변경하지 않고 변경될 수 있습니다.

기본값:	4KB
권장:	-Xlp64k는 64KB 페이지 크기 지원을 사용합니다. 주: POWER5+ 시스템, 5300-04 권장 유지보수 패키지를 갖는 AIX 5L 버전 5.3은 64비트 커널을 실행할 때 새 64KB 페이지 크기를 지원합니다.

관리 콘솔을 사용하여 힙 크기를 구성하려면 다음을 수행하십시오.
Java 메모리 조정
Java 언어로 작성된 엔터프라이즈 응용프로그램은 복잡한 오브젝트 관계를 포함하며 많은 수의 오브젝트를 활용합니다. Java 언어가 자동으로 오브젝트 라이프 사이클과 연관되는 메모리를 관리하는 경우에도 오브젝트에 대한 응용프로그램 사용 패턴을 이해하는 것이 중요합니다. 특히 다음 사항을 확인하십시오.
- 응용프로그램이 오브젝트를 과도하게 이용하고 있지 않습니다.
- 응용프로그램이 오브젝트를 누출하지 않고 있습니다.
- Java 힙 매개변수가 주어진 오브젝트 사용 패턴을 처리하기에 적합하게 설정되었습니다.
1. 오브젝트가 과도하게 사용되는지 검사하십시오.Tivoli Performance Viewer를 사용하여 JVM 런타임에 대한 카운터를 관찰하여 응용프로그램이 오브젝트를 과도하게 사용 중인지를 확인할 수 있습니다. JVMPI(Java Virtual Machine Profiler Interface) 카운터를 사용 가능하게 만들기 위해 JVM 모듈 최대 레벨뿐 아니라 -XrunpmiJvmpiProfiler 명령행 옵션을 설정해야 합니다.가비지 콜렉션 사이의 평균 시간에 대한 최상의 결과는 최소한 단일 가비지 콜렉션의 평균 지속 시간의 5 – 6배입니다. 이 수치에 도달하지 않는 경우, 응용프로그램은 가비지 콜렉션에서 해당 시간의 15%를 초과하여 소비합니다.정보에서 가비지 콜렉션 병목 현상이 나타나면, 두 가지 방식으로 그 병목 현상을 없앨 수 있습니다. 응용프로그램을 최적화하는 비용상 가장 효율적인 방법은 오브젝트 캐시 및 풀을 구현하는 것입니다. 대상으로 할 오브젝트를 판별하려면 Java 프로파일러를 사용하십시오. 응용프로그램을 최적화할 수 없는 경우, 메모리, 프로세서 및 복제본 추가가 도움이 될 수 있습니다. 추가 메모리는 각 복제본이 적절한 힙 크기를 유지할 수 있게 해줍니다. 추가 프로세서는 복제본이 병렬로 실행될 수 있도록 합니다.
2. 메모리 누수를 테스트하십시오.Java 언어에서의 메모리 누출은 가비지 콜렉션 병목 현상을 일으키는 위험한 요소입니다. 메모리 누출은 궁극적으로 시스템 불안정을 야기시키기 때문에 지나친 메모리 활용보다 더 좋지 않습니다. 시간이 지나면서 최종적으로 힙이 고갈되고 Java 코드가 치명적인 메모리 부족 예외와 함께 실패할 때까지 가비지 콜렉션이 더 자주 발생합니다. 메모리 누출은 사용되지 않는 오브젝트가 결코 사용 가능하지 않은 참조를 가질 때 발생합니다. 메모리 누출은 Hashtable 같은 콜렉션 클래스에서 가장 일반적으로 발생하는 데, 이 테이블이 항상, 실제 참조가 삭제된 후에도 오브젝트에 대한 참조를 갖기 때문입니다.높은 워크로드는 종종 생산 환경에서의 전개 직후에 응용프로그램이 손상되는 원인이 됩니다. 이러한 상황은 특히 높은 워크로드가 누출의 확대를 가속화시키고 메모리 할당 실패가 발생하는 누출 응용프로그램의 경우 발생합니다.
  메모리 누출 테스트의 목표는 숫자를 확대하는 것입니다. 메모리 누출은 가비지 콜렉션을 수행할 수 없는 바이트 또는 KB 양으로 측정됩니다. 정밀한 타스크는 이러한 양을 유용한 메모리와 사용 불가능한 메모리의 예상 크기를 차별화하는 것입니다. 이 타스크는 숫자가 증대되어 그 결과로 차이가 더 커지고 불일치를 더 쉽게 식별할 수 있게 되는 경우 보다 쉽게 완료됩니다. 다음 목록에는 메모리 누출에 관한 중요한 결론이 들어있습니다.
  - 장기 실행 테스트메모리 누출 문제점은 일정 기간 후에만 나타날 수 있으므로, 메모리 누출은 장기간 실행되는 테스트 중에 쉽게 발견됩니다. 단기 실행 테스트는 잘못된 알람을 가져올 수 있습니다. 때로는 Java 언어에서 메모리 누출이 발생하고 있을 때, 특히 주어진 기간 동안 메모리 누출이 겉으로는 갑자기 또는 단조롭게 증가했을 때를 알기가 어렵습니다. 메모리 누출을 발견하기가 어려운 이유는 이런 종류의 증가가 유효하거나 개발자의 의도일 수 있다는 점입니다. 장기간 동안 응용프로그램을 실행하여 오브젝트의 지연 사용을 완전히 사용되지 않는 오브젝트와 구별하는 방법을 배울 수 있습니다. 장기 실행 응용프로그램 테스트는 오브젝트의 지연 사용이 실제로 발생하고 있는지 여부의 충분한 증거를 제공합니다.
  - 반복적인 테스트많은 경우에 메모리 누출 문제점은 같은 테스트 사례에 대해 연속해서 반복적으로 발생합니다. 메모리 누출 테스트의 목적은 상대적인 크기에 따라 사용되지 않는 메모리와 사용된 메모리 사이에 큰 차이를 만드는 것입니다. 다시 같은 시나리오를 반복함으로써 매우 점진적인 방법으로 차이를 배가시킵니다. 이 테스트는 테스트 사례의 실행에 의해 유발되는 누출 수가 한 번의 실행에서 알기 어려울 만큼 작은 경우에 도움이 됩니다.시스템 레벨이나 모듈 레벨에서 반복 테스트를 사용할 수 있습니다. 모듈 테스트의 장점은 제어하기 좋다는 것입니다. 모듈이 메모리 사용 같은 외적인 부작용을 만들지 않고 개인용 모듈을 유지하도록 설계될 때, 메모리 누출에 대한 테스트가 더 쉽습니다. 먼저, 모듈 실행 전에 메모리 누출을 기록합니다. 그런 다음, 고정된 테스트 사례 세트를 반복해서 실행합니다. 테스트 실행이 끝나면 현재 메모리 사용을 기록하고 중요한 변화를 점검합니다. 가비지 콜렉션이 발생하기 원하거나 프로파일링 도구를 사용하여 강제로 이벤트를 발생시키는 모듈에서 System.gc()를 삽입하여 실제 메모리 사용을 기록할 때 가비지 콜렉션을 제안해야 한다는 것을 잊지마십시오.
  - 동시성 테스트일부 메모리 누출 문제점은 여러 스레드가 해당 응용프로그램에서 실행되는 경우에만 발생할 수 있습니다. 불행히도 프로그램 논리에 복잡성이 추가되었기 때문에 동기화 지점에서 메모리 누출 생성 가능성이 매우 높습니다. 주의하지 않고 프로그래밍하면 보존되거나 해제되지 않은 참조를 유발할 수 있습니다. 메모리 누출 사고는 시스템에서 동시성 증가로 인해 쉽게 발생하거나 가속화됩니다. 가장 일반적인 동시성 증가 방법은 테스트 드라이버의 클라이언트 수를 늘리는 것입니다.
    메모리 누출 테스트에 사용할 테스트 사례를 선택할 때 다음 사항을 고려하십시오.
    
    좋은 테스트 사례는 오브젝트가 작성된 응용프로그램 부분을 실습합니다. 대부분 응용프로그램에 대한 지식이 필요합니다. 시나리오 설명은 새 레코드 추가, HTTP 세션 작성, 트랜잭션 수행 및 레코드 검색과 같은 데이터 공간 작성을 제시할 수 있습니다.
    
    오브젝트의 콜렉션이 사용되는 위치를 찾으십시오. 일반적으로 메모리 누출은 동일한 클래스 내의 오브젝트로 구성됩니다. 또한 벡터 및 해시 테이블과 같은 콜렉션 클래스는 해당 삽입 메소드를 호출하여 오브젝트 참조를 내재적으로 저장한 위치입니다. 예를 들어, Hashtable 오브젝트의 get 메소드는 검색된 오브젝트에 대한 참조를 제거하지 않습니다.
  Tivoli Performance Viewer를 사용하여 메모리 누수를 찾을 수 있습니다.또한 할당된 오브젝트 수와 해제된 오브젝트 수 사이의 차이를 살펴보십시오. 두 수 사이의 차이로 초과 시간이 증가하면, 메모리 누출이 있는 것입니다.또 다른 힙 단편화 양식은 작은 오브젝트(512 바이트 미만)들이 사용 가능한 경우 발생합니다. 오브젝트가 사용 가능하게 되지만, 기억장치가 복구되지 않아서 힙 압축이 실행될 때까지 메모리 단편화를 가져옵니다.
3. 힙 단편화는 압축을 강제 실행하여 줄일 수 있지만 이러한 경우 성능이 저하됩니다. 메모리 옵션 목록을 보려면 Java -X 명령을 사용하십시오.
4. 이후 가볍거나 거의 유휴 상태의 워크로드 중에 복구되는 것처럼 보이지만 심한 워크로드 중에(Application Server가 일관적으로 거의 100%의 CPU를 사용하는 경우) 가능한 누수를 나타내는 힙 이용은 힙 단편화의 표시입니다. 힙 단편화는 JVM이 가비지 콜렉션 주기 동안 메모리 할당 요청을 충족시키기 위해 충분한 오브젝트를 사용 가능하게 만들 수 있지만 JVM이 힙의 작은 사용 가능 메모리 영역들을 더 큰 연속 공간으로 압축할 시간이 없는 경우 발생할 수 있습니다.
5. 최상의 결과를 얻기 위해서는 1000, 2000 및 4000 페이지 요청과 같이 지속 기간을 늘려 실험을 반복해야 합니다. 사용되는 메모리의 Tivoli Performance Viewer 그래프에는 톱니 모양이 있어야 합니다. 그래프에서의 각 낙하는 가비지 콜렉션에 해당됩니다. 다음 중 하나가 발생하면 메모리 누출이 있습니다.
  - 각 가비지 콜렉션 바로 다음에 사용되는 메모리 양이 현저하게 증가합니다. 톱니 모양의 패턴이 더 계단 같이 보입니다.
  - 톱니 모양 패턴의 형태가 불규칙합니다.

가비지 콜렉션 조정Java 가비지 콜렉션을 조사하면 응용프로그램의 메모리 이용 방식에 대한 통찰을 얻을 수 있습니다. 가비지 콜렉션은 Java의 장점입니다. Java 응용프로그램은 응용프로그램 작성자로부터 메모리 관리 부담을 덜어서 가비지 콜렉션을 제공하지 않는 언어로 작성된 응용프로그램보다 더 강력해진 경향이 있습니다. 이 견고성은 응용프로그램이 오브젝트를 남용하지 않는 한 적용됩니다. 가비지 콜렉션은 보통 적절하게 기능하는 응용프로그램의 총 실행 시간의 5% – 20%를 사용합니다. 관리하지 않을 경우, 가비지 콜렉션은 응용프로그램의 가장 큰 병목 현상 중 하나입니다.사용자는 고정된 워크로드 실행 중에 가비지 콜렉션을 모니터링하여 응용프로그램이 오브젝트를 과도하게 활용 중인지를 알아볼 수 있습니다. 가비지 콜렉션은 메모리 누출이 있는지 확인할 수도 있습니다.JVM 설정을 사용하여 가비지 콜렉션의 유형과 동작을 구성할 수 있습니다. JVM이 연속되는 공간의 부족 때문에 현재 힙에서 오브젝트를 할당할 수 없는 경우 더 이상 사용되지 않는 Java 오브젝트에서 메모리를 재생하기 위해 가비지 콜렉터가 호출됩니다. 각 JVM 벤더는 고유한 가비지 콜렉터 정책 및 조정 매개변수를 제공합니다.관리 콘솔에서 자세한 가비지 콜렉션 설정을 사용하여 가비지 콜렉션 모니터링을 사용 가능으로 설정할 수 있습니다. 이 설정의 출력에는 클래스 가비지 콜렉션 통계가 포함됩니다. 생성된 보고서 형식이 서로 다른 JVM 또는 릴리스 레벨 사이에서 표준화되지 않습니다.JVM 가비지 콜렉션 설정을 조정하려면 다음을 수행하십시오.

관리 콘솔에서, 서버 > Application Servers > server를 클릭하십시오.
서버 인프라 아래에서, Java 및 프로세스 관리 > 프로세스 정의 > JVM(Java Virtual Machine)을 클릭하십시오.
일반 JVM 인수 필드에 변경하려는 –X 옵션을 입력하십시오.
확인을 클릭하십시오.
마스터 구성에 변경사항을 저장하십시오.
Application Server를 중지했다가 다시 시작하십시오.

다른 JVM 가비지 콜렉터의

–X

옵션에 대한 자세한 정보는 다음을 참조하십시오.

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

IBM Java 가비지 콜렉터에 대한 전체 안내서는 IBM Developer Kit and Runtime Environment, Java2 Technology Edition, Version 5.0 Diagnostics Guide에 제공됩니다. 이 문서는developerWorks 웹 사이트에서 구할 수 있습니다.Java -X 옵션을 사용하여 메모리 옵션의 목록을 보십시오.

728x90

-Xgcpolicy
Java 5.0에서부터, IBM 가상 시스템은 가비지 콜렉션에 대한 네 가지 정책을 제공합니다. 각 정책은 고유한 이점을 제공합니다.
- optthruput는 기본값으로서 처리량은 높지만 더 긴 가비지 콜렉션 일시정지 시간을 제공합니다. 가비지 콜렉션 중에 압축이 필요할 때 모든 응용프로그램 스레드가 표시, 청소 및 압축을 위해 중지됩니다. optthruput가 대부분의 응용프로그램에 충분합니다.
- optavgpause는 응용프로그램 실행과 동시에 가비지 콜렉션의 표시 및 청소 단계를 수행하여 가비지 콜렉션 일시정지 시간을 줄입니다. 이 동시 실행은 전체 처리량에 작은 성능 영향을 유발합니다.
- gencon은 IBM Java 5.0에서 새로운 정책으로서 IBM 가상 시스템에 대한 세대별 가비지 콜렉터입니다. 세대별 설계는 가비지 콜렉션 일시정지 시간의 축소와 함께 높은 처리량을 달성하려고 합니다. 이 목표를 달성하기 위해 힙이 새 세그먼트와 오래된 세그먼트로 분할됩니다. 오래 활동한 오브젝트는 오래된 공간으로 승격되는 반면 활동기간이 짧은 오브젝트는 새 공간으로 빨리 가비지 콜렉트됩니다. gencon 정책은 많은 응용프로그램에 대해 상당한 이점을 제공하지만 모든 응용프로그램에 적합하지는 않으며 일반적으로 조정하기가 더 어렵습니다.
- subpool은 일반적으로 9개 이상의 프로세서를 사용하는 멀티프로세서 시스템에서 성능을 증가시킬 수 있습니다. 이 정책은 IBM pSeries 및 zSeries 프로세서에서만 사용 가능합니다. subpool 정책은 힙이 오브젝트 할당을 위한 향상된 확장성을 제공하는 서브풀로 나뉘어지는 것을 제외하면 optthruput 정책과 비슷합니다.
기본값: optthruput

권장: optthruput

사용법: Xgcpolicy:optthruput은 가비지 콜렉션을 optthruput로 설정합니다.

gcpolicy를
optthruput
으로 설정하면 동시 표시가 사용되지 않습니다. 일시정지 시간 문제점이 있을 수 있음을 표시하는 오류가 있는 응용프로그램 응답 시간을 경험하지 않는 한
optthruput
정책을 사용할 때 최상의 처리량 결과를 얻을 것입니다.
gcpolicy를
optavgpause
로 설정하면 기본값을 갖는 동시 표시가 사용 가능합니다. 이 설정은 일반 가비지 콜렉션에 의해 유발되는 오류가 있는 응용프로그램 응답 시간을 완화시킵니다. 그러나 이 옵션은 전체 처리량을 줄일 수 있습니다.

-Xnoclassgc기본적으로 JVM은 클래스의 활동하는 인스턴스가 없을 때 메모리에서 해당 클래스를 로드 해제합니다. 그러므로, 클래스 로드 해제는 성능을 저하시킬 수 있습니다.-Xnoclassgc 인수를 사용하여 클래스 가비지 콜렉션을 사용 불가능하게 하므로 응용프로그램이 클래스를 훨씬 더 쉽게 다시 사용할 수 있습니다. 클래스 가비지 콜렉션을 끄면 동일한 클래스를 여러 번 로드 및 로드 해제하는 오버헤드를 제거합니다.

문제점 방지: 이 인수는 응용프로그램이 클래스를 동적으로 작성하거나 리플렉션을 사용하는 경우 주의해서 사용해야 합니다. 왜냐하면 이 유형의 응용프로그램에 대해 이 옵션을 사용하면 기본 메모리가 고갈되거나, JVM이 메모리 부족 예외를 전달할 수 있습니다. 이 옵션이 사용될 때 응용프로그램을 다시 전개해야 하는 경우 이전 버전 응용프로그램의 클래스와 정적 데이터를 지우도록 Application Server를 항상 재시작해야 합니다.

기본값:	클래스 가비지 콜렉션이 사용 가능합니다.
권장:	ADisable 클래스 가비지 콜렉션.
사용법:	Xnoclassgc는 클래스 가비지 콜렉션을 사용 불가능하게 합니다.

Sun JVM 가비지 콜렉터.

Solaris 플랫폼에서 Application Server는 Java용 IBM 가상 시스템이 아니라 Java HotSpot VM에서 실행합니다. 성능 최적화 기능을 이용하기 위해서는 Sun JVM과 함께 올바른 조정 매개변수를 사용하는 것이 중요합니다.

Java HotSpot VM은 최적 성능을 달성하기 위해 세대별 가비지 콜렉션에 의존합니다. 다음 명령행 매개변수가 가비지 콜렉션 조정에 유용합니다.

-XX:SurvivorRatioJava 힙은 예전에 생성된(old) 즉, 오브젝트용 섹션과 최근에 생성된(young) 오브젝트용 섹션으로 나뉘어집니다. 최근에 생선된(young) 오브젝트용 섹션은 다시 eden이라고 부르는 새 오브젝트가 할당되는 섹션과, 여전히 사용 중인 새 오브젝트가 이전 오브젝트로 승격되기 전에 처음 몇 번의 가비지 콜렉션에서 살아남는 섹션(감독자 공간으로 부름)으로 나뉘어집니다. 감독자 비율은 힙의 최근에 생선된(young) 오브젝트 섹션에서 감독자 공간에 대한 eden의 비율입니다. 이 설정을 늘리면 높은 오브젝트 작성 및 낮은 오브젝트 보존을 갖는 응용프로그램에 대해 JVM을 최적화합니다. WebSphere Application Server가 다른 Application Server보다 더 많은 중간 및 오래 활동하는 오브젝트를 생성하기 때문에, 이 설정은 기본값보다 낮아야 합니다.

기본값: 32

권장: 16

사용법: -XX:SurvivorRatio=16
-XX:PermSize영구 생성을 위해 예약되는 힙의 섹션은 JVM에 대한 모든 반사 데이터를 보유합니다. 이 크기는 많은 클래스를 동적으로 로드하고 로드 해제하는 응용프로그램의 성능을 최적화하기 위해 늘려야 합니다. 이 설정을 값 128MB로 설정하면 힙의 이 파트를 증가시키는 오버헤드를 제거합니다.

권장: 128m

사용법: XX:PermSize=128m은 perm 크기를 128MB로 설정합니다.
-Xmn이 설정은 젋음 세대가 힙에서 소비하도록 허용되는 공간을 제어합니다. 이 매개변수를 적절하게 조정하면 가비지 콜렉션의 오버헤드를 줄여서 서버 응답 시간 및 처리량을 개선할 수 있습니다. 이 옵션에 대한 기본 설정은 일반적으로 너무 낮아서 사소한 가비지 콜렉션의 수를 높게 만듭니다. 이 설정을 너무 높게 설정하면 JVM이 주요(또는 전체) 가비지 콜렉션만 수행하게 만들 수 있습니다. 이들은 대개 수 초가 걸리며 서버의 전체 성능에 극히 불리합니다. 이 상황을 피하기 위해 이 설정을 전체 힙 크기의 절반 이하로 유지해야 합니다.

기본값: 2228224 바이트

권장: 대략 총 힙 크기의 1/4

사용법: -Xmn256m은 크기를 256MB로 설정합니다.

-Xnoclassgc기본적으로 JVM은 클래스의 활동하는 인스턴스가 없을 때 메모리에서 해당 클래스를 로드 해제하지만, 이는 성능을 저하시킬 수 있습니다. 클래스 가비지 콜렉션을 끄면 동일한 클래스를 여러 번 로드 및 로드 해제하는 오버헤드를 제거합니다.클래스가 더 이상 필요없는 경우 클래스가 힙에서 차지하는 공간은 일반적으로 새 오브젝트의 작성을 위해 사용됩니다. 그러나 클래스의 새 인스턴스를 작성하여 요청을 처리하는 응용프로그램이 있고 해당 응용프로그램에 대한 요청이 임의 시간에 오는 경우, 이전 요청자가 완료될 때 다음 요청이 나타날 때만 클래스를 다시 인스턴스화하기 위해 정상 클래스 가비지 콜렉션이 클래스가 차지했던 힙 공간을 사용 가능하게 해서 이 클래스를 지우는 것이 가능합니다. 이 상황에서는 이 옵션을 사용하여 클래스의 가비지 콜렉션을 사용 안할 수 있습니다.

기본값:	클래스 가비지 콜렉션이 사용 가능합니다.
권장:	클래스 가비지 콜렉션이 사용 불가능합니다.
사용법:	Xnoclassgc는 클래스 가비지 콜렉션을 사용 불가능하게 합니다.

Java HotSpot 가상 시스템 조정에 대한 추가 정보는 Performance Documentation for the Java HotSpot VM을 참조하십시오.

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

Java용 HP 가상 시스템은 최적 성능을 달성하기 위해 세대별 가비지 콜렉션에 의존합니다. 다음 명령행 매개변수가 가비지 콜렉션 조정에 유용합니다.

-XX:+AggressiveHeap이 설정을 사용하면 JVM이 Java 힙을 공격적으로 자동 조정할 수 있습니다. JVM으로 여러 인스턴스를 전달하는 경우 힙 크기 설정과 같은 다른 인수를 대체할 수 있는 이 인수를 먼저 지정해야 합니다. 공격적인 조정 알고리즘은 -XX:+AggressiveHeap 인수 다음에 JVM으로 전달되는 인수의 제한조건을 유지합니다.

기본값: off

권장: on

사용법: -XX:+AggressiveHeap은 Java 힙을 자동 조정합니다.
-Xoptgc이 설정은 수명이 짧은 많은 오브젝트를 갖는 응용프로그램에 대해 JVM을 최적화합니다. 이 매개변수가 지정되지 않으면 JVM은 대개 주요(전체) 가비지 콜렉션을 수행합니다. 전체 가비지 콜렉션은 수 초가 걸릴 수 있으며 서버 성능을 크게 저하시킬 수 있습니다.

기본값: off

권장: on

사용법: -Xoptgc는 최적화된 가비지 콜렉션을 사용 가능하게 합니다.
-XX:SurvivorRatioJava 힙은 예전에 생성된(old) 즉, 오브젝트용 섹션과 최근에 생성된(young) 오브젝트용 섹션으로 나뉘어집니다. 최근에 생성된(young) 오브젝트용 섹션은 다시 eden이라고 부르는 새 오브젝트가 할당되는 섹션과, 여전히 사용 중인 새 오브젝트가 이전 오브젝트로 승격되기 전에 처음 몇 번의 가비지 콜렉션에서 살아남는 섹션(감독자 공간으로 부름)으로 나뉘어집니다. 감독자 비율은 힙의 최근에 생선된(young) 오브젝트 섹션에서 감독자 공간에 대한 eden의 비율입니다. 이 설정을 늘리면 높은 오브젝트 작성 및 낮은 오브젝트 보존을 갖는 응용프로그램에 대해 JVM을 최적화합니다. WebSphere Application Server가 다른 Application Server보다 더 많은 중간 및 오래 활동하는 오브젝트를 생성하기 때문에, 이 설정은 기본값보다 낮아야 합니다.

기본값: 32

권장: 16

사용법: -XX:SurvivorRatio=16
-XX:MaxTenuring 임계값이 설정은 이전 세대에 오브젝트가 프롬프트되기 전에 새 세대에 남길 수 있는 콜렉션의 수를 지정합니다. 이 설정에 지정된 값을 늘리면 오브젝트가 새 세대에 더 오래 머무릅니다. 이 설정에 지정된 값을 줄이면 이전 세대에 오브젝트가 더 빨리 프롬프트됩니다.

기본값: 31

권장: 32

사용법: -XX:MaxTenuringThreshold=32
-XX:+ForceMmapReserved이 명령은 지연 스왑을 사용 불가능하게 하고 운영 체제가 더 큰 메모리 페이지를 사용할 수 있게 하여 Java 힙을 구성하는 메모리에 대한 액세스를 최적화합니다. 기본적으로 Java 힙은 지연 스왑 공간 할당됩니다. 지연 스왑 기능은 메모리 페이지가 필요할 때 할당되기 때문에 스왑 공간을 절약합니다. 그러나 지연 스왑 기능은 4KB 페이지의 사용을 강제합니다. 대형 힙 시스템에서 이 메모리 할당은 힙을 수십만개의 페이지에 분산시킬 수 있습니다.

기본값: off

권장: on

사용법: -XX:+ForceMmapReserved는 지연 스왑 기능을 사용 안합니다.
-XX:+UseParallelGC이 명령은 새 세대의 가비지 콜렉션을 사용 가능하게 합니다. 멀티프로세서 시스템에 이 명령을 발행하면 JVM이 부분 가비지 콜렉션 주기를 완료하기 위해 필요한 시간을 줄일 수 있습니다.

기본값: off

권장: on

사용법: -XX:+UseParallelGC는 새 세대에 대한 병렬 가비지 콜렉션을 사용 가능하게 합니다.
-XX:+UseParallelOldGC이 명령은 이전 세대의 가비지 콜렉션을 사용 가능하게 합니다. 멀티프로세서 시스템에 이 명령을 발행하면 JVM이 전체 가비지 콜렉션 주기를 완료하기 위해 필요한 시간을 줄일 수 있습니다.

기본값: off

권장: on

사용법: -XX:+UseParallelOldGC는 이전 세대에 대한 병렬 가비지 콜렉션을 사용 가능하게 합니다.
-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는 클래스 가비지 콜렉션을 사용 불가능하게 합니다.

HP 가상 시스템 조정에 대한 추가 정보는 Java technology software HP-UX 11i를 확인하십시오.

가비지 콜렉션 모니터링에 대한 자세한 정보는 다음 문서를 참조하십시오.
- 성능: 학습 자원 for a description of the IBM verbose:gc output
HP-UX의 Java용 HP 가상 시스템을 조정하십시오. 다음 옵션을 설정하여 응용프로그램 성능을 개선하십시오.
```
-XX:SchedulerPriorityRange=SCHED_NOAGE  -XX:-ExtraPollBeforeRead -XX:+UseSpinning -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.DevPollSelectorProvider  
```
HP 가상 시스템 조정에 대한 추가 정보는 Java technology software HP-UX 11i를 확인하십시오.
Solaris의 Java HotSpot VM에 대해 클라이언트 또는 서버 모드를 선택하십시오.WebSphere Application Server가 Solaris 플랫폼에서 사용하는 JVM(Java Virtual Machine)은 클라이언트 또는 서버의 두 가지 모드에서 실행됩니다. 각 모드는 고유한 장점을 갖습니다.
클라이언트 모드는 사용자 환경이 다음과 같을 때 선택하기에 좋은 모드입니다.
- 서버 재부팅 또는 작동 중단 후에 빠른 복구가 필요합니다. 클라이언트 모드는 가상 시스템이 더 빨리 준비될 수 있게 하므로 Application Server가 시작 후에 많은 수의 요청을 매우 빠르게 서비스하게 합니다.
- 물리적 RAM 제한을 갖습니다. 클라이언트 모드는 서버 모드보다 적은 메모리를 사용합니다. 이 메모리 절약은 하드웨어 제한 때문에 전체 JVM 크기가 작을 때 매우 중요합니다. 예를 들어 하드웨어의 단일 부분에서 여러 JVM을 실행 중이기 때문에 전체 JVM 크기는 작을 수 있습니다.
거의 다시 시작되지 않는 Application Server에서 성능을 극대화하려는 경우 서버 모드에서 HotSpot JVM을 실행해야 합니다. JVM이 서버 모드에 있을 때 Application Server가 많은 수의 요청을 서비스할 수 있는 상태가 되기 위해 여러 배 더 오래 걸립니다. 그러나 해당 상태가 된 후에는 서버 모드가 클라이언트 모드에서 실행 중인 비교 가능한 JVM보다 상당히 잘 수행할 수 있습니다.Java 5.0의 Solaris 구현은 사용자 하드웨어를 조사하고 사용자 환경에 맞는 JVM 모드를 선택하려고 합니다. JVM이 서버 레벨 시스템에서 실행 중임을 판별하는 경우 JVM은 자동으로 서버 모드를 사용합니다. Java 1.4.2 이하에서 기본 모드는 클라이언트 모드이며 서버 모드를 사용하려면 JVM 명령행에서
-server
플래그를 사용해야 합니다.
사용자 시스템이 최소한 2개의 CPU와 2GB의 메모리를 갖는 경우 JVM이 자동으로 서버 모드를 사용하기 때문에 JVM은 서버 모드로 기본 설정됩니다. 그러나 일반 JVM 인수에서
-client
및
-server
플래그를 사용하여 JVM이 사용자를 위해 선택하는 모드가 사용자 환경에 맞지 않는 경우 어느 하나의 모드로 가상 시스템을 강제 실행할 수 있습니다.
서버 모드에서 실행 중인 HotSpot JVM은 초기 준비 단계 동안 Java 코드를 최적화하고 다시 최적화하는 높은 최적화 컴파일러를 사용합니다. 이 모든 최적화 작업은 잠시 시간이 걸리지만, JVM이 준비된 후에는 Application Server가 동일한 하드웨어에서 클라이언트 모드의 경우보다 훨씬 더 빨리 실행됩니다.

캐시에서 클래스 공유를 사용 가능하게 하십시오.IBM J2RE(Java 2 Runtime Environment) 버전 1.5.0의 공유 클래스 옵션은 캐시에서 클래스를 공유할 수 있게 합니다. 캐시에서 클래스를 공유하면 시작 시간이 개선되고 메모리 풋프린트가 감소합니다. Application Server, Node Agent 및 Deployment Manager와 같은 프로세스는 공유 클래스 옵션을 사용할 수 있습니다.

중요사항: IBM J2RE 1.5.0은 현재 다음에서 사용되지 않습니다.

Solaris
HP-UX

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

관리 콘솔에서, 서버 > Application Servers > server를 클릭하십시오.
서버 인프라 아래에서, Java 및 프로세스 관리 > 프로세스 정의 > JVM(Java Virtual Machine)을 클릭하십시오.
일반 JVM 인수 필드에서 -Xshareclasses:none를 입력하십시오.
확인을 클릭하십시오.
마스터 구성에 변경사항을 저장하십시오.
Application Server를 중지했다가 다시 시작하십시오.

기본값:	캐시 옵션의 공유 클래스가 사용 가능합니다.
권장:	캐시에서 클래스 공유 옵션을 사용 가능으로 두십시오.
사용법:	-Xshareclasses:none은 캐시에서 클래스 공유 옵션을 사용 불가능하게 합니다.

프로세스에 대한 공유 클래스 옵션을 사용 안해야 하는 경우 해당 프로세스에 대해 일반 JVM 인수 -Xshareclasses:none을 지정하십시오.
메모리 이용을 최소화하십시오.
Sun Java 5.0 JVM의 기본 조정 환경 설정은 이전 JVM 버전보다 많은 메모리를 사용합니다. 이 추가 메모리는 처리량을 최대화하는 데 도움이 됩니다. 그러나 실제 메모리가 대체로 정량 이상인 환경(예: JVM hoteling)을 실행할 경우에는 문제를 일으킬 수 있습니다. 최소 메모리 이용을 위해 Sun Java 5.0 JVM을 조정해야 할 경우, 일반 JVM 인수에 다음 조정 매개변수를 추가할 수 있습니다.
```
-client -XX:MaxPermSize=256m -XX:-UseLargePages -XX:+UseSerialGC
```
이러한 매개변수의 설정은 특정 처리량에 영향을 줄 수 있으며 서버 시작 시간이 조금 느려질 수 있습니다. 매우 큰 응용프로그램을 실행할 경우에는 MaxPermSize 설정에 보다 높은 값을 지정할 수 있습니다.
HP Java 5 JVM의 기본 조정 환경 설정은 이전 JVM 버전보다 많은 메모리를 사용합니다. 이 추가 메모리는 처리량을 최대화하는 데 도움이 됩니다. 그러나 실제 메모리가 대체로 정량 이상인 환경(예: JVM hoteling)을 실행할 경우에는 문제를 일으킬 수 있습니다. 최소 메모리 이용을 위해 Sun Java 5.0 JVM을 조정해야 할 경우, 일반 JVM 인수에 다음 조정 매개변수를 추가할 수 있습니다.이러한 매개변수를 설정하면 서버 시작 시간이 조금 느려질 수 있습니다.
-XX:-UseParallelGC –XX:-UseAdaptiveSizePolicy
큰 셀 구성의 구성 갱신 프로세스를 조정하십시오.
큰 셀 구성에서는 구성 갱신 성능이 보다 중요한지 또는 일관성 점검이 보다 중요한지 여부를 결정해야 할 수 있습니다. 구성 일관성 점검이 켜져 있는 경우 구성 변경을 저장하거나 많은 응용프로그램을 전개하기 위해서는 많은 시간이 필요할 수 있습니다. 다음 요소는 필요한 시간량에 영향을 미칩니다.
- 셀에 정의된 Application Server 또는 클러스터가 많을수록 구성 변경을 저장하는 데 많은 시간이 소요됩니다.
- 셀에 전개된 응용프로그램이 많을수록 구성 변경을 저장하는 데 많은 시간이 소요됩니다.
구성 변경을 변경하는 데 필요한 시간이 불충분한 경우 JVM 설정에 config_consistency_check 사용자 정의 특성을 추가하고 이 특성 값을 false로 설정할 수 있습니다.
1. 관리 콘솔에서 시스템 관리 > Deployment Manager를 클릭하십시오.
2. 서버 인프라 아래에서 Java 및 프로세스 관리를 선택한 다음 프로세스 정의를 클릭하십시오.
3. 추가 특성 아래에서 JVM(Java Virtual Machine) > 사용자 정의 특성 > 새로 작성을 클릭하십시오.
4. 이름 필드에 config_consistency_check를 입력하고 값 필드에 false를 입력하십시오.
5. 확인을 클릭한 후 저장을 클릭하여 마스터 구성에 이러한 변경사항을 적용하십시오.
6. 서버를 다시 시작하십시오.

다음에 수행할 내용

각 Java 벤더는 성능 및 해당 JVM의 조정에 대한 자세한 정보를 제공합니다. 특정 Java 런타임 환경에 대한 추가 조정 정보를 얻으려면 다음 웹 사이트를 사용하십시오.

Java용 IBM 개발자 킷의 경우 다음을 확인하십시오.
- http://www.ibm.com/developerworks/java/
- http://www.ibm.com/developerworks/java/jdk/diagnosis/
Sun Java JDK의 경우, http://java.sun.com/docs/performance/의 내용을 참조하십시오.
HP-UX Java의 경우, http://www.hp.com/products1/unix/java/의 내용을 참조하십시오.

DB2를 사용하는 경우, HP-UX의 Java용 HP 가상 시스템에서는 SafepointPolling 기술을 사용 불가능으로 설정하는 것을 고려하십시오. Java 스레드에 대한 safepoints를 보장하기 위해 개발된 SafepointPolling 기술은 WebSphere Application Server와 DB2 데이터베이스 간의 신호를 간섭할 수 있는 신호를 생성합니다. 이러한 간섭이 발생할 때 데이터베이스 교착 상태가 종종 발생합니다. 런타임 동안 SafepointPolling을 사용 불가능하게 하는 -XX:-SafepointPolling 옵션으로 JVM을 시작하여 이러한 방해가 발생하지 않도록 하십시오.

=================================

저작자표시

'프로그래밍 관련 > 언어들의 코딩들 C++ JAVA C# 등..' 카테고리의 다른 글

프로그래밍 java MD5 변환 (0)	2016.08.09
[Java] 자바 열거형 Enum 예제 관련 ~! (0)	2016.06.22
[Delphi] 델파이 자료형 Data Type 관련 (0)	2016.05.17
자바 단위테스트 JUnit 이걸로 테스트 관련 (0)	2016.05.16
자바 GUI 툴 google 에서 만든 자바 gui 툴 WindowBuilder 관련 (0)	2016.05.06

현재글JAVA 실행 시 Heap 설정 메모리 설정 관련

알레폰드의 테크 이모저모

JAVA 실행 시 Heap 설정 메모리 설정 관련

덧글