В высоконагруженном Go-сервисе аллокации малых объектов не стали пропорционально медленнее после роста числа горутин. Как устройство аллокатора объясняет такую масштабируемость?
Аллокатор Go снижает конкуренцию за общий ресурс, используя локальные кэши памяти, привязанные к каждому P, а не к каждой горутине. Малые объекты обычно выдаются из локального mcache текущего P, поэтому большинство аллокаций не требует общей блокировки. Масштабирование ограничивается числом P, пополнением локальных кэшей, крупными объектами и дополнительной нагрузкой GC.
Единый глобальный аллокатор с общей блокировкой плохо подходит для высококонкурентных программ: множество горутин начинает ждать друг друга даже при коротких операциях выделения памяти. Runtime Go использует многоуровневую схему, чтобы частые малые аллокации выполнялись локально, а синхронизация требовалась только при обращении к общим структурам.
Такой подход решает прежде всего проблему конкуренции при выделении памяти. Он не отменяет стоимость самой аллокации, работы сборщика мусора или обращения к общим уровням аллокатора.
Если каждая аллокация обращается к общей куче, рост параллелизма приводит к блокировкам, ухудшению пропускной способности и росту задержек. Ошибочно считать, что увеличение числа горутин само по себе должно линейно ускорять или замедлять аллокации: выполнение горутин ограничено доступными P, а путь выделения зависит от размера и типа объекта.
Особенно заметны ограничения, когда локальный кэш нужно пополнять, выделяется крупный объект или приложение создаёт слишком много мусора. В этих случаях узким местом становится уже не только синхронизация аллокатора, но и пропускная способность памяти либо GC.
У каждого P есть локальный mcache. Для малых объектов он содержит доступные блоки памяти различных классов размеров; при выполнении горутины на этом P аллокатор обычно берёт очередной свободный блок из локального кэша. Поэтому обычный быстрый путь не требует обращения к общей структуре и не конкурирует с аллокацией на другом P.
Когда локальный запас заканчивается, runtime получает новый span через более общие уровни: mcentral, а затем при необходимости mheap. Эти операции дороже и могут требовать синхронизации. Крупные объекты также обходят обычный быстрый путь малых объектов и сильнее зависят от общих структур управления кучей.
Важно, что кэш принадлежит P, а не горутине. Десять тысяч горутин при небольшом GOMAXPROCS не создают десять тысяч независимых путей аллокации. Увеличение числа P может повысить параллелизм аллокаций, но одновременно увеличить общий объём локально удерживаемых ресурсов и нагрузку на GC.
Локализация аллокаций не означает отсутствия накладных расходов. Остаются вычисление класса размера, обслуживание span, запись метаданных, возможная работа write barrier и последующая обработка объектов сборщиком мусора. Поэтому производительность нужно оценивать по профилям CPU и аллокаций, а не только по числу горутин.
В сервисе обработки сообщений после увеличения числа параллельных обработчиков выросло число малых временных объектов. Вариант с глобальным пулом памяти уменьшал часть аллокаций, но добавлял собственные блокировки и усложнял жизненный цикл объектов; вариант с sync.Pool мог снизить повторные аллокации, но не гарантировал сохранность объектов между циклами GC и требовал проверки повторного использования.
Сначала следует проверить профиль аллокаций, GOMAXPROCS, долю крупных объектов и время, уходящее на GC. Если основная масса выделений уже проходит через локальные кэши аллокатора, ручная оптимизация пулом может не окупиться. Обоснованным решением будет уменьшить время жизни и количество временных объектов только в подтверждённых горячих путях, а не пытаться синхронизировать собственный глобальный allocator; результатом обычно становится снижение конкуренции без ухудшения управляемости памяти.
Почему рост числа горутин не равен росту числа независимых кэшей аллокатора?
Потому что локальный кэш привязан к P. В каждый момент на одном P выполняется не более одной горутины, поэтому множество горутин может последовательно использовать один и тот же mcache. Реальный параллелизм быстрого пути определяется доступными P, а не количеством созданных горутин.
Что происходит, когда локальный кэш P исчерпывается?
Runtime запрашивает новый span у более общих уровней аллокатора. Это требует дополнительной работы и потенциально увеличивает конкуренцию, особенно если многие P одновременно пополняют кэши. Поэтому локальный быстрый путь хорошо масштабируется, но не устраняет стоимость массового роста общей кучи.
Почему снижение времени аллокаций не обязательно означает ускорение приложения?
Быстрые аллокации всё равно создают объекты, которые нужно отслеживать и маркировать GC, если они достижимы во время сборки. При большом потоке короткоживущих объектов приложение может упереться в стоимость GC, кэш-промахи или пропускную способность памяти. Оценивать эффект нужно совместно по latency, CPU, объёму аллокаций и паузам либо assist-нагрузке GC.