유용한 JVM 플래그들 – Part 4 (힙 튜닝)

이상적으로, 자바 애플리케이션은 아무런 플래그를 지정하지 않은채 기본 JVM 세팅만으로도 잘 동작한다. 하지만 운이 나쁘게도 성능적인 문제에 직면했을때, 관련 JVM 플래그에 대한 지식들은 훌륭한 안내서가 된다. 이번시간에는 메모리 관리 영역에 대한 몇몇 JVM 플래그들을 살펴볼 것이다. 이러한 플래그들에 대해서 알고 있는 것과 이해하는 것은 개발자나 운영자로서의 높은 가치를 증명한다.

모든 설치된 HotSpot 메모리 관리와 가비지 컬렉션 알고리즘은 힙(Heap)의 동일한 기본 분할에 기초한다: “young generation” 은 새롭게 메모리가 할당된 것과 짧은 삶을 사는 객체를 가진다. 반면에 “old generation” 은 특정연령 이상 수명이 긴 객체를 포함한다. 그 외에, “permanent generation” 전체 JVM 라이프사이클을 통해서 살아가야할 객체를 포함하는데 예를들면 로드 된 클래스의 객체 표현이나 문자열 인터 캐쉬등이다. 다음시간부터 우리는 힙이 permanent, old, young generation 들이 전통적인 전략에 따라 분할되어 있다고 가정할 것이다. 그러나, 다른 전략들도 유망하다, 한가지 눈에 뛰는 새로운 G1 가비지 컬랙터의 존재는 young 과 old generation 사이의 구분을 흐리게 한다. 또,  HotSpot JVM 의 미래버전일 수 있는 현재 개발버전에서는 더 이상 old 와 permanent generation들을 구분하지 않을 것이다.

-Xms and -Xmx (or: -XX:InitialHeapSize and -XX:MaxHeapSize)

아주 유명한 JVM 플래그들로 최대 JVM 힙 크기와 초기 JVM 힙 크기를 각각 지정할 수 있도록 해주는 -Xms 와 -Xmx가 있다. 양쪽 모두 기본적으로 bytes 용량단위의 값을 가지지만 짧은 용량 표기법을 지원하는데 “kilo”는 “k”나 “K”, “mega”는 “m”나 “M” 그리고 “giga”는 “g”나 “G”로 표기할 수 있다. 예를들어, 다음의 커맨드 라인은 초기 힙 크기를 128 megabytes 와 최대 힙 크기를 2 gigabytes 로 세팅하고 “MyApp” 자바 클래스를 시작한다.

실제로, the initial heap size turns out to also be a lower bound for the heap size,i.e., 최소 힙 크기(minimum heap size). JVM이 런타임에 동적으로 힙의 크기를 조정할 수 있으며, 따라서 이론적으로 우리는 힙의 크기가 초기 힙 크기 아래로 떨어지는 것을 관찰할 수 있는 것은 사실이지만, 나는 실험적으로 아주 낮은 힙을 사용할때조차도 이러한 것을(이론상으로 가능한 것) 목격한 적은 없다. 이러한 행동은 개발자와 운영자에게 편리한데, 단순하게 -Xms 와 -Xmx 를 같은 값으로 세팅함으로써 정적 힙 크기를 지정할 수 있도록 해주기 때문이다.

-Xms 와 -Xmx 가 짧은 약어이며 이것은 내부적으로 -XX:InitialHeapSize 와 -XX:MaxHeapSize 로 매핑된다. 이러한 두개의 XX 플래그들은 같은 효과을 주기위해서 직접 사용할 수 있다.

주목할 것은 초기 및 최대 힙 크기에 관한 모든 JVM 출력이 독점적으로 긴 이름을 사용한다. 따라서 동작중인 JVM 의 힙 크기에 대한 정보를 찾을때에는, -XX:+PrintCommandLineFlags 의 출력으로 체킹을 하거나 JMX를 통해 JVM 에 질의를한다거나, 우리는 “Xms” 나 “Xmx” 가 아닌 “InitialHeapSize” 나 “MaxHeapSize”를 찾아야 한다.

-XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath

만약 우리가 -Xmx 세팅을 적절한 값으로 하지 않을 경우에, JVM을 다룰 때 우리가 직면 할 수있는 가장 무서운 짐승의 하나인 OutOfMemoryError 와 마주칠 위험을 동반한채 JVM이 동작한다. 이 주제에대해 이 블로그에서 상세하게 다루었듯이, OutOfMemoryError의 근본원인을 신중하게 다룰 필요가 있다. 종종, 특별히 만약 JVM 이미 크래쉬(Crash) 되었고 애플리케이션이 몇 시간 또는 며칠 동안 부드럽게 실행 후에 오류가 프로덕트 시스템에만(Product system. 역) 실제 서비스를 하고 있는 시스템을 말한다) 나타나는 않았다면 깊이 있는 분석에 대한 좋은 방법은 힙 덤프(Heap Dump)이다. – 만약 사용할 수 없다면 최악이다

