На машине с тем же объёмом данных увеличение GOMAXPROCS сократило длительность GC, но ухудшило задержки запросов. Каким механизмом это объясняется?
GOMAXPROCS задаёт верхнюю границу числа логических процессоров Go, на которых одновременно выполняются горутины и работа рантайма. При его увеличении сборщик мусора может выполнять параллельную маркировку быстрее, но начинает конкурировать с обработчиками запросов за CPU, поэтому общая задержка может вырасти.
Это не означает, что число GC-воркеров всегда строго равно GOMAXPROCS: фактический параллелизм зависит от фазы сборки, объёма работы, планировщика и доступного CPU.
Ранние подходы к сборке мусора сильнее останавливали выполнение пользовательского кода на время обхода объектов. Для серверных приложений это создавало длинные паузы, поэтому современный GC Go выполняет значительную часть маркировки конкурентно с программой.
Конкурентная работа требует CPU. Настройка параллелизма стала компромиссом между длительностью самого цикла GC и ресурсами, остающимися приложению.
Если GOMAXPROCS слишком мал, сборщик получает меньше возможностей для параллельной маркировки. Цикл может занимать больше времени, а при высокой скорости аллокаций приложение чаще будет выполнять работу GC через mark assist.
Если GOMAXPROCS слишком велик относительно CPU-квоты контейнера или нагрузки приложения, GC и обработчики запросов конкурируют за процессор. Это повышает планировочные накладные расходы, вытесняет полезную работу и может ухудшить p95 или p99 latency, даже если отдельный цикл GC завершается быстрее.
Во время конкурентной маркировки рантайм запускает GC-воркеры, которые обходят достижимые объекты и помечают их. Эти воркеры получают время выполнения через планировщик Go и используют доступные P, поэтому увеличение GOMAXPROCS обычно расширяет потенциальный параллелизм GC.
Однако ускорение не является линейным. Когда работы мало, дополнительные процессоры почти не помогают; когда память или пропускная способность подсистемы памяти становятся ограничением, добавление GC-воркеров только усиливает конкуренцию.
Пользовательские горутины тоже работают на тех же ресурсах. Поэтому увеличение GOMAXPROCS может сократить wall-clock время маркировки, но одновременно уменьшить CPU, доступный обработке запросов. Важны не только длительность GC-паузы, но и доля CPU, занятая GC, частота циклов и влияние на задержки приложения.
На коротких stop-the-world-фазах увеличение GOMAXPROCS не гарантирует пропорционального выигрыша: их длительность зависит от конкретной операции рантайма, синхронизации и состояния всех P. Кроме того, в контейнере нужно учитывать реальную CPU-квоту, а не только число процессоров хоста.
Практическое решение — измерять одновременно CPU профиля, метрики GC и распределение задержек. GOMAXPROCS следует подбирать нагрузочным тестом: цель состоит не в минимальном времени GC как таковом, а в приемлемом балансе между пропускной способностью, накладными расходами сборки и p99 latency.
Сервис обрабатывает запросы в контейнере с ограниченной CPU-квотой. После увеличения GOMAXPROCS маркировка стала завершаться быстрее, но p99 вырос: дополнительные GC-воркеры стали отбирать процессор у горутин, обслуживающих запросы.
Рассматривались два варианта. Оставить высокое значение было выгодно для длительности GC, но плохо для latency; уменьшить его снижало конкуренцию, однако увеличивало время маркировки и риск mark assist при пиковых аллокациях.
Выбранное значение определили нагрузочным тестом с контролем CPU-квоты, частоты GC, доли CPU GC и p99. В результате предпочли настройку, при которой GC занимал немного больше времени, но запросы получали стабильный процессорный ресурс; это дало лучший конечный результат для SLA.
Нет. GOMAXPROCS ограничивает доступный параллелизм выполнения Go-кода, но GC использует его с учётом текущей фазы и объёма работы. Влияние ограничивают отсутствие достаточного количества объектов для обхода, синхронизация, пропускная способность памяти и CPU-квота.
Время цикла — не единственная характеристика. GC-воркеры потребляют те же процессорные ресурсы, что и обработчики запросов, а планировщик дополнительно переключает и координирует горутины. Поэтому пользовательский код может получать меньше CPU в течение большего числа интервалов, что особенно заметно в хвосте распределения задержек.
Нужно сопоставить метрики. При недостаточном параллелизме обычно видны длительные циклы маркировки и признаки того, что приложение вынуждено помогать GC; при чрезмерной конкуренции растёт доля CPU, потребляемая GC, а задержки приложения ухудшаются при отсутствии соответствующего роста полезной пропускной способности.
Проверку проводят серией нагрузочных тестов с разными значениями GOMAXPROCS при неизменной CPU-квоте. Сравнивают не только паузы, но и CPU GC, аллокации, частоту mark assist, throughput и p95/p99 latency.