운영 중인 JVM이 갑자기 7~8초씩 통째로 멈춥니다(STW)... 며칠째 원인을 못 잡겠어요 제발

Question

정말 미치겠습니다. 평소엔 멀쩡한데 하루에 몇 번씩 서비스가 7~8초 동안 완전히 얼어붙습니다. 그 순간 요청이 죄다 타임아웃 나요. G1GC 쓰고 있고 힙은 8G입니다.GC 로그 보면 이런 게 찍힙니다.[gc] Pause Full (G1 Humongous Allocation) 7623.114ms [gc] To-space exhausted [gc] Humongous regions: 214->214 [gc,heap] region size 2048K평소 Young GC는 20~40ms로 짧은데 저 Full GC만 뜨면 8초씩 잡아먹습니다. 힙을 늘려도 봤고 -XX:MaxGCPauseMillis도 200으로 줬는데 소용없어요. 대체 뭐가 문제일까요? 고수님들 도와주세요...

김영삼 · Accepted Answer

로그에 답이 다 나와 있습니다. 핵심은 Humongous Allocation입니다. MaxGCPauseMillis를 아무리 낮춰도 이건 안 잡힙니다. 그 옵션은 Young/Mixed GC의 목표일 뿐이고 지금 문제는 Full GC거든요.G1은 힙을 고정 크기 region으로 나눕니다. 지금 region size 2048K, 즉 2MB네요. G1에서 region 크기의 절반(=1MB)을 초과하는 단일 객체는 'Humongous object'로 분류되어 연속된 여러 region에 특별하게 할당됩니다.문제는 이겁니다.Humongous 객체는 연속된 빈 region이 필요한데, 힙이 파편화되면 연속 공간을 못 찾습니다.그러면 To-space exhausted → Full GC로 폴백하고, 이게 STW로 수 초씩 멈추는 겁니다.즉 코드 어딘가에서 1MB를 넘는 큰 객체(대형 byte[], 큰 String, 큰 배열, 이미지/파일 버퍼 등)를 자주 할당하고 있습니다. 확인/해결 순서:1) -X

gc_narae · Answer

헉 짚어주신 대로 코드 뒤져보니 외부 API 응답을 byte[]로 통째로 받는 데가 있는데 이게 보통 3~4MB 됩니다. 이게 humongous였군요. 그럼 region size는 얼마로 잡아야 하나요? 계산법이 헷갈립니다.

김영삼 · Answer

정확히 범인 찾으셨네요. 계산은 간단합니다.Humongous 임계값 = G1HeapRegionSize ÷ 2. 이 값보다 큰 객체가 humongous가 됩니다.지금 region 2MB → 임계값 1MB → 3~4MB byte[]는 당연히 humongous.4MB 객체를 일반 객체로 만들려면 임계값이 4MB를 넘어야 하니 region ≥ 8MB가 필요합니다.그래서 -XX:G1HeapRegionSize=8m(또는 여유 두고 16m)로 설정하세요. 그러면 임계값이 4MB(또는 8MB)가 되어 그 byte[]가 더는 humongous로 분류되지 않고 일반 Young 영역에서 처리됩니다. 참고로 G1HeapRegionSize는 반드시 2의 거듭제곱(1,2,4,8,16,32MB)이어야 합니다.-Xmx8g -Xms8g -XX:+UseG1GC -XX:G1HeapRegionSize=16m -Xlog:gc*:file=gc.log한 가지 주의: region을 키우면 region 개수가 줄어(8G/16M

gc_narae · Answer

G1HeapRegionSize=16m 적용하고 반나절 지켜봤는데 humongous Full GC 로그가 완전히 사라졌고 그 8초 프리징도 재현이 안 됩니다. 병행해서 byte[] 스트리밍 처리도 리팩터링 들어가려고요. 임계값=region/2 이 공식 하나로 다 이해됐습니다. 정말 감사합니다 🙏

댓글 0