Производительность
GC: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — давление аллокаций, pacing, компромиссы коллекторов, барьеры и production-сбои.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в реальном инциденте — не определение для заучивания, а компромисс, который надо взвесить под нагрузкой.
Цель
Убедись, что связываешь давление аллокаций, выбор коллектора, ручки тюнинга и production-сбои — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
Сервис A держит кэш 4 ГБ и аллоцирует 50 МБ/с. Сервис B держит 100 МБ живых данных и аллоцирует 1 ГБ/с. Коллектор одинаковый. У кого больше GC-хвостовая задержка и почему?
Heads-up Стоимость маркировки масштабируется с живым набором, а стабильный кэш — это в основном устойчивые живые данные, собираемые редко. Здесь доминирует частота циклов, которую задаёт allocation rate.
Heads-up Коллектор тот же, но профили аллокаций совсем разные. Алгоритм задаёт форму паузы; allocation rate — как часто ты за неё платишь.
Heads-up Паузы GC — главный источник хвостовой задержки в аллокационно-тяжёлых сервисах; на этом построен весь юнит.
Викторина
Completed
Go-сервис в контейнере 4 ГБ спорадически убивается по OOM на пиках трафика; GOGC по умолчанию 100. Какая первая ручка и что она реально делает?
Heads-up GOGC=50 триггерит GC при меньшем коэффициенте роста, но не задаёт потолок — достаточно большой всплеск всё равно нарастит кучу за лимит контейнера и вызовет OOM.
Heads-up GOGC=off полностью отключает пропорциональный триггер; куча только растёт. Это безопасно лишь для коротких batch-задач, которые завершаются, но не для долгоживущего сервиса.
Heads-up ZGC — это коллектор JVM; здесь Go. Корневая причина — отсутствие мягкого лимита памяти, а не алгоритм коллектора.
Викторина
Completed
После миграции с G1 на (негенерационный) ZGC паузы упали с 60 мс до <1 мс, но пропускная способность снизилась ~12%, а RSS вырос ~18%. Как это читать?
Heads-up Ни один коллектор не минимизирует паузу, пропускную способность и память одновременно. Эти числа — в пределах нормальных накладных негенерационного ZGC.
Heads-up Накладные барьеров напрямую облагают CPU-пропускную способность, а multi-mapping цветных указателей раздувает память. Оба определяются коллектором.
Heads-up Если нагрузка чувствительна к задержке на большой куче, обмен 12% пропускной способности на паузы в 60× меньше — часто и есть цель. Суди по SLO, а не по одному числу пропускной способности.
Викторина
Completed
Зачем конкурентному коллектору барьер записи и что ломается без него?
Heads-up Барьер добавляет накладные на каждую запись (2–10% CPU); он не распараллеливает маркировку. Его задача — корректность при конкурентной мутации, а не скорость.
Heads-up Уплотнение — отдельная фаза. Барьер записи — про то, чтобы не потерять живые объекты, когда мутатор перекоммутирует ссылки во время маркировки.
Heads-up Он нужен любому конкурентному коллектору, генерационному или нет — Go негенерационный и всё равно использует барьер записи.
Викторина
Completed
Java-сервис регистрирует Object.finalize() на обёртках файловых дескрипторов; под нагрузкой число открытых дескрипторов непредсказуемо скачет. Корневая причина?
Heads-up ОС выдаёт дескрипторы корректно; непосредственная причина — недетерминированное освобождение через тайминг финализатора.
Heads-up Размер кучи не управляет планированием потока финализаторов. Финализаторы — просто неверный механизм для детерминированного освобождения ресурсов.
Heads-up Они всё ещё собираются — но только после запуска их финализатора, и именно эта задержка удерживает дескрипторы.
Викторина
Completed
gctrace показывает рост GC CPU 1% → 39% за час, при этом время конкурентной маркировки растёт с 1.3 мс до ~350 мс. Что происходит и какой первый фикс?
Heads-up Здоровый сервис держит GC CPU под ~5%. Монотонный рост до 39% с растущим временем маркировки — патология, а не прогрев.
Heads-up Откладывание GC меняет память на меньшее число циклов и может загнать в OOM во время спирали; это маскирует причину. Сначала сократи аллокации, потом думай про тюнинг.
Heads-up Больше ядер отсрочат OOM, но спираль возобновится, так как давление аллокаций растёт с нагрузкой. Устойчивый фикс — меньше аллокаций.
Итог
Сквозная линия юнита — одно дерево решений: allocation rate задаёт частоту GC, живой набор задаёт стоимость цикла, коллектор задаёт форму паузы, а ручки (сначала GOMEMLIMIT, потом GOGC/цель по паузе, в последнюю очередь алгоритм) защищают границы. Все production-сбои — OOM на пиках, компромиссы ZGC, штормы финализаторов, death-spiral, allocation-DoS — сводятся к одному рычагу: сократи аллокации, прежде чем что-либо тюнить.