승하연서빠의 작업 메모

1. 먼저 /etc/inetd.conf 파일에서 FTP부분을 수정한다.

출처: http://egloos.zum.com/donquite/v/8860506

JVM 구조

IBM JVM를 구성하는, 각각의 Component structure는 아래와 같이 나뉜다.

각 영역의 주요 기능은 아래와 같이 요약된다.

[표 1] IBM JVM 구성 요소 설명

여기서 우리는 ‘Memory management’ 를 중점적으로 다뤄본다.

JIT 컴파일러

흔히, IBM JVM을 JIT계열의 JVM이라고 표현한다.

JIT는 흔히 Just-In-Time의 약자로 알려져 있으며, 이는 JVM의 한 part라기 보다는, SDK의 기본 구성요소로 생각하는 것이 맞다.

Java가 Interpreter 언어이고, 이는 소스가 bytecode로 컴파일 되고, 실행되기 위해서는 다시금 system code로 해석되어 수행되어야 하는, performance적인 저하요소를 극복하기 위해 자주 수행되는 Java method를 대상으로 미리 system code로해석해서, Method가 call되면 컴파일 과정 없이 바로 서비스를 하는 방식으로 작동한다.

 이런 JIT 컴파일러가 때때로 Runtime시 문제점이 발생하는 경우는, 아래의 방법으로 JIT 옵션을 꺼둘 수도 있다.

[표 2] JIT 컴파일러 비활성화

또, 아래와 같이 JIT 옵션을 켤 수도 있다.

[표 3] JIT 컴파일러 활성화

Garbage Collector

Sun의 HotSpot 계열의 JVM은 ‘New/Old/Permanent’등의 ‘세대(Generation)’로 불리는 영역으로 분리된 Heap구조를 가진다.

이에 반해, IBM JVM은 영역이 따로 분리되지 않은 하나의 ‘Single Space’로 Heap이 구성되어 있다.

참고로, IBM JDK 1.5부터는 아래와 같이 ‘세대(Generation)’기반의 Heap 구조를 지원한다.

(GC 알고리즘이 Concurrent Generational Collector 인 경우의 Heap 구조임)

각 영역이 어떤 식으로 Garbage Collector에 의해 사용되는지 설명하기 위해서,

‘Generational Concurrent Garbage Collection’의 알고리즘에 대해 잠깐 언급하도록 한다.

JVM이 Logic을 처리하는 동안, 새로운 Object들은 당연히 ‘Nursery’영역에 생기게 된다. 만일, 새로운 Object가 할당되는데 필요한 ‘연속된 메모리 영역’이 부족하게 되면, 객체는 ‘Tenured’영역으로 옮겨지게 된다. 또한, Garbage collection 발생시 옮겨지기도 한다.

Nursery 영역은 ‘Allocate Space’와 ‘Survivor Space’로 나뉘게 된다.

Object는 최초 Allocate Space에 생기게 된다. 만일, Space가 부족하게 되는 경우,

Allocation Failure가 발생되면 Garbage Collector가 작동되고, Scavenge가 시작된다.

Scavenge가 진행되는 동안, reference가 살아있는 Object들은 ‘Survivor Space’로 이동되고, 이때 reference가 없는Object들은 건들지 않는다.

Reference가 살아있는 Object들의 이동작업이 다 끝나게 되면, ‘Allocate Space’와 ‘Survivor Space’는 그 역할을 순간적을 바꾸게 된다.

이때, 기존의 reference가 없는 Object들은 순간적으로 비워지게 된다. 그리고, 다음 Scavenge가 발생할 때 까지는‘Survivor Space’가 Object를 위한 Allocate 공간 업무를 수행하게 된다.

GC command-line options

-verbose:gc

garbage collection 의 정보를 standard out 으로 출력한다.

-Xverbosegclog:<file, X, Y>

garbage collection 의 정보를 파일로 출력한다. 만약 integer X와 Y의 값을 명시하면 output이 Y GC Cycle의 output을 포함하는 X 파일로 재지정된다.

-Xgcpolicy: <optthruput | optavgpause | gencon | subpool>

이 option은 garbage collector 행동을 제어한다.

