JVM Option 설정에 대하여

작성일 | In

No Image

JVM (Oracle) Options

-Xms, -Xmx

  • -Xms
    • JVM 시작시의 Heap size
  • -Xmx
    • 최대 Heap size

-Xms, -Xmx를 어떻게 셋팅하는 것이 좋을까?

  • -Xms, -Xmx를 동일하게 셋팅하는 것을 추천.
  • Heap 사이즈를 변경하기 위해 런타임 기간동안 발생하는 불필요한 오버헤드를 줄일 수 있다.
  • 과거의 JVM 기준으로 내려오는 설정방법이라는 의견이 있다.
  • 최신 JVM에서는 설정안하는 것을 추천한다고 하는데 테스트를 진행하고 확인해봐야 한다.
  • Reference

    In very early versions of the adaptive sizing algorithms there may have been some advantage to running with this combination, but for modern workloads it’s almost always counterproductive. If you set this combination, the JVM is constrained in how it can resize and shape the heap, making it less responsive to sudden changes in traffic behavior or request rate.

그럼 Heap Size를 어느 정도까지 설정하는게 좋을까?

  • 32bit 운영체제인 경우 최대 Heap Size는 2^32 = 4GB를 사용할 수 있다.
  • 64bit 운영체제인 경우 최대 Heap Size는 그보다 더 많이 사용할 수 있다.
    • 하지만 포인터 크기가 증가함에 따라 불필요한 메모리를 사용하는 단점이 있다.
    • Java에서는 더 많은 Heapsize와 작은 포인터 크기를 사용하기 위해 Compressed Ordinary object pointers를 사용하였다.
    • 실제로 주소가 아닌 주소의 Offset을 8의 배수로 계산하여 가지기 때문에 최대 힙사이즈는 4GB -> 32GB로 증가하게 된다.
    • 최대 힙 사이즈가 32GB를 넘어서게 된다면 JVM은 64bit 기반의 OOP를 사용하게 된다.
    • 그렇기 때문에 ElasticSearch에서는 최대 HeapSize를 32GB 이하로 권장한다.

항상 Heap Size가 크다고 좋은것일까?

  • 같은 애플리케이션일 경우 2GB의 힙을 사용하는 경우가 8GB 크기의 힙을 사용하는 것보다 풀 GC에 걸리는 시간이 짧아 응답 반응성에 유리하다.
  • 하지만 8GB 힙을 사용하면 2GB보다 풀 GC 발생 간격이 그만큼 줄어들 것이고 내부 캐시를 사용하는 애플리케이션이라면 히트율을 높여 응답 반응성을 높일 수 있다.
  • 어느 것을 선택해도 Trade-off가 발생하기에 상황에 맞게 적절한 해결방법을 찾자.

JVM DNS Cache

  • JVM 내부에서도 DNS Cache를 한다. DNS 변경에 바로 반영이 되려면 캐시를 없애는 편이 좋아보인다.
  • networkaddress.cache.ttl
  • sun.net.inetaddr.ttl
    • -1 - 영속적인 캐시를 지원한다.
    • 0 - 캐시를 없앤다.

JVM Server 모드

  • -client
    • JIT(Just in time) Compiler를 사용하기에 서버 시작 시간은 빨라지고 더 작은 메모리 사용량(foot-print)를 사용한다.
    • 보통 GUI 시스템, 작은 시스템을 구동하는데 사용하기 좋다.
  • -sever
    • client 모드보다 더 많은 최적화를 진행한다.
    • 빠른 Operation이 (작은 메모리 사용량, 빠른 시작 시간)보다 더 중요한 상황에서 사용하면 적절하다.

-XX:MaxPermSize=, -XX:PermSize=

-XX:UseContainerSupport

JIT Compiler option

-XX:CompileThreshold

Reference

0%