core JVM 힙 상한 정정

[m-a-king]

한눈에

core 서버의 JVM 힙 크기를 컨테이너 메모리 한도에 맞춤

• 이전: core 컨테이너가 쓰는 메모리가 컨테이너 한도보다 큼
  • JVM 이 힙 말고도 클래스 정보·컴파일된 코드·스레드에 약 400MiB 를 씀
  • 결과: 한도에 닿을 때마다 커널이 메모리를 디스크 스왑으로 내보냄
• prod 는 JVM 힙 상한을 줄이고 dev 는 컨테이너 한도를 올림
• dev 검증 배포 뒤 스왑이 약 280MiB 에서 6MiB 로 줄어듦
• 머지하면 dev 자동 배포, prod 는 다음 승격 때 반영

Situation

착수 후 확인

• core JVM 힙 상한 정정 #1215
• 힙 밖 크기는 실행 중인 프로세스에서 직접 잼(10-15)
  • 프로세스의 실제 상주 메모리와 스왑을 더한 뒤 JVM 이 잡아 둔 힙을 뺌

항목	prod	dev
상주 메모리 (anon)	726MiB	551MiB
스왑	0.4MiB	141MiB
힙 committed	352MiB	288MiB
힙 밖 (metaspace·코드 캐시·스레드·malloc)	약 375MiB	약 405MiB

• 이전 산정은 힙 밖을 250-300MiB 로 봄
  • 원인: JVM 지표의 nonheap 은 metaspace·코드 캐시만 셈. 스레드·GC 구조·malloc 은 빠짐
• prod 는 지금 힙이 352MiB 라 한도 안에 있음
  • 힙이 Xmx 512m 까지 크면 약 890MiB 로 한도 768MiB 초과

Task

힙과 한도를 실측 힙 밖 크기에 맞춤

• core JVM 힙 상한 정정 #1215

Action

환경별 값

항목	이전	이후
prod 한도	768m	768m
prod Xmx	512m	352m
dev 한도	576m	704m
dev Xmx	288m	256m

• prod Xmx 352m 는 GC 뒤 살아 있는 객체 최대치 172MiB 의 약 2배
  • 352 + 375 = 727MiB 라 한도 안에 약 40MiB 여유
• dev 는 Xmx 를 줄이는 것만으로 576m 안에 안 들어감
  • 576m 에 맞추려면 Xmx 약 130m 이하
  • 원인: GC 뒤 살아 있는 객체 최대치가 154MiB
• 컨테이너 스왑 한도는 두 환경 모두 기존 관례대로 한도의 2배 유지

선택지	장점	비용
prod Xmx 축소, dev 한도 상향 (채택)	서버 크기 그대로. prod 는 박스 메모리 사용 변화 없음	prod 힙 여유 감소, young GC 횟수 증가
두 환경 모두 한도 상향	힙 그대로	prod 박스 여유 감소. 서버 축소 검토와 반대 방향
서버를 4GiB 로 키움	여유 큼	서버당 월 약 $15 추가. 한도가 JVM 보다 작은 원인은 그대로 남음
힙 밖 상한 지정 (metaspace·코드 캐시 상한)	힙 밖이 커지는 것을 막음	상한을 잘못 잡으면 JVM 종료나 컴파일 중단. 지금은 커지는 추세가 없어 보류

메모리 값 선택 기준을 브랜치에서 환경으로 바꿈

• 이전: main 브랜치면 prod 값, 그 외는 dev 값
  • 원인: 계정 이관은 dev 브랜치에서 prod 로 배포함
  • 결과: 이관 배포가 prod 서버에 dev 값으로 뜸

배포 겹침 합산 주석 삭제

• 두 슬롯 동시 기동 때 합계가 서버 메모리 안이라는 계산
  • 원인: OS·docker·Alloy 고정 몫 약 400-500MiB 가 빠진 계산
• 겹치는 약 35초 동안 넘치는 몫은 박스 스왑이 받는다는 한 줄로 대체

Result

dev 검증 배포 (이 브랜치를 dev 에 수동 배포)

항목	이전 (576m·Xmx288)	배포 직후 (704m·Xmx256)
상주 메모리 (anon)	551MiB	603MiB
컨테이너 스왑	280MiB	7MiB
한도 도달 횟수	30분에 수백 번 몰림	0

• 검증 배포는 약 18분 유지됨
  • 원인: 05:51(UTC) 다른 PR 머지로 dev 가 dev 브랜치로 다시 배포됨
  • 그 뒤 옛 설정(576m·Xmx288)에서 다시 스왑 261MiB
• 위험: 힙 밖은 오래 떠 있을수록 늘어남(코드 캐시·metaspace)
  • 배포 직후 dev 힙 밖은 약 347MiB
  • 약 8.5시간 떠 있던 컨테이너의 실측 405MiB 를 쓰면 256 + 405 = 661MiB 로 한도 704MiB 안
  • 머지 뒤 몇 시간 지나 한도 도달 횟수 재확인 필요
• 위험: dev 박스 가용 메모리가 core 가 늘어난 만큼 줄어듦
  • 배포 직후 박스 가용 665MiB

후속

• prod 는 승격 뒤 힙이 커지는 시점의 한도 도달 횟수 확인
• 컨테이너 메모리 지표(cAdvisor)를 prod 서버에 깔면 대시보드로 확인 가능

---

연관 이슈

• close core JVM 힙 상한 정정 #1215

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Repository: TeamPiKi/core/.coderabbit.yml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 9cb5db36-7d6e-45de-869c-652dcb58a33b

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Discord 스레드 연동용 메타데이터입니다. discord-pr-bot 워크플로가 자동 생성하며, 수정·삭제하면 PR 과 Discord 알림 연동이 끊깁니다.