IBM JVM 튜닝 - 3

앞선 IBM JVM 튜닝 - 2 포스팅에서 AF를 줄이는 방안을 연구해 보자고 했다.

AF란 결국 아래의 두 논리의 경합이다.
1. heap memory상에는 움직일수 없는 객체들이 존재한다. (unmovable objects)
2. heap memory에 객체가 할당되기 위해서는 연속된 memory공간이 필요하다. (contiguous memory block)

여기서 '움직일수 없는 객체(unmovable object)'의 두가지 type에 대해 살펴보도록 하자.

pinned objects

• java heap 영역이 아닌 space로 부터 참조를 당하고 있는 객체들을 말한다.
  (여기서 java heap 영역이 아닌 space란 말은 native heap, thread stack등의 영역을 의미하는데 이는 포스팅 진행중 설명하겠다.)
• jvm 내부 스트럭처의 일부분 혹은, jni의 내부의 변수, 혹은 다른 pinned objects등에 의해 reference를 가진 객체를이 해당된다.

dosed objects

• 순간적으로 pinned objects화 된 객체등을 의미한다.
• java 코드내의 local variable, 혹은 method 간의 호출에 사용되는 parameter 객체들이 될 수있다.
• GC Thread가 돌때, 위에서 설명한 dosed object들은 active로 간주되어 GC의 대상에서 벗어나게 되고,이후 GC Thread에 의해서 reference 참조 여부가 결정된 후, 일반 객체처럼 수거된다.

아래의 그림을 보면 쉽게 이해가 갈 것이다.

이러한 unmovable objects들 중, 다행히 dosed object들은 생명이 짧다. 따라서 곧 mark-sweep될 가능성이 많다.
하지만, 문제는 pinned object들 이다. 이 녀석들은 대부분 긴 생명력을 자랑하면서, 제한된 Heap 공간에 자기 멋대로 자리를 틀어 버리기 때문이다.
필연적으로 이러한 pinned objects들이 다수 존재하게 되면, 그만큼 AF가 발생할 확률이 높다는 말이 된다.

그렇다면, 어떠한 방법이 있을까?

사례 1) Heap사용률은 높지 않지만, 다수의 pinned object에 의해 AF가 발생.
이경우는, pinned objects들만 사용할 수 있는 전용공간을 Heap상에 만들어 주면 된다.
이때 사용되는 대표적인 옵션은 아래와 같다.
-Xknnn  -Xpiii[k][,ooo[k]] 

• nnn is the maximum number of classes used by the application,
• iii is the size of the primary pinned cluster, 
• ooo is the size of the overflow pinned clusters in bytes, and
• Using k changes value from bytes to kilobytes.

윗 영문해설은 'ibm'사이트에서 발췌한 항목에 대한 설명인데, 개인적으로는 다음과 같이 이해하고 있다.
 'nnn'은 메모리에 로딩된 application class의 총 개수를 의미하며, 'iii'는 pinned objects를 연속된 공간에 묶기 위한 cluster된 공간의 크기인데, WAS등이 부팅되면서 로딩시키는 class들 중, pinned성격의 object들이 먼저 위치하는 공간의 크기를 의미하며, 'ooo'는 JVM Runtime시 종종 생성되고 사라지는 pinned object들이 위치하는 공간이다.
통상, -Xk로 표현되는 옵션을 'KCluster'라고 부르며, -Xp로 표현되는 옵션을 'PCluster'라고 부른다.

통상적인 경우, 1.3.1_07 이상 및 1.4.2 이상의 ibm jdk에서는 이를 산출하기 위한 back data를 볼 수 있는 옵션을 제공하고 있다.

• 1.3.1_07 이상의 1.3대 jvm
  -verbosegc -Xtgc2
  
• 1.4.2 이상의 jvm
  -verbosegc -Dibm.dg.trc.print=st_verify

