들어가며

해당 옵션을 알게된 계기

JDK8 → JDK17로 올리면서 RSS 메모리가 튀었고, 이 때문에 pod OOM이 났다.
devops 분들이 anon 뭐시기가 메모리를 엄청 먹고있다고 했고, k8s에 의해서 프로세스 킬을 이것 때문에 한 로그가 남았다고 했음
- dmesg 옵션으로 봤따는데 이 때 C2 CompilerThread가 죽였다고 뜸 anon이 엄청 많았다는데 이것도 알아보자
MALLOC_ARENA_MAX 옵션이 기본값으로는 CPU에 n 배수인데, 컨테이너 환경에서도 노드의 하드웨어 기준으로 값이 할당되고 있어 과도한 리소스를 사용할 수 있는 잠재적 위험이 있을 것으로 판단된다고 함
- 노드랑 파드의 차이가 뭐지?
이걸 값 4로 줄였더니 RSS가 튀는 것이 없어졌고, 또한 RSS 사용량이 200MB 정도 줄었다.
throughput이 기존보다 떨어질 것이라고 생각했는데 거의 안떨어졌다. 이건 왜 그런거지? arena에 대한 thread들의 lock 경합이 벌어져서 느려질 것이라고 생각했는데 왜 비슷할까..?
같이 알아볼 옵션
- -XX:UseDynamicNumberOfComplierThreads
- -XX:UseAVX=2
- -XX:TrimNativeHeapInterval=10000
- jeprof, jemalloc이 뭔가

고려 순서

JVM 힙 이슈인가? → GC나 힙 관련 메트릭에서 특별한 문제 없었고, 다른 파드와 비교했을 때도 특이점 없음
Off-Heap 이슈인가?
- memory map을 살펴봐야함 → 이건 어케 확인하지? 정상적인 프로세스 대비 많은것을 확인했다함
- off-heap 이슈가 일어나는 원인에는 뭐가 있지? → 알아보기
JDK 버전업하면 이런 이슈가 있나?

참고할 것