GC, memori & GOMAXPROCS di container

Runtime Go tidak tahu batas memori container-mu kecuali diberi tahu. Akibatnya, garbage collector bisa membiarkan heap tumbuh melewati batas cgroup — dan yang terjadi bukan GC, melainkan container yang dibunuh kernel.

Bagaimana GC Go memutuskan kapan berjalan

GOGC=100 (default):
  Setelah GC, heap hidup = 100 MB
  → GC berikutnya saat heap mencapai 200 MB   (tumbuh 100%)

GOGC=50:
  → GC berikutnya saat heap mencapai 150 MB   (lebih sering, CPU lebih tinggi,
                                                memori puncak lebih rendah)
GOGC=200:
  → GC berikutnya saat heap mencapai 300 MB   (lebih jarang, CPU lebih rendah,
                                                memori puncak lebih tinggi)

GOMEMLIMIT: pencegah OOM kill

Tanpa GOMEMLIMIT, container 512 MB:

  heap hidup 200 MB → GC menunggu sampai 400 MB
  + stack goroutine + buffer + runtime  ≈ 520 MB
  → kernel membunuh container (exit 137), tanpa satu pun log dari aplikasimu

Dengan GOMEMLIMIT=400MiB:

  saat total mendekati 400 MB, GC berjalan LEBIH AGRESIF
  → memori tertahan di bawah batas
  → aplikasi jadi lebih lambat, tapi TETAP HIDUP

// Bisa disetel dari kode, dihitung dari batas container.
import "runtime/debug"

func setelBatasMemori(batasContainerByte int64) {
	debug.SetMemoryLimit(batasContainerByte * 80 / 100)
}

// Atau lewat environment di task definition ECS
"environment": [
  { "name": "GOMEMLIMIT", "value": "400MiB" }
]
// dengan "memory": 512 pada container definition

GOMAXPROCS dan container

Sebelum Go 1.25, Fargate task dengan 0,5 vCPU di host 64-core:

  GOMAXPROCS = 64
  → runtime menjadwalkan 64 goroutine berjalan bersamaan
  → cgroup hanya memberi 0,5 CPU
  → CPU throttling parah, latensi ekor melonjak

Sejak Go 1.25:

  GOMAXPROCS dibaca dari batas CPU cgroup → 1
  → penjadwalan sesuai kapasitas sungguhan

// Memeriksa nilai efektifnya saat startup
log.Info("runtime",
	"gomaxprocs", runtime.GOMAXPROCS(0),
	"num_cpu", runtime.NumCPU(),
	"gomemlimit", debug.SetMemoryLimit(-1),   // -1 = hanya membaca
	"gogc", os.Getenv("GOGC"))

Green Tea GC (Go 1.26)

Go 1.26 menjadikan Green Tea sebagai garbage collector bawaan, setelah setahun tersedia sebagai eksperimen. Ia meningkatkan lokalitas saat menandai objek kecil dan memakai instruksi vektor pada CPU amd64 yang lebih baru.

Memantau memori

go func() {
	for range time.Tick(30 * time.Second) {
		var m runtime.MemStats
		runtime.ReadMemStats(&m)

		metrik.Gauge("go.heap_alloc_bytes", float64(m.HeapAlloc))
		metrik.Gauge("go.heap_sys_bytes", float64(m.HeapSys))
		metrik.Gauge("go.gc_pause_total_ns", float64(m.PauseTotalNs))
		metrik.Gauge("go.num_gc", float64(m.NumGC))
		metrik.Gauge("go.goroutines", float64(runtime.NumGoroutine()))
	}
}()

Urutan yang benar saat memori bermasalah

1. Ambil profil heap — apa yang menahan memori sekarang?
2. Bandingkan dua profil berselang waktu — yang tumbuh itu kebocorannya.
3. Cek profil goroutine — goroutine bocor menahan seluruh stack-nya.
4. Kurangi alokasi di jalur terpanas (Fase 8).
5. Setel GOMEMLIMIT supaya lonjakan tidak jadi OOM kill.
6. Baru pertimbangkan menaikkan memori task.