Если во время события создаётся масса временных объектов, GC запускается намного чаще обычного.
Почему Дроп предметов, боевые логи и награды события резко увеличивают число временных объектов → Следствие GC запускается в несколько раз чаще, объекты, которые не успели стать мусором, переходят в область Old, и Full GC тоже наступает раньше → На экране Короткие периодические подвисания только во время событий
Основной ответственный Команда разработки · Разработка сервера
Команда разработки: задачи
Завести пулы объектов и переиспользуемые буферы, профилировать аллокации.
На графике
Растёт вслед за онлайном и нагрузкой · число сборок GC, скорость аллокаций
Где смотреть
Считать число сборок GC в минуту по GC-логу (Java -Xlog:gc, Go GODEBUG=gctrace=1), для .NET смотреть объём аллокаций и число сборок в dotnet-counters (с .NET 9 dotnet.gc.heap.total_allocated и dotnet.gc.collections, в 8 и ниже Allocation Rate и Gen 0 GC Count). Накладывать на онлайн и время событий
Подтверждает
С началом события скорость аллокаций и число сборок растут быстрее онлайна, короткие паузы учащаются. После события всё возвращается к прежнему уровню
Опровергает
Если число сборок прежнее, а каждая пауза стала длиннее, вырос объём живых данных (mem-gc-thrash, mem-leak)
Чем проверить
Инструменты инфраструктуры (игровой код не нужен)
Источники
Garbage Collector ImplementationOracle Когда заполняется область Young, выполняется minor GC, часть выживших объектов переносится в область Old, а когда заполняется Old, собирается вся куча (намного дольше, чем minor). -Xlog:gc пишет по строке на каждый GC
dotnet-counters diagnostic tool.NET В .NET 9 и новее это dotnet.gc.heap.total_allocated и dotnet.gc.collections, в .NET 8 и ниже Allocation Rate и Gen 0 GC Count