Краткий ответ

Резкое увеличение порога поколения 0 обычно уменьшит частоту запусков сборщика циклических ссылок поколения 0. Это может снизить накладные расходы CPU, но одновременно увеличит объём временно удерживаемых объектов и отсрочит обнаружение циклов, поэтому пиковое потребление памяти может вырасти.

Порог поколения 0 не управляет подсчёком ссылок: обычные объекты без циклических ссылок по-прежнему освобождаются сразу после исчезновения последней сильной ссылки.

Исторический контекст

В CPython освобождение большинства объектов основано на подсчёте ссылок. Такой механизм хорошо подходит для объектов, которые быстро теряют последнюю ссылку, но не может самостоятельно освободить замкнутую группу объектов, ссылающихся друг на друга.

Для обнаружения таких циклов используется дополнительный циклический сборщик мусора. Поскольку полный поиск циклов после каждой аллокации был бы дорогим, сборщик применяет поколенческий подход: недавно созданные объекты проверяются чаще, а пережившие сборки объекты обычно проверяются реже.

Постановка проблемы

Если приложение создаёт много короткоживущих объектов, частые сборки поколения 0 могут заметно увеличивать загрузку CPU. Повышение порога снижает эту частоту, но откладывает проверку контейнеров, способных участвовать в циклах.

Неверно считать увеличение порога универсальной оптимизацией памяти. Оно не уменьшает размер объектов, не возвращает память операционной системе и может привести к более высокому пику потребления памяти до запуска сборщика.

Подробное решение

Порог поколения 0 задаёт условие, при котором CPython решает запустить очередную сборку самого молодого поколения. Упрощённо, чем больше разница между количеством выделений и освобождений отслеживаемых объектов, тем быстрее порог достигается.

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

Изменение порога влияет прежде всего на циклический GC, а не на подсчёт ссылок. Поэтому для кода, создающего только простые объекты без циклических ссылок, эффект может быть небольшим: такие объекты освобождаются подсчётом ссылок независимо от частоты циклических сборок.

Порог нельзя оценивать изолированно от других настроек GC и характера нагрузки. Слишком маленькое значение повышает CPU-накладные расходы, слишком большое может увеличить задержки сборки и пиковую память. Настройку следует подтверждать профилированием CPU и памяти на репрезентативной нагрузке, а не только микробенчмарком.

import gc

old = gc.get_threshold()
gc.set_threshold(100_000, old[1], old[2])
try:
    run_workload()
finally:
    gc.set_threshold(*old)

Здесь изменяется только порог поколения 0, а исходные настройки восстанавливаются после эксперимента. Такой тест показывает влияние настройки на конкретную нагрузку, но не доказывает, что большое значение безопасно для постоянного использования.

Ситуация из практики

В обработчике сообщений CPU был перегружен частыми сборками, потому что каждая задача создавала множество временных контейнеров. Рассматривались отключение GC, безусловное увеличение порога и изменение структуры данных.

Полное отключение GC снизило накладные расходы, но создало риск накопления циклических объектов. Безусловное увеличение порога дало похожий эффект, однако повысило пик памяти на длительных сериях задач. Изменение структуры данных уменьшило число циклических ссылок, но потребовало заметной переработки кода.

Выбрали умеренное увеличение порога поколения 0 вместе с контролируемым запуском полной сборки между независимыми этапами обработки. Это сохранило автоматическое обнаружение циклов и снизило частоту малых сборок; результат оценивали по CPU, задержкам и пику памяти, а не по одному показателю.

Что кандидаты часто упускают

Означает ли рост порога, что объекты без циклических ссылок будут жить дольше?

Обычно нет. В CPython объект без оставшихся сильных ссылок, как правило, освобождается механизмом подсчёта ссылок независимо от порога циклического GC. Рост порога главным образом откладывает обработку отслеживаемых контейнеров и поиск недостижимых циклов.
Почему увеличение порога может не снизить RSS процесса?

Даже если сборщик стал запускаться реже, освобождённые объекты могут оставаться внутри аллокаторов CPython или системного аллокатора для повторного использования процессом. Кроме того, более редкая сборка может временно удерживать больше циклического мусора. Поэтому изменение порога может уменьшить CPU-затраты, но не дать пропорционального уменьшения RSS.
Почему нельзя выбирать порог только по времени выполнения одного короткого теста?

Короткий тест может не создать длительно живущих циклов и не достичь режима, в котором проявляется рост удерживаемой памяти. На реальной нагрузке важны распределение времени жизни объектов, продолжительность работы процесса, частота циклов и требования к задержкам. Поэтому сравнивают несколько прогонов по CPU, пиковому потреблению памяти, задержкам и числу сборок; настройка, ускоряющая тест, но вызывающая рост памяти в долгом процессе, является плохим компромиссом.