Go 서버의 지연이 튀는 시점에 GC도 자주 실행됩니다. GC가 원인인지 확인하고 메모리와 지연을 어떻게 조정하나요?

먼저 지연이 큰 시점과 GC 활동이 실제로 겹치는지 확인하겠습니다. Go GC는 대부분 동시 실행되지만, 짧은 정지뿐 아니라 GC가 쓰는 CPU나 애플리케이션의 할당 보조 작업도 처리 지연에 영향을 줄 수 있습니다. GC 횟수만 보고 원인이라고 단정하지는 않겠습니다.

GC를 원인으로 확정하기 전

GC는 더 이상 필요하지 않은 객체의 메모리를 회수하는 런타임 기능입니다. 살아 있는 객체의 양이 작아도 요청마다 임시 객체를 많이 만들고 버리면 회수 작업이 자주 필요할 수 있습니다. 반면 오래 살아 있는 캐시가 커지는 문제는 할당률과는 다른 축이므로 두 지표를 구분해야 합니다.

요청마다 작은 임시 객체를 많이 만드는 경로가 있다고 하겠습니다. 살아 있는 힙은 크지 않아도 할당 속도가 높으면 GC가 자주 일할 수 있습니다. 저는 할당 프로파일에서 어떤 호출이 객체를 만드는지 보고, 버퍼의 불필요한 복사나 포맷팅부터 줄이겠습니다. 풀을 쓰면 할당을 줄일 수 있지만 객체를 오래 붙잡아 살아 있는 힙과 구현 복잡성이 늘 수 있어 실제 재사용 이득을 확인해야 합니다.

할당률과 메모리 예산

GOGC를 높이면 일반적으로 더 큰 힙을 허용해 수집 빈도를 줄일 수 있지만 메모리 예산을 더 씁니다. GOMEMLIMIT도 전체 프로세스 메모리의 엄격한 상한으로 보지는 않겠습니다. 관리 밖의 메모리와 필요한 살아 있는 데이터가 있기 때문입니다. 먼저 할당 원인을 줄이고, 이후 실제 메모리 한도와 부하에서 설정을 비교하겠습니다. 성공 기준은 GC 횟수 감소가 아니라 오류 없이 처리하는 양과 p99, 메모리 여유가 함께 나아지는지입니다.

선택 기준과 검증

GC와 지연이 같은 시각에 보여도 큰 JSON 변환, 락 대기, 스케줄러 지연이 함께 원인일 수 있습니다. 실험군과 대조군의 입력·동시성·메모리 한도를 고정하고, 수집 횟수보다 p99·GC CPU·heap live·오류율을 비교하겠습니다. 버퍼 풀은 재사용률이 낮거나 트래픽 하강 뒤 객체를 오래 보유하면 오히려 생존 힙을 키우므로, 풀 보유량과 회수 후 RSS도 같이 확인하겠습니다.

Go의 추적 GC는 살아 있는 객체를 찾아 표시해야 하므로 단순한 힙 바이트뿐 아니라 포인터가 많은 그래프의 스캔 비용도 중요합니다. 같은 100MB라도 바이트 배열과 작은 포인터 객체가 얽힌 그래프는 스캔 특성이 다릅니다. 할당이 수집 진도보다 빨라지면 할당하는 고루틴이 표시 작업을 돕는 mark assist 때문에 요청 지연이 늘 수 있어, stop-the-world 시간만 짧다고 GC 영향을 배제하지 않겠습니다.

GOGC는 생존 힙을 기준으로 다음 수집 목표를 조절하고, GOMEMLIMIT는 런타임이 관리하는 메모리의 소프트 한도로 작동합니다. 살아 있어야 하는 데이터가 한도에 가까우면 GC를 반복해도 줄일 수 없어 CPU를 소모할 수 있습니다. 이 경우 설정을 더 낮추기보다 캐시·동시성·버퍼 상한을 줄여야 합니다. sync.Pool은 항목이 언제든 제거될 수 있는 임시 재사용 장치이므로 필수 저장소나 고정 용량 풀처럼 의존하지 않겠습니다.