ElasticSearch Full GC 해결 과정

8월 3째주

세상이 멈췄다

엘라스틱서치를 사용하는 서비스 API 에서 간헐적으로 circuit breaker 가 오픈됐다. circuit breaker 가 오픈되는 이유 중에 하나는 API 반환이 제 시간에 되지 못했다는 것이다. 그 시간대에 엘라스틱서치에 무슨 일이 있었나 키바나로 확인해 보니

세상에나! Full gc 수행시간이 600 ms 가량 치솟았다.

한 번만 발생한 거라면 살짝 넘어갔겠지만.. 간헐적으로 발생하고 있었기에 조치가 필요했다.

여러 대안이 있었고 그 때 당시 Heap 메모리 사용량이 90% 에 육박했기에 메모리를 30% 가량 증설하였다.

♣ 노드 하나당 힙 메모리: 24G → 32G

8월 4째주

해결된 듯 했으나

메모리 증설 후 며칠동안 상황을 지켜봤는데 이런.. Full GC 가 또 치솟는것이 아닌가!

stop-the-world 시간이 약 1초 이고 이 시간동안 엘라스틱서치가 아무 일도 못하고 멈춰있으니 또 다른 튜닝 포인트를 찾아야 했다.

GC 를 조사해보자

ElasticSearch 6 버전은 디폴트 Garbage Collector 로 CMS GC 를 쓰고 있다.

CMS GC(Concurrent Mark Sweep GC) 는 멀티쓰레드로 동작하고 메모리 정리 후의 조각난 공간은 필요한 경우에만 합치기(=compaction 과정) 때문에 일반적으로는 GC 시간이 짧다. 하지만 한 번 compaction 이 일어나면 비교적 긴 stop-the-world 시간이 소요된다. (방청소를 1년에 한 번 하는 게 1주일에 한 번 하는 것보다 오래 걸리는 느낌?!)

CMS GC 는 stop-the-world 시간이 오래 걸릴 수도 있다고..?

당시 힙 메모리 사용량이다. 약 23.3 GB 를 유지하다가 Full GC 수행 후 5 GB 대로 훅 떨어졌다. 아 가용 힙 메모리가 너무 커서 채울 수 있을 때 까지 채웠다가 롤러코스터 내려가듯이 쭈욱 18 GB 정도의 메모리를 정리하려니 stop-the-world 시간이 그렇게 길었을 수도 있겠구나 싶었다.

그렇다면, 오히려 힙 메모리 사이즈를 더 줄여보는 것이다!

♣ 노드 하나당 힙 메모리: 32G → 16G

8월 5째주

과유불급이렸다..

빨간 세로 선이 힙 메모리를 축소한 시점이다. 그 이후로 비정상적인 Full GC 는 더 이상 발생하지 않았고 API circuit breaker 도 오픈되지 않았다. 상황 종료!