Балласт памяти в Go или как полюбить кучу

Крайне занимательная статья о том, как в Twitch одним маленьким изменением добились снижения потребления CPU на фронтовых серверах на ~30% и уменьшили 99-й перцентиль времени ответа API на ~45%.

Их приложение страдало от пиков нагрузки, в остальное время работало стабильно. При нагрузке API latency сильно деградировало. Очевидной идеей было держать дополнительные мощности, но стоимость кусалась.

Потыкав pprof-ом, они выяснили, что при нагрузках огромное потребление приходится на garbage collector. Происходило множество триггеров GC (8-10 в секунду) и выделений памяти, поэтому сборщик мусора пожирал те самые ~30% CPU.

⭐️ Интересные идеи

➡️ Простое решение: выделили балласт на 10 GiB RAM для каждого пода. Сборщик мусора при каждом вызове удваивает память, поэтому следующий вызов увеличит кучу до 20 GiB, чего хватит надолго.

➡️ Балласт не убивается GC, потому что на него висит постоянный референс из main.

➡️ Балласт не потребляет столько памяти на самом деле, потому что в *nix-системах память адресуется виртуально и маппится только при реальном обращении к ней. Поэтому балласт фактически занимает место только в виртуальном адресном пространстве программы.

➡️ Решение привело к уменьшению циклов GC на 99% (до 2 в минуту) и снижению потребления CPU на те самые ~30%. Ну и отказоустойчивость, конечно, повысилась.

Приятного чтения!

// Понравился пост? Ставь 💛
// Есть классный материал? Пришли ссылку в комментах

#programming@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
📝 @tech_fit