Анатомия игровых лагов › L10 Память

Утечка памяти Memory leak

ID причины mem-leak · Основной ответственный Команда разработки · Разработка сервера · Совместно Команда инфраструктуры · Серверная инфраструктура

Открыть карточку в основной версии с иллюстрациями и экспериментами →

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

Почему Данные персонажей, вышедших из игры, и обработчики событий не освобождаются → Следствие Свободной памяти становится всё меньше в течение нескольких дней → На экране Сразу после техработ всё в порядке, с каждым днём лагает сильнее, в итоге сервер падает

Симптомы

Слоумо, Фриз, Дисконнект

Факторы

Остановка

У кого

Весь сервер

Когда

Чем дольше без перезапуска, Вечерний пик

Ответственные

Основной ответственный Команда разработки · Разработка сервера · Совместно Команда инфраструктуры · Серверная инфраструктура

Команда разработки: задачи

Анализировать дампы кучи, проводить длительные нагрузочные тесты.

Команда инфраструктуры: задачи

Отслеживать тренд потребления памяти по процессам, настроить алерты.

На графике

Плавный рост · память процесса (RSS), куча сразу после GC

Где смотреть

Смотреть память процесса игрового сервера (RSS в pidstat -r) на отрезке в несколько дней, а для сервера с GC смотреть, сколько кучи остаётся сразу после GC. В Java это значение после GC (строки -Xlog:gc показывают занятый объём до и после GC), в .NET размер кучи после GC в dotnet-counters (с .NET 9 dotnet.gc.last_collection.heap.size, в 8 и ниже GC Heap Size)

Подтверждает

Объём кучи сразу после GC (нижняя линия) после перезапуска растёт день ото дня и не опускается даже ночью при низком онлайне

Опровергает

Если нижняя линия кучи ровная, а растёт только RSS, дело во фрагментации (mem-fragment) или в нативной памяти. Если память растёт и падает вслед за онлайном, это нормальное потребление

Чем проверить

Инструменты инфраструктуры (игровой код не нужен)

Подробнее

Если сервер каждую неделю перезапускается на плановых техработах, утечка маскируется и долго остаётся незамеченной. Часто она внезапно проявляется, когда техработы один раз переносят или когда онлайн вырастает из-за события.

Источники

1. Troubleshoot Memory Leaks Oracle
   Если программа работает всё медленнее, стоит подозревать утечку, в итоге память кончается и процесс аварийно завершается. Главный материал для анализа утечки: дамп кучи
2. Debug a memory leak in .NET .NET
   Даже при наличии GC постоянные ссылки на ненужные объекты дают утечку, падение производительности и OutOfMemoryException. Проверка тренда памяти и анализ дампов
3. Garbage Collector Implementation Oracle
   Строка -Xlog:gc имеет формат «занято до GC->занято после GC(размер кучи)»
4. dotnet-counters diagnostic tool .NET
   В .NET 9 и новее это dotnet.gc.last_collection.heap.size, в .NET 8 и ниже GC Heap Size
5. pidstat(1) — Linux manual page sysstat
   -r: RSS каждого процесса (память, фактически находящаяся в RAM) и ошибки страниц (page faults)

Смотрите также

Тот же слой: L10 Память

• Полная пауза GC на сервере
• Паузы GC в скриптовом движке
• Лавина аллокаций
• Трешинг GC (мало свободного места в куче)
• Своп
• Промах кэша
• Фрагментация памяти
• Удалённая память NUMA

Причины с тем же симптомом (Слоумо) на других слоях

• Лавина догоняющих шагов при фиксированном таймстепе L1 Процесс игрового клиента
• Перекос балансировки и ошибки health check L5 Сетевое оборудование ЦОД
• Избыток потоков и переключение контекста L7 ОС сервера (ядро)
• Троттлинг CPU в контейнере (квота CFS) L7 ОС сервера (ядро)
• Всплески задержки из-за управления питанием сервера (C-state, управление частотой) L7 ОС сервера (ядро)
• Плановые задания L7 ОС сервера (ядро)
• Изменение производительности после обновления ОС, ядра, драйверов или прошивки L7 ОС сервера (ядро)
• Блокирующая отправка из-за медленного клиента L8 Сокеты и протоколы

Карточка в основной версии с иллюстрациями и экспериментами