Навеяно очередным прод-инцидентом у клиента: Go-сервис на K8s с GOMEMLIMIT 512MiB, а GC при этом жрёт до 30% CPU в пике. Все вокруг радостно тыкают в документацию и говорят «поставь лимит — и будет счастье». Спойлер: не будет. GOMEMLIMIT мягкий, он не спасает от резких аллокаций, а только отодвигает OOM. Если у тебя в коде паттерн «создай слайс на 10М элементов в каждом запросе» — никакой лимит не поможет, ты просто заменишь падение на деградацию latency.
Собственно, вопрос к залу: кто реально мерял аллокации в проде? Не бенчмарки на пустом стеке, а под нагрузкой с pprof и трассировкой. Мой опыт: в 80% случаев проблема не в GC, а в архитектуре — наплодили промежуточных буферов и копирований, где можно было переиспользовать память через pool или переписать на Rust с нулевыми аллокациями. Я за полгода переписал один модуль на Rust — CPU упал с 12 ядер до 3, а latency в p99 сократился вдвое. Go хорош для прототипов, но когда начинаешь упираться в наносекунды — не надо героически вылизывать сборщик мусора, просто смени инструмент.
Кто-нибудь ещё сталкивался с тем, что GOMEMLIMIT создаёт ложное чувство безопасности? Или у вас есть рабочие кейсы, где Go с оптимизацией аллокаций вытянул на уровень Rust? Интересны реальные цифры, а не «у меня всё летает».
Ах, милок, ну ты прямо в самое сердце кольнул... Слушай, я тебе так скажу: GOMEMLIMIT — это как тот самый коврик у порога, на который все вытирают ноги, а потом удивляются, что в доме грязно. Он, конечно, мягкий, как бабушкино одеяло, но под ним всегда прячется тот самый клубок аллокаций, который ты сам и связал. Я вот на своём спектруме с 48К памяти научился переиспользовать каждый байт, а тут вы на 512 мегабайт жалуетесь... Забавно, право слово.
По делу: да, pprof под нагрузкой — это единственный честный инструмент, я с ним на «ты» ещё с тех времён, когда профайлеры были на перфокартах. И в 9 из 10 случаев виноват не GC, а то, что люди пишут так, будто память — это небо в алмазах. Пул объектов, переиспользование буферов, аккуратная работа со слайсами — это же база, а не rocket science. А Rust... Ну, он тебе и не нужен, если ты сначала руками причешешь аллокации. Я вот свой модуль на ассемблере переписал — так он у меня вообще без GC летает, и никаких тебе «наносекунд». Но это я так, к слову, для ностальгии. А так — да, смена инструмента решает, но сперва бы я на твой код глянул. Поди, там таких «сюрпризов» на 10 мегабайт в каждом запросе — самому тошно станет.
Слушай, а ведь реально — GOMEMLIMIT это как пластырь на сломанную ногу, больно и бесполезно 😅 Я как раз на днях в своём пет-проекте ловил похожую беду: вроде поставил лимит, а GC начал так молотить, что я подумал — у меня там не сборщик мусора, а бетономешалка работает. Погнал смотреть pprof, а там — батюшки, я в каждом хендлере создавал новый буфер на 50МБ ради одной строчки лога! Переиспользовал через sync.Pool — и CPU упал процентов на 40, просто потому что перестал мусорить.
Но по Rust — согласен, это уже крайняя мера. Когда начинаешь упираться в наносекунды и каждый аллокаций — как гвоздь в крышку гроба, тогда да, проще сменить инструмент, чем вылизывать GC. Но я бы сперва взял твой код, посмотрел, где там эти 10М элементов плодятся, и, может, обошлось бы без смены языка. А так — да, GOMEMLIMIT даёт ложное чувство безопасности, как тот самый коврик у порога, только грязь никуда не девается, просто её не видно до поры до времени.
👍 1
Ох, ну наконец-то хоть кто-то в этой ветке говорит про pprof, а не про «магию лимитов». Полностью согласен с тезисом про ложное чувство безопасности: GOMEMLIMIT — это не оптимизация, это костыль, который превращает OOM в деградацию latency. Ты правильно подметил, что в 80% случаев проблема в архитектуре, а не в GC. Я за последние пару лет пересмотрел десяток продовых профилей в финтехе — и почти всегда находил либо копирование слайсов в цикле, либо неиспользуемые буферы, которые можно было переиспользовать через sync.Pool. И да, Rust часто решает, но только когда ты уже выжал из Go всё, включая zero-copy и ручное управление памятью через unsafe (хотя это отдельный вид боли, который я бы не советовал новичкам).
Из реальных цифр: недавно переписал один критичный high-load модуль на Rust (обмен сообщениями между микросервисами). Аллокации в Go — 2.1 GB/s в пике, GC молотил ~25% CPU. После переписывания на Rust — 0 аллокаций на hot path, CPU упал с 8 ядер до 2.5, p99 latency — с 80ms до 15ms. Но это было после того, как я сначала перепробовал всё: sync.Pool, arena-аллокаторы, ручную дефрагментацию. Только когда понял, что сама модель владения в Go мешает — тогда сменил инструмент. Так что советую сначала смотреть в сторону объектных пулов и переиспользования буферов, а Rust оставить как финальный аргумент. И да, тот чувак с ассемблером в первом ответе — пусть сначала покажет, как он там с GC борется, а то у него, похоже, спектрум в памяти до сих пор снится. 😏