운좋게도, -XX:+HeapDumpOnOutOfMemoryError 플래그를 세팅함으로써 OutOfMemoryError 발생했을때에 자동적으로 힙 점프를 생성하도록 JVM에 지시할 수 있다. 단지 그러한 경우에 대한 플래그를 세팅함으로써 예기치못한 OutOfMemoryError 에 직면했을때에 많은 시간을 절약할 수 있다. 기본적으로, 힙 덤프는 JVM이 시작된 디렉토리에 java_pid<pid>.hprof(여기서 <pid>는 JVM 프로세스의 프로세스 ID이다) 파일에 저장된다. 이 기본값을 변경하기 위해서, 우리는 -XX:HeapDumpPath=<path> 플래그를 사용해 다른 위치를 지정할 수 있으며, <path> 는 힙 덤프를 저장할 파일에대해 상대적이거나 절대적인 경로가 될 수 있다.

아주 멋진 말인데, 우리가 명심해야할 게 있다. 힙 덤프는 특히나 OutOfMemoryError 가 발행했을때에 아주 큰걸 얻을 수 있다. 따라서 디스크 사용이 아주 넉넉한 위치를 지정하기 위해 -XX:HeapDumpPath 를 사용할 것을 권장한다.

-XX:OnOutOfMemoryError

우리는 OutOfMemoryError 가 발생했을때 임의 명령행을, e.g., 관리자에게 메일을 보낸다든가 어떤 클린업(Cleanup) 작업을 실행시키다든가하는, 실행시킬 수도 있다. 이것은 명령어들의 리스트와 그들의 파라메터들을 가지는 -XX:OnOutOfMemoryError 플래그로 인해서 가능하다. 우리는 이것에 대해 자세히 나가진 않고 설정예제를 보여주겠다. 다음 명령어 라인 상태에서 OutOfMemoryError 가 발생하면 우리는 /tmp/heapdump.hprof 파일에 힙 덤프를 작성하고 동작중인 JVM 의 사용자 홈 디렉토리에 쉘 스크립트 cleanup.sh 가 실행된다.

-XX:PermSize and -XX:MaxPermSize

Permanent 세대는 JVM에 의해서 로드되는 모든 클래스의 객체표현을 포함하는 것으로 힙 영역과 분리된다. 많은 클래스들을(e.g., because they depend on lots of third-party libraries, which in turn depend on and load classes from even more libraries) 로드하는 애플리케이션을 성공적으로 동작시키기 위해서는 아마도 permanent 크기를 증가시킬 필요가 있을 것이다. 이것은 -XX:PermSize 와 -XX:MaxPermSize 플래그를 사용해 가능하다. 여기서 -XX:MaxPermSize 는 permanent 세대의 최대 크기를 지정하는 것이고 반면에 -XX:PermSize 는 JVM 시작시에 초기화할 크기이다. 예를들어,

주의할 것은 permanent 세대 크기는 -XX:MaxHeapSize 로 지정되어지는 힙 크기의 일부로 계산되지 않는다. -XX:MaxPermSize 의해서 정한 permanent 세대 메모리의 양은 -XX:MaxHeapSize 에의해서 정해진 힙 메모리에 더해서 필요하게 되어질 수 있다.

-XX:InitialCodeCacheSize and -XX:ReservedCodeCacheSize

자주 JVM 메모리 영역에서 무시되어지는 재미있는 영역은 “코드 캐쉬(code cache)” 인데, 이것은 컴파일된 메소드의 네이티브 코드 생성을 저장하는 데 사용된다. 코드 캐쉬는 거의 성능문제를 발생시키지 않지만, 한번 코드 캐쉬 문제가 생기면 그 효과는 어마어마할 것이다. 만약 코드 캐쉬 메모리를 모두 사용하게 되면, JVM 은 경고 메시지를 출력하고 “interpreted-only mode” 로 전환한다. JIT 컴파일러는 정지되고 더이상 바이트코드(bytecode)는 네이티브 코드로 컴파일 될지 않을 것이다. 따라서 애클리케이션이 동작은 계속되지만 크기의 순서에따라 점점 느려진다.

다른 메모리 영역과 같이 우리는 코드 캐쉬 크기를 정할 수 있다. 관련 플래그로 -XX:InitialCodeCacheSize 과 -XX:ReservedCodeCacheSize이 있고 위에서 소개한 플래그들처럼 byte 용량 값을 가진다.

-XX:+UseCodeCacheFlushing

만약 코드 캐쉬가 지속적으로 증가한다면, 예를들어 hot deployment 로 인해서 발생된 메모리 릭으로 인해서, 코드 캐쉬를 늘리는 것은 단지 필연적으로 발생될 오버플로우(OverFlow)를 지연시킬 뿐이다. 오버플로우를 비하기 위해, 코드 캐쉬 메모리가 가득찼을때에 JVM이 몇몇 컴파일된 코드를 정리하도록 시키기위해 우리는 재미있고 비교적 새로운 옵션을 시도할 수 있다. 우리는 -XX:+UseCodeCacheFlushing 플래그를 지정하면 된다. 이 플래그를 사용함으로 인해서 우리는 적어도 코드 캐쉬 문제에 직면했을때에 “interpreted-only mode” 전환되는 것을 적어도 피할 수 있다. 그러나 나는 여전히 코드 캐쉬 문제가 발생되면 가능한 빨리 근본 원인을 차단하길 권장한다. 예를들어, 메모리 릭을 규명하고 그것을 고치는 방법.