역사 Go 1.19 이전에는 런타임에서 가비지 컬렉션을 제어하기 위해 GOGC만 제공되었으며, 이는 라이브 메모리에 비례하여 힙 트리거를 조정합니다. 이 점은 cgroups가 절대 메모리 제한을 부과하는 컨테이너화된 배포에서는 불충분했습니다. 개발자들은 런타임에 한계 개념이 없었기 때문에 OOM 킬에 직면했습니다.
문제 Go 프로세스가 하드 메모리 제한(예: Docker 또는 Kubernetes를 통한 512 MiB) 내에서 실행될 때, 기본 GOGC=100은 가비지 컬렉션을 트리거하기 전에 힙을 두 배로 증가시킬 수 있도록 합니다. 컨테이너 경계에 대한 인식이 없으면 런타임은 커널이 OOM 킬러를 호출할 때까지 할당을 계속하여 프로세스를 충돌시키고 생존을 우선시하지 않습니다.
해결책 Go 1.19는 런타임에 의해 적용되는 소프트 메모리 제한인 GOMEMLIMIT를 도입했습니다. 하드 한계와 달리 할당을 중단하지 않고 GC 속도를 수정합니다. 힙 크기(스택, 전역 데이터 및 런타임 오버헤드를 포함)가 한계에 근접할 때, 런타임은 GOGC가 제안하는 것보다 더 공격적인 새로운 GC 트리거 포인트를 계산합니다. 공식은 다음과 같습니다: 다음 GC 주기가 한계를 초과할 경우 즉시 트리거합니다. 필요할 경우 GC 주기를 100% CPU로 작동하여 안정성과 처리량을 맞바꿀 수 있습니다.
import "runtime/debug" // 소프트 제한을 400 MiB로 설정 // 값은 바이트 단위입니다; 0은 제한을 비활성화합니다. debug.SetMemoryLimit(400 << 20) // 환경 변수 GOMEMLIMIT=400MiB를 통해 대안으로 설정
위기 우리의 데이터 처리 파이프라인은 대용량 CSV 파일을 소비하며 파싱 중 메모리를 600 MiB로 급증시켰습니다. 512 MiB 제한이 있는 Kubernetes에 배포되었을 때, 팟은 매 시간 OOMKilled 상태로 사망했습니다. 기본 GOGC는 제한된 환경에서 힙 비율이 너무 높아졌습니다.
해결책 1: 공격적인 GOGC 조정 우리는 GOGC=20을 설정하여 더 이른 수집을 강제하기로 고려했습니다. 이로 인해 최대 메모리가 약 480 MiB로 줄어들었습니다. 그러나 CPU 사용량은 리소스가 낮은 유휴 시간에도 지속적으로 10%에서 40%로 증가했습니다. 이는 불필요하게 리소스를 낭비하고 대기 시간을 저하시켰습니다.
해결책 2: 수동 GC 트리거 우리는 **runtime.ReadMemStats()**가 높은 할당을 보고할 때마다 **runtime.GC()**를 호출하는 메모리 감시기를 구현했습니다. 이것은 취약했습니다; 폴링 오버헤드가 필요했으며 갑작스러운 급증 동안 너무 늦게 트리거되거나, 너무 일찍 트리거되어 스래싱을 유발했습니다. 런타임이 제공할 수 있는 미세한 속도를 무시했습니다.
해결책 3: GOMEMLIMIT 통합 우리는 배포 매니페스트를 통해 GOMEMLIMIT=400MiB (스택 급증에 대한 여유 공간 남기기)를 설정했습니다. 런타임은 메모리가 증가함에 따라 GC 빈도를 자동으로 조절했습니다. 유휴 시간 동안 GC는 드물게 발생했고, CSV 파싱 중에는 수집이 거의 지속적으로 이루어졌지만 메모리를 400 MiB로 유지했습니다. 우리는 압박이 있는 경우에만 CPU 트레이드 오프를 수용했습니다.
결정 및 결과 우리는 수동 계측 없이 컨테이너 계약을 준수했기 때문에 해결책 3을 선택했습니다. 서비스는 안정화되었습니다: 30일 간 OOM 킬 없음. GC CPU 사용량은 평균 8%였으며(정적 GOGC의 경우 40%) 고강도 파싱 중에만 25%로 급증했으며 이는 얻은 신뢰성에 대해 수용 가능한 수준이었습니다.
GOMEMLIMIT는 계산에서 고루틴 스택 메모리를 어떻게 고려합니까?
많은 이들이 GOMEMLIMIT가 오로지 힙 객체만 추적한다고 가정합니다. 실제로 한계는 Go 런타임이 매핑하는 모든 메모리(힙, 고루틴 스택, 런타임 메타데이터 및 CGO 할당)를 포함합니다. 런타임은 주기적으로 sys 메트릭을 통해 사용 중인 메모리 추정치를 업데이트합니다. 수천 개의 고루틴이 동시에 스택을 성장시키면, 이는 한도에 포함되어 GC를 발생시킬 수 있습니다. 후보들은 이것이 "총 메모리" 한계라는 점을 놓칩니다; 힙 전용이 아닙니다.
라이브 힙이 GOMEMLIMIT를 영구적으로 초과하면 할당 대기 시간은 어떻게 됩니까?
후보자들은 흔히 GOMEMLIMIT가 할당을 차단하는 하드 한계처럼 작용한다고 믿습니다. 사실 이는 소프트 목표입니다. GC 주기 이후 라이브 힙이 이미 한계를 초과하면(예: 거대한 피할 수 없는 데이터 세트를 로드하는 경우), 런타임은 다음 GC 트리거를 현재 힙 크기와 동일하게 설정하여 모든 할당시 GC가 실행됩니다. 이런 "GC 스래싱"은 처리량보다 생명 유지에 우선합니다. 프로그램은 극적으로 느려지지만 한계 자체로 인해 패닉에 빠지거나 크래시하지 않습니다; OS 한계에 도달하면 여전히 OOM이 발생할 수 있지만, GOMEMLIMIT는 최대 회수 노력을 기울여 이를 방지하려고 합니다.
GOMEMLIMIT가 메모리 사용량이 한계 아래로 보일 때도 성능 저하를 유발할 수 있는 이유는 무엇입니까?
이는 스캐빈저와 속도 조정 휴리스틱과 관련이 있습니다. 한계에 근접하면 런타임은 GC를 더 자주 실행할 뿐만 아니라 MADV_DONTNEED를 통해 OS에 물리적 메모리를 더 공격적으로 반환합니다. 애플리케이션에 톱니 모양 할당 패턴이 있을 때(급증 후 유휴 상태), 스캐빈저가 페이지를 해제할 수 있으며, 다음 급증 시 이를 다시 가져오게 됩니다. 이러한 "페이지 폴트 폭풍"은 대기 시간 급증으로 나타납니다. 후보들은 GOMEMLIMIT가 GOGC와 상호 작용하여 최소 트리거 계산을 가지며, 한계는 GC 빈도의 바닥을 설정하여 메모리가 안전해 보일 때도 GOGC를 무시할 수 있음을 놓칩니다.