$ mt simulate gctrace.log --gogc 50,100,200,400

GOGC	Heap (МБ) ?Целевой размер heap. Формула: liveHeap × (1 + GOGC/100). При GOGC=100 heap = 2× live.	Нагрузка CPU ?Дополнительные затраты CPU на GC в процентах. Растёт при снижении GOGC (GC запускается чаще).	Частота GC ?Относительная частота запусков GC. 1.0 = baseline. 0.5x = GC в 2 раза реже.	Пауза p99 (мс) ?99-й перцентиль STW паузы. Растёт с увеличением heap (больше объектов для сканирования).	Баланс

Потребление памяти

Нагрузка CPU

Риск задержки

$ mt tune --gogc 100

Как читать результаты

Потребление памяти

0–25%heap ≈ live heap, агрессивная сборка

25–50%heap ≈ 2× live — стандартный GOGC=100

50–75%heap ≈ 3× live — умеренная сборка

75–100%heap ≈ 4× live — ленивая сборка

Нагрузка CPU

0–25%<5% CPU — минимум затрат

25–50%5–10% CPU — умеренная нагрузка

50–75%10–15% CPU — высокая нагрузка

75–100%>15% CPU — критично, GC конкурирует с бизнес-логикой

Риск задержки

0–25%<0.5ms p99 — безопасно для latency-critical

25–50%0.5–1ms p99 — приемлемо для большинства сервисов

50–75%1–1.5ms p99 — заметны micro-spikes

75–100%>1.5ms p99 — риск SLA-нарушений

▾ Снижать GOGC — если критична память (heap слишком большой), но готовы платить CPU

▴ Повышать GOGC — если критичен CPU (GC мешает бизнес-логике), но.heap может вырасти

– GOMEMLIMIT — жёсткий потолок heap. Добавьте при значительном снижении GOGC для защиты от OOM

MT

Как читать результаты