GC 로그 분석
Elasticsearch 는 현재 CMS GC 방식으로 운영하고 있다.
운영하면서 발생되는 GC 로그는 크게 Minor GC / Major GC 로 나뉜다.
Minor GC Log
[2024-12-26T01:33:11.134+0000][7860][gc] GC(116956) Pause Young (Allocation Failure) 10695M->9167M(16006M) 16.598ms
[2024-12-26T01:33:11.150+0000][7860][gc] GC(116957) Pause Young (GCLocker Initiated GC) 9169M->9168M(16006M) 15.689ms
1. Timestamp & GC 정보
- [7860]
해당 부분은 JVM 프로세스 ID 이다
- [gc]
가비지 컬렉션 관련 로그임을 나타낸다.
- GC(116956)
이번 로그가 116956번째 가비지 컬렉션 이벤트임을 나타낸다.
2. GC 유형
- Pause Young (Allocation Failure)
Young 세대에서의 가비지 컬렉션이며, 새로운 객체를 할당하기 위한 공간 부족때문에 발생함을 나타낸다.
- Pause Young (GCLocker Initiated GC)
이는 GC Locker 에 의해 발생한 Young 세대 가비지 컬렉션이다.
GC Locker 는 JNI(Java Native Interface) 의 호출이
가비지 컬렉션을 방해하지 않도록 잠금을 거는 메커니즘이다.
3. 메모리 사용량
- 10695M → 9167M(16006M)
10695M: 가비지 컬렉션 전 Young 제네레이션 메모리 사용량.
9167M: 가비지 컬렉션 후 Young 제네레이션 메모리 사용량.
16006M: 할당된 전체 힙 메모리 크기.
Major GC Log
[2024-12-25T19:36:41.333+0000][7860][gc] GC(109791) Pause Initial Mark 10729M->10729M(16006M) 1.458ms
[2024-12-25T19:36:41.333+0000][7860][gc] GC(109791) Concurrent Mark
[2024-12-25T19:36:41.474+0000][7860][gc] GC(109791) Concurrent Mark 137.944ms
[2024-12-25T19:36:41.474+0000][7860][gc] GC(109791) Concurrent Preclean
[2024-12-25T19:36:41.552+0000][7860][gc] GC(109791) Concurrent Preclean 84.458ms
[2024-12-25T19:36:41.552+0000][7860][gc] GC(109791) Concurrent Abortable Preclean
[2024-12-25T19:36:43.568+0000][7860][gc] GC(109791) Concurrent Abortable Preclean 2012.906ms
[2024-12-25T19:36:43.677+0000][7860][gc] GC(109791) Pause Remark 11512M->11512M(16006M) 100.848ms
[2024-12-25T19:36:43.677+0000][7860][gc] GC(109791) Concurrent Sweep
[2024-12-25T19:36:46.037+0000][7860][gc] GC(109792) Pause Young (Allocation Failure) 7492M->5958M(16006M) 14.723ms
[2024-12-25T19:36:47.006+0000][7860][gc] GC(109791) Concurrent Sweep 3339.648ms
[2024-12-25T19:36:47.006+0000][7860][gc] GC(109791) Concurrent Reset
[2024-12-25T19:36:47.068+0000][7860][gc] GC(109791) Concurrent Reset 55.357ms
위의 로그는 Major GC, 특히 “Concurrent Mark Sweep“ (CMS) 가비지 컬렉션 과정을 기록한 것이다.
1. Pause Initial Mark
GC 가 시작될 때, 힙 메모리에서 접근 가능한 객체들을 초기 표시하는 짧은 정지가 있다.
이 경우에는 메모리 사용량은 변하지 않는다.
2. Concurrent Mark
초기 표시 이후, JVM은 애플리케이션을 중단하지 않고 사용 중인 객체를 식별하기 위해 힙을 횡단한다.
3. Concurrent Preclean
표시 과정에서 변경된 부분을 미리 정리한다.
4. Concurrent Abortable Preclean
필요한 경우, 추가적인 정리를 수행할 수 있는 단계
5. Pause Remark
가비지 컬렉션의 최종 표시 단계로, 힙 전체를 정밀 검사하여 GC 를 완료하기 전에 놓친 부분이 없는지 확인
6. Concurrent Sweep
사용하지 않는 객체들을 Heap 에서 실제로 제거하는 단계.
이 단계는 비교적 긴 시간 동안 실행된다.
7. Concurrent Reset
다음 GC 사이클을 위해 가비지 컬렉터를 리셋한다.
'Elasticsearch' 카테고리의 다른 글
[Elasticsearch] maximum shards open error (0) | 2023.12.27 |
---|---|
[Elasticsearch] 검색성능 비교 (0) | 2023.05.15 |
[Elasticsearch] Nori 분석기 적용 (0) | 2023.05.14 |
[Elasticsearch] Disk-based shard allocation (1) | 2023.03.02 |
[Elasticsearch] text, keyword 타입 (0) | 2023.03.02 |