-. optthruput

concurrent mark를 비활성화 한다. 만약 application response time에 문제가 없다면 이 option을 사용하여 최적의throughput을 낼 수 있다. Optthruput은 default 값이다.

-. optavgpause

concurrent mark를 활성화 한다. 만약 일반적인 garbage collections 에 의해 application response time에 문제가 있다면이 option을 사용함으로 문제를 줄일 수 있다.

-. gencon

Concurrent와 generational GC를 겸용하여 사용함으로 garbage collection 지체 시간을 최소화 할 수 있다.

-. subpool

concurrent mark를 비활성화 한다. 이것은 heap에 객체들을 배치할 때 더 나은 성능을 내기 위해 향상된 object allocation알고리즘을 사용한다. 이 option은 16 이상의 processor의 SMP system에서 실행되며, subpool option은 AIX, Linux PPC 와 zSeries, z/OS, i5/OS 에서 가능하다.

-Xmx<value>

최대 heap size를 지정한다. (Xmx >= Xms)

-Xms<value>

최소 heap size를 지정한다.  Xmo 또한 사용할 수 있다. 최소 size는 8KB이다.

scavenger 가 활성화 되어 있을 경우, -Xms >= -Xmn + -Xmo

scavenger 가 비활성화 되어 있을 경우, -Xms >= -Xmo

-Xcompactgc

모든 garbage collections(system 또는 global) 에 대하여 압축을 가능하게 한다.

-Xnocompactexplicitgc

System.gc() 호출에 의한 압축을 불가능하게 한다. 압축은 만약 –Xcompactgc 명시하거나 또는 compaction triggers를 만나면 global garbage collections 에서 발생한다.

-Xcompactexplicitgc          

System.gc()가 호출 될 때마다 모든 GC 시스템에서 압축을 사용 가능하게 한다.

-Xnocompactgc

모든 garbage collections(system 또는 global) 에 대하여 압축을 사용 불가능하게 한다.

-Xnoclassgc

Class garbage collection 을 비활성화 한다. JVM에 의해서 더 이상 사용되지 않는 Java class 들과 연관된 storage의garbage collection을 끈다. 즉 dynamic 클래스 로드 해제를 사용 불가능하게 한다.

-Xclassgc

dynamic 클래스 로드 해제를 사용 가능하게 한다.

-Xalwaysclassgc

global collection 동안 항상 dynamic class load 해제를 수행한다. Default 는 -Xclassgc 에 의해 정의된다.

-Xmaxf<percentage>

garbage collection 후 free 되어야 하는 heap의 최대 percentage를 지정한다. 만약 free 영역이 이 값을 초과하면 JVM은heap을 줄이기 위해 시도한다. Default는 0.6(60%) 이다.

-Xminf<percentage>

garbage collection이후 free되어야 하는 heap의 최소 percentage를 지정한다. 만약 free영역 이 값에 못 미치는 경우 JVM은 heap을 확장하기 위해 시도한다. Default는 30%이다.

-Xgcthreads<number>

Garbage Collector 의 thread 수를 지정한다. Default는 물리적인 CPU의 수로 지정된다. 다른 수로 지정하기 위해 (예를 들어 4)  -Xgcthreads4 로 표기한다.

Nonstandard command-line options

-Xss<size>

모든 Java thread의 최대 stack size를 지정한다. Default는 32bit JVM에서 256KB, 64bit JVM에서 512KB 이다.

-Xmso<size>

OS thread의 stack size를 지정한다.  

JIT command-line options

-Xint

JVM을 JIT로 사용불가하고, Interpreter 로만 사용한다.

-Xquickstart

최적화를 지연하여 시작 시간을 향상시킨다. 

GC 알고리즘의 이해

IBM JDK에서는 아래와 같이 주요 4가지 Garbage Collection 옵션을 제공한다.

이들은 아래와 같은 방법으로 설정이 가능하다.

여기에 설정할 수 있는 옵션은 다음과 같다.

optthruput GC 알고리즘 설명

optavgpause GC 알고리즘 설명

gencon GC 알고리즘 설명

subpool GC 알고리즘 설명

