GC는 힙 공간에서 참조하지 않는 객체를 수집합니다. 가장 좋은 GC는 수집에 소요되는 시간을 실행 시간의 5% 이내로 조정
JVM 힙 크기는 VM이 GC에 소비되는 빈도와 기간을 결정합니다. GC에 허용되는 비율은 애플리케이션마다 다르며 GC 수집의 실제 시간과 빈도를 분석하여 조정해야 합니다.
큰 Heap Size를 선택하면 수집 속도는 느려지지만 발생 빈도가 줄어듭니다. 메모리 요구사항에 따라 힙 크기를 설정하게 되면 GC 속도는 빠르지만 더 빈번하게 발생됩니다.
Heap Size 조정 목표는 WebLogic Server가 주어진 시간에 처리할 수 있는 클라이언트 수를 최대화하고 JVM이 GC를 수행하는데 소요되는 시간은 최소하는 것입니다.
힙 크기는 VM에서 사용할 수 있는 최대 메모리 양을 사용 가능한 물리적 RAM 보다 초과하지 않는 값으로 설정해야 합니다. 초과하면 OS가 페이징을 시작하고 성능이 크게 저하됩니다. VM은 항상 Heap Size 보다 더 많은 메모리를 사용합니다. 내부, 외부 VM 기능과 라이브러리와 영구적인 메모리 사용 공간이 필요한 메모리는 힙 크기 조정에 추가로 할당합니다.
Generation 별로 GC 방식을 사용할 때, Nursery(새로운 객체가 생성되고 일시적으로 보관되는 임시 메모리 영역)을 Java Heap Size의 절반을 초과해서는 안됩니다. 일반적으로 힙 크기의 25~40%가 적합합니다.
프로덕션 환경에서는 힙을 지속적으로 늘리고 줄이는데 사용되는 VM 리소스의 낭비를 막기 위해서 최소 힙 크기와 최대 힙 크기를 동일한 값으로 설정합니다.
오라클 JRockit 제품의 Heap Size 설정 옵션
Nursery 설정 | -Xns | GC 일시 중지 시간을 허용 가능한 정도로 낮게 유지하고 Nursey를 최대한 크게 만드는 것이 좋습니다. 특히 많은 임시 객체를 생성하는 프로그램에서 중요합니다. nursery 최대 크기는 최대 힙 크기의 95%를 초과할 수 없습니다 |
초기, 최소 힙 사이즈 설정 | -Xms | 오라클은 GC 수집을 최소화하기 위해 최소 힙크기 (-Xms), 최대 힙 크기를 동일시 할 것을 권장합니다. |
최대 힙사이즈 설정 | -Xmx | 실시간 데이터 양에 비해 최대 힙 크기를 낮게 설정하게 되면 빈번하게 GC가 발생하여 성능이 저하됩니다. |
GC 설정 | -Xgc:Parallel | |
Java 실행시 초기 최적화 설정 | -XXaggressive:memory | JRokint에게 사용가능한 메모리를 적극 사용하도록 지시합니다 |
예를 들어 WebLogic Server 인스턴스 시작시 java JRokit VM 힙 크기를 아래처럼 지정할 수 있습니다.
$ java -Xns10m -Xms512m -Xmx512m
이러한 값의 기본 크기는 바이트 단위로 측정합니다.
킬로바이트를 나타내려면 값에 문자 'k' 또는 'K'를 추가하고, 메가바이트 표기는 'm' 또는 'M', 기가 바이트는 'g' 또는 'G'를 추가합니다. 위 예에서는 WebLogic Server 인스턴스에 대한 Nursery 힙 크기에 10MB 메모리를 할당하고 최소, 최대 힙 크기에 512MB 메모리를 할당합니다.
사용하고 있는 JVM에 따라 GC 선택하여 시스템 메로리 관리를 할 수 있습니다. 일부 가비지 컬렉션은 특정 유형의 애플리케이션에 더 적합합니다. 애플리케이션의 워크로드와 JVM에서 사용하는 다양한 가비지 컬렉션 알고리즘을 이해하면 GC 구성을 최적화 할 수 있습니다.
Sun HotSpot VM에서 사용할 수 있는 가비지 수집 체계는 "Tuning Garbage Collection with the 5.0 Java Virtual Machine"을 참조하면 됩니다.
가비지 컬렉션의 상세 옵션을 사용하면 수집에 소요되는 시간과 리소스 양을 정확하게 측정할 수 있습니다. 가장 효과적인 힙 크기를 결정하려면 가비지 컬렉션을 활성하하고 진단 목적의 출력을 로그파일로 리다렉션 할 수 있습니다.
과정
1. 애플리케이션을 실행하는 동안 최대 부하에서 WebLogic Server의 성능을 모니터링 합니다.
2. -verbosegc 옵션을 사용하여 JVM에 대한 자세한 가비지 수집 출력을 하고 표준 오류와 표준 출력을 모두 로그 파일로 리다렉션 합니다. WebLogic Server 정보와 오류 메시지, 적절한 컨텍스트에 스레드 덤프 정보를 배치하고 진단 목적으로 유용한 로그를 제공합니다.
Windows, Solaris 예시
java -ms32m -mx200m -verbosege -classpath $CLASSPATH
-Dweblogic.Name=%SERVER_NAME% -Dbea.home="C:\Oracle\Middleware"
-Dweblogic.management.username=%WLS_USER%
-Dweblogic.management.password=%WLS_PW%
-Dweblogic.management.server=%ADMIN_URL%
-Dweblogic.ProductionModeEnabled=%STARTMODE%
-Djava.security.policy="%WL_HOME%\server\lib\weblogic.policy" weblogic.Server >> logfile.txt 2 >&1
여기서 logfile.txt 2>&1 명령은 표준 오류와 표준 출력을 모두 로그 파일로 리디렉션합니다.
3. 데이터 포인트를 분석합니다.
- 가비지 컬렉션이 얼마나 자주 발생하는가? weblogic.log 파일에서 가비지 수집 주변의 타임스태프를 비교합니다.
- 가비지 수집에 시간이 얼마나 소요되었는가? 전체 가비지 수집은 3~5초 이상 걸리지 않아야 합니다.
- 평균 메모리 사용량은 얼마인가? 가비지 수집이 완료될 때마다 힙은 어떻게 다시 정리되는가? 힙이 항상 85% 이상의 여유 공간으로 고정되면 힙 크기를 더 작게 설정할 수 있습니다
4. 힙 크기(Sun), Nursery(JRockit) 크기를 검토합니다.
- Jrokit : JRokit JVM 힙 크기 옵션 참고
- Sun : Java HotSpot VM 힙 크기 옵션 참고
5. 힙 크기가 시스템에서 사용 가능한 여유 RAM 보다 크지 않은지 확인
시스템이 페이지를 디스크로 교환하지 않고 가능하면 큰 힙 크기를 사용하도록 합니다. 시스템의 여유 RAM 크기는 하드웨어 구성과 컴퓨터에서 실행중인 프로세스의 메모리 요구 사항에 따라 다릅니다. 시스템의 여유 RAM 용량을 확인하려면 시스템 관리자에 문의해야 합니다.
6. 시스템이 가비지 수집에 너무 많은 시간을 소비하고 있는 경우 힙 크기를 줄여야 합니다.
일반적으로 JVM에서 사용 가능한 RAM의 80%를 사용해야 합니다.
7. 사용 가능한 여유 RAM이 많이 남는 시스템은 더 많은 WebLogic Server 인스턴스를 실행해야 합니다.
힙 크기 조정의 목표는 WebLogic Server가 특정 시간에 처리할 수 있는 클라이언트 수를 최대화하면서 JVM이 GC를 수행하는데 소요 시간을 최소화 하는 것입니다.
어노테이션 (메타데이터 리플랙션 @Retention @Target) (0) | 2024.01.09 |
---|---|
열거 타입 정리 (JAVA) (1) | 2024.01.08 |
가비지 컬렉터 (Serial GC, Parallel GC) (1) | 2024.01.06 |
JVM 힙(Heap), 가비지컬렉션(Garbage Collection) (0) | 2024.01.05 |
JVM 메소드 영역 (Constant_pool) (0) | 2024.01.04 |
댓글 영역