Go 언어의 가비지 컬렉터(GC)가 전체 실행 정지(STW) 상태에서 힙(heap) 외부 메타데이터를 읽을 때, 해당 메타데이터가 운영체제의 스왑 공간으로 밀려나 있으면 최대 40ms에 달하는 예상치 못한 지연이 발생한다는 사실이 실험을 통해 밝혀졌습니다. 이는 Go 애플리케이션의 성능에 중요한 영향을 미칠 수 있는 문제로, 특히 낮은 지연 시간(latency)이 필수적인 서비스 환경에서 우려를 낳고 있습니다.
이번 실험은 커널 6.8과 MGLRU(Multi-Generational LRU)가 활성화된 Hetzner 서버에서 진행되었습니다. 30분 동안 312회의 STW 정지를 관측했으며, 중앙값은 약 51µs로 매우 짧았지만, 최악의 경우 메타데이터가 NVMe 스토리지로 스왑되었을 때 40ms의 정지가 발생했습니다. 이는 중앙값의 약 800배에 달하는 수치로, 228회의 페이지 폴트(page fault) 처리 과정에서 39ms가 소요된 것으로 분석됩니다. 이 지연은 GC의 내부 관리 작업과 관련된 것으로 확인되었으며, 511KiB 메시지 생성 시간이 평소 3~5ms에서 NVMe 사용 시 105ms, 네트워크 볼륨 사용 시 903ms로 늘어나는 현상도 관측되었습니다. Go 1.26의 Green Tea GC에서도 메타데이터 읽기 문제에 대한 영향은 미미한 것으로 나타났습니다.
이러한 현상은 GC가 STW 중 읽는 힙 외부 메타데이터가 스왑 대상이 될 수 있기 때문에 발생합니다. 커널은 페이지 접근 시점을 기준으로 오래 접근하지 않은 페이지를 스왑으로 내보내는데, 이후 GC가 STW 상태에서 해당 페이지를 읽으려 하면 메이저 페이지 폴트가 발생하여 커널의 스왑 처리와 디스크 대기 시간을 거쳐야 합니다. 모든 P(프로세서)가 정지하는 STW 동안에는 I/O가 완료되어도 고루틴(goroutine)이 이를 처리할 수 없어 지연이 더욱 길어집니다. 이는 Go 애플리케이션이 메모리 압박이 심한 환경에서 스왑을 사용할 때, 예상치 못한 성능 저하를 겪을 수 있음을 시사합니다. 따라서 지연 시간이 중요한 애플리케이션의 경우 스왑 사용을 신중하게 고려하거나, mlock()과 같은 기능을 통해 핵심 메모리 영역을 고정하는 방안을 검토할 필요가 있습니다.