GC Dump의 이해

앞에서, GC 알고리즘에 대해 개략적으로 살펴보았다.

여기서는, 로그가 실제 어떤 식으로 생성되는지 간략한 예를 살펴보도록 한다.

아래는, 실제로 JEUS에 각각의 GC 알고리즘을 적용시켜 생성한 Dump이다.

–Xgcpolicy:optthruput GC dump

로그 패턴을 보면, Allocation Failure가 발생하였고, GC를 거쳐 Tenured영역의 Free Space가 57%로 증가했음을 알 수있다. 

–Xgcpolicy:optavgpause GC dump

 
–Xgcpolicy:gencon GC dump

–Xgcpolicy:subpool GC dump

Subpool은 CPU가 16장 이상인 환경에서 최적화 되어있다고 앞서 말했다.

종종 System Capacity가 부족한 환경에서는 아래와 같은 로그가 목격되기도 한다.

위의 로그와 비슷하게, System.gc()가 명시적으로 호출된 경우는 아래와 같은 GC Dump가 발생한다.

Java Thread Dump 분석

Java Thread Dump란, 특정 Java Process에 대한 청사진이라 해석될 수 있다.

IBM 플랫폼에서 Java Thread Dump는 text형태로 생성된다.

이를, 직접 열어서 내용을 Trace하는 것도 가능하지만, 여기서는 Visual Tool을 이용한 분석법을 소개한다.

JCA를 이용한 Java Thread Dump 분석

1. 다운로드 : http://www.alphaworks.ibm.com/tech/jca (파일명:jca*.zip)

2. 실행화면

 3. 설명

실제 javacore덤프를 분석한 화면이다.

덤프 생성 당시, 가용한 메모리가 없었다는 경고와 함께, Worker Thread들 중 하나가

Running 상태였다는 정보를 쉽게 알 수 있다.

이와 같이, Worker Thread의 상태정보 및 Heap Memory Usage정보, Thread Monitor 상태정보(dead lock)등의 정보에쉽게 접근이 가능하다.

Java Heap Dump 분석

Java Heap Dump란, 특정 Java Process에 allocation 되었던 Heap Memory에 대한 청사진이라 할 수 있다.

IBM 플랫폼에서는 text형태, 혹은 phd(Portable Heap Dump)포맷으로 생성된다.

Heap Dump 분석에는 주로 아래와 같은 방법이 사용된다.

여기서는 GUI기반의 HeapAnalyzer를 소개한다.

HeapAnalyzer를 이용한 Java Heap Dump 분석

1. 실행화면 

2. 설명

실제 Heap Dump를 분석한 화면이다.

Heap Dump 생성 당시의 Memory allocation에 대한 Stack정보를 계층구조로 보여주고 있어서, Memory 누수 라던지OOM(Out Of Memory)상황이 발생하였을 경우, 그 원인파악에 매우 도움이 되는 화면을 제공한다.

(*주의: Heap Dump Size가 매우 큰 경우는, 서버의 X-Window환경에서 작업하도록 한다. 통상적인 Heap Dump 분석에는 많은 Memory가 필요하기 때문이다.)

GC Dump 분석

GC Dump 분석이란, -verbose:gc –Xverbosegelog:logname.log 의 결과로 생성된 GC log파일을 분석하는 것을 말한다.

이 역시, script를 이용하는 방법과 command-line을 이용한 명령어 사용방법 등이 있는데, 여기서는 역시 GUI 기반의 툴인‘GCCollector’를 이용하는 방법을 소개한다.

GCCollector를 이용한 GC Dump 분석

1. 다운로드: GCCollector를 실행하기 위해서는 JFreeChart 도 다운받아야 한다.           

2. GCCollector 실행파일에 오류가 발생할 경우 아래와 같이 작성한다.

javaw -Xmx300m –classpath lib/GCCollector.jar;lib/jfreechart-1.0.0-rc1.jar;lib/jcommon-1.0.0-rc1.jar it.imperato.jvmperf.GCCollector

3. 실행화면

4. 설명

실제 GC Dump를 분석한 화면이다. (-Xgcpolicy:optthruput or –Xgcpolicy:optavgpause)

GCCollector를 통해 판단할 수 있는 항목은 아래와 같다.

표준 설정 옵션

전체적인 GC Time이 너무 길고, Response Time이 너무 나오지 않습니다.

상황

GC 수행시간 그래프를 보면, 수행시간이 오래 걸리는 GC들의 peak가 자주 목격됩니다.

Response Time 역시 너무 안 나옵니다.

조치

대부분, GC에 있어서 Full heap collection 혹은 compaction에 소요되는 시간이 너무 긴 경우 발생할 수 있습니다.

이 경우, -Xgcpolicy:optavgpause 옵션을 적용하면, concurrent 하게 heap collection이 발생하게 되고, GC에 따른 pause시간이 감소하여, 전체적인 Response Time 향상을 기대할 수 있습니다.

Throughput이 너무 적게 나옵니다.

상황

CPU 및 Memory등의 capacity가 좋은 장비임에도 불구하고, WAS 서비스의 전체적인

Throughput이 너무 나오지 않습니다.

조치

이 경우, -Xgcpolicy:optthruput 옵션을 적용하면, concurrent 한 mark&sweep 작업을 막음으로써, 대부분의 Thread가Business Service를 수행하는데 사용되도록 유도하여 전체적인 Throughput을 향상시키는데 도움이 될 수 있습니다.

만일, CPU가 16장 이상인 고 사양 환경의 경우 –Xgcpolicy:subpool 옵션이 좀더 효과적인 성능을 발휘 할 수 있습니다.

Garbage Collection이 너무 자주 발생합니다.

상황

GC Interval이 매우 좁게 나타나며, GC count가 너무 높게 나옵니다.

조치

Application 특성에 비해 Heap Size가 너무 작게 설정되어 있을 수 있습니다.

또한, 이 경우 –Xgcpolicy:optthruput 옵션이 도움이 될 수 있습니다.

설정된 Heap Size와 실제 사용량의 차이가 너무 심하게 납니다.

상황

실제 WAS JVM에 할당한 Heap Size와 사용되는 Heap Size의 등락폭이 너무 심하게 자주 바뀝니다.

조치

Heap Size가 너무 크게 설정되어 있을 수 있습니다.

Heap Size를 줄이고, Generation Heap Space가 설정된 경우 ‘Nursery’영역의 Size를 좀더

할당해 주는 것도 도움이 될 수 있습니다.

CPU 16장 이상의 환경에서 WAS를 운영하는 경우, 권장 GC 정책은 무엇인가요?

상황

CPU 16장 이상의 AIX장비의 IBM JDK 1.5 이상 환경에서 WAS를 운영하고자 합니다.

권장 GC 정책은 무엇 인가요.

조치

이 경우 -Xgcpolicy:subpool 옵션을 권장합니다.

하지만 Business Application의 성격에 따라 다른 결과가 나올 수 있음으로, 다른 GC 정책과의 비교 Test가 필요합니다.

 Heap Size를 넉넉하게 설정하였음에도 불구하고, Allocation Failure가 자주 발생합니다.

상황

Heap Size를 넉넉하게 설정하였습니다. Application에서 사용하는 Object들도 매우 큰 경우는 별로 발견되지 않는데, 잦은AF(Allocation Failure)가 발생하고 있습니다.

조치

메모리 단편화(Memory Fragmentation)를 의심해 볼 수 있습니다.
WAS의 JVM에 -Dibm.dg.trc.print=st_verify 를 설정하여, kCluster/pCluster 설정이 필요합니다. 또한, -Xloratio옵션을주어 LOA 영역에 대한 사이즈 조절도 때때로 유효한 경우가 있습니다.

AIX가 인터넷이 된다면...

root로....

ftp ftp.software.ibm.com
Name> ftp
Password> 이메일
ftp> cd aix/freeSoftware/aixtoolbox/RPMS/ppc/wget
ftp> binary
ftp> get wget-1.9.1-1.aix5.1.ppc.rpm
ftp> quit
rpm -hUv wget-1.9.1-1.aix5.1.ppc.rpm


끝~

wget 사용...