위의 설정이 작동하게 되면, standard out 에 아래와 같은 로그가 찍히게 된다.
<GC(VFY-SUM): pinned=3000(classes=2755/freeclasses=0) dosed=9388 movable=1045582 free=3340>
해석해 보면, 총 2755개의 application class들이 로딩되어 있으며, 이중 unmovable object로는 pinned objects가 3000개, 그리고 순간 pinned화 된 dosed object가 9388개 존재한다. 기타 movable한 object는 1045582개 존재하며, mark가 끊긴 object들은 3340개 존재한다.

위와같은 로그를 획득하였다면, -Xk와 -Xp의 sizing을 해 보자.

• -Xk sizing
  통상적으로 로딩된 class개수의 10%정도를 더 설정해 주는 것을 권고한다. 위의 data를 기반으로 산출해 보면 아래와 같다.
  2755 + (2755x0.1) = 3030, 따라서 -Xk3030과 같이 설정한다.
  
• -Xp sizing
  이부분에 대한 명쾌한 설명을 하고 있는 자료를 본적이 없다. IBM에서도 아래와 같이 설명하고 있다.
  If the problem still persist after setting a -Xk value then you may want to look at setting  -Xp as well and examining the application code to see if you can reduce the size of the larger objects that are being requested.
  Sizing the -Xp option is a complex task and should only be done with assistance from IBM Support.
  
  위에서 설명한데로, -Xpiii[k][,ooo[k]]형식이 되는데, 'iii'는 pinned objects를 연속된 공간에 묶기 위한 cluster된 공간의 크기인데, WAS등이 부팅되면서 로딩시키는 class들 중, pinned성격의 object들이 먼저 위치하는 공간의 크기를 의미하며, 'ooo'는 JVM Runtime시 종종 생성되고 사라지는 pinned object들이 위치하는 공간으로 이해한다.
  
  따라서, -Xk옵션으로 별다른 개선효과가 없다면, AF가 발생했을 당시의 gc로그를 기반으로, AF를 유발한 object 크기를 유형별로 산출하여, 단위시간에 몰리는 object크기의 총 합정도를 설정하여, 반복테스트를 통하여 가장 좋은 성능을 발휘하는 임계치를 찾는 방법을 사용해야 할 것 같다.
  

사례 2) unmovable obejcts는 많지 않지만, 다수의 dosed objects들에 의한 AF발생.

• -Xcompactgc
  모든 GC사이클 수행시마다, compact를 수행한다. 성능은 크게 감소할 것을 감수해야 한다.
  하지만, 해당 옵션을 활성화 시켜서 AF가 많이 줄어 든다고 판단되면, dosed objects들에 의한 AF가 많다라고 간주하는데 판단기준이 될 수 있다.
  
• -Xpartialcompatgc
  compact trigger가 자주 발생한다. 즉, 기존의 full compaction을 점진적(incremental)으로 진행한다.
  비활성화는 -Xnopartialcompactgc로 설정하면 되고, full compaction 모드로 작동하게 된다.
  
• -Xgcpolicy
  IBM JVM 튜닝 - 1 을 참조한다.
  

사례 3) unmovable obejcts는 많지 않지만, 다수의 large size objects들에 의한 AF발생.
large object를 위한 loa(large object area)영역을 지정한다.

• jdk 1.4 이상
  -Xloratio : loa 영역의 크기를 백분률로 지정한다. 
                 loa 영역을 지정한 경우, 통상적으로 Xmx영역을 일정비율 늘려줘야 한다. 
                 공식은 아래와 같다.               
                                     New Xmx = Current Xmx / (1 - loratio)
  
• jdk 1.5이상
  -Xloa : 64k 이상의 large object들만을 담는 loa(large object area)를 활성화 한다.
  -Xloainitial : loa영역의 초기 백분률로 0~0.95의 수치를 지정한다. 기본값은 0.05(5%)이다.
  -Xloamaximum : loa영역의 최대 백분률로 0~0.95의 수치를 지정한다. 기본값은 0.5(50%)이다.

포스팅을 마무리하고 보니, IBM JVM 튜닝중 AF쪽에 포커스가 맞추어 진 느낌이다.
다음에는 IBM JVM 전반에 걸쳐 포스팅을 해볼까 한다.

출처 : http://javagosu.tistory.com/29