Когда из-за постоянных выделений и освобождений свободное место дробится на мелкие куски, процесс занимает намного больше памяти, чем реально использует.
Почему Много потоков долго выделяют и освобождают блоки памяти разного размера → Следствие Свободное место раздроблено, вернуть его ОС нельзя, и потребление растёт, как при утечке → На экране Чем дольше работает сервер, тем сильнее он тормозит из-за свопа и нехватки памяти, а затем принудительно завершается
Основной ответственный Команда разработки · Разработка сервера
Команда разработки: задачи
Завести пулы памяти по размерам блоков, перейти на аллокатор, устойчивый к фрагментации (jemalloc, mimalloc и др.).
На графике
Плавный рост · память процесса (RSS)
Где смотреть
Запустить два сервера одной сборки, на одном уменьшить число арен glibc переменной окружения MALLOC_ARENA_MAX или заменить аллокатор (например, на jemalloc) и несколько дней сравнивать RSS в pidstat -r
Подтверждает
При сопоставимом онлайне и числе объектов рост RSS останавливается или заметно замедляется только на изменённом сервере
Опровергает
Если и с другим аллокатором память растёт так же, это память, которую не освобождают (mem-leak)
Чем проверить
Инструменты инфраструктуры (игровой код не нужен)
Подробнее
Внешне это выглядит как утечка, но анализ кучи места утечки не покажет. Со стандартным аллокатором Linux (glibc) на серверах с большим числом потоков фрагментация особенно сильна, и одна только замена аллокатора иногда заметно снижает потребление.
Источники
mallopt(3) — Linux manual pageLinux man-pages Чтобы потоки меньше конкурировали, malloc в glibc создаёт арены, число которых может доходить до кратного числу CPU, и чем больше арен, тем больше потребление памяти (ограничивается M_ARENA_MAX, задаётся и переменной окружения MALLOC_ARENA_MAX)
jemalloc memory allocatorjemalloc Универсальная реализация malloc, рассчитанная на защиту от фрагментации и масштабирование при параллельной работе