Заканчивается память сервера — общий подход к диагностике

MAATRIX GAMES

Сервер падает по OOM, игроки жалуются на фризы раз в несколько часов, а в панели хостинга график RAM медленно ползёт вверх весь вечер — знакомая картина почти для любой игры, будь то Minecraft с горой модов, ARK с кластером карт или Rust с раздутой базой данных. Проблема в том, что "не хватает памяти" — это симптом, а не диагноз: за ним может стоять утечка в конкретном плагине, разовый пик от ивента с толпой игроков, или просто честный рост проекта, который перерос свой тариф. Ниже — методика, которая работает одинаково для любой игры: как отличить одно от другого и что делать в каждом случае, без гадания на кофейной гуще.

Шаг 1: посмотреть на цифры, а не на ощущения

Прежде чем что-то чинить, нужно понять, сколько памяти реально используется и куда она уходит. На Linux-сервере (а подавляющее большинство игровых серверов крутится именно на Linux, даже если сама игра винда-only внутри Wine/Proton) есть три базовых инструмента.

free -h

Даёт снимок на текущий момент: сколько всего RAM, сколько занято, сколько в буферах/кэше, сколько реально свободно (available, не free — это важное отличие, free почти всегда маленький, потому что Linux агрессивно кэширует диск, и это нормально).

htop

Интерактивный монитор процессов — сортируйте по Mem% (клавиша Shift+M), чтобы увидеть, какой именно процесс жрёт больше всего. Для игрового сервера это обычно сам процесс игры (java, srcds_run, RustDedicated, ArkAscendedServer.exe под Proton и т.д.), но иногда виноват соседний процесс — бэкап-скрипт, панель управления, мониторинг-агент.

watch -n 5 'free -h'

Обновляет вывод free каждые 5 секунд — удобно смотреть за динамикой вживую, пока сервер под нагрузкой (например, во время ивента или наплыва игроков).

Если у хостинга есть встроенный график потребления RAM за последние 24-72 часа (в MAATRIX GAMES такой график есть в панели каждого сервера) — начните с него, это экономит время: форма графика сразу подсказывает, утечка перед вами или пик.

Шаг 2: утечка или разовый пик — как отличить по графику

Это ключевая развилка всей диагностики, потому что решения для утечки и для пика — разные.

Признаки утечки памяти:

• график RAM растёт монотонно, без просадок, на протяжении часов или дней;
• рестарт процесса сразу возвращает потребление к базовому уровню — и цикл роста начинается заново;
• рост не коррелирует с онлайном игроков — память растёт даже ночью, когда на сервере никого нет;
• чем дольше сервер живёт без рестарта, тем ближе он к OOM.

Признаки разового пика:

• скачок RAM привязан к конкретному событию — заход большого числа игроков одновременно, генерация нового чанка/региона карты, крафт/спавн тяжёлого объекта, ивент с боссом или массовым PvP;
• после пика память либо сама снижается (garbage collector отработал), либо остаётся на новом уровне, но дальше не растёт — то есть это новое плато, а не тренд;
• проблема воспроизводится в конкретное время (вечер пятницы, старт сезона) и не проявляется в спокойные часы.

Если сомневаетесь — постройте график на неделю. Утечка на недельном масштабе выглядит как лестница или ровный подъём; пиковая нагрузка — как отдельные зубцы на фоне ровной базовой линии.

Шаг 3: диагностика утечки — сузить круг подозреваемых

Если это утечка, дальше нужно понять, где именно она происходит: в самом ядре игры, в модах/плагинах, или в стороннем процессе на сервере.

Практический метод — бинарный поиск по нагрузке:

1. Поднимите тестовый сервер (или временно отключите половину модов/плагинов на существующем, если можете себе это позволить в окно с низким онлайном) с минимальным набором — только ядро игры без сторонних дополнений.
2. Понаблюдайте за памятью 30-60 минут под похожей нагрузкой (можно самому побродить по серверу или использовать бота для симуляции активности, если игра это позволяет).
3. Если утечки нет — возвращайте моды/плагины пачками по 3-5 штук, каждый раз наблюдая за трендом RAM.
4. Как только утечка вернулась — сужайте пачку до одного подозреваемого.

Для игр на Java (Minecraft и производные на Forge/Fabric/Paper) это особенно эффективно, потому что там утечки чаще всего дают конкретные моды с плохо написанными кэшами сущностей или незакрытыми listener'ами — подробнее про поиск конфликтующего мода можно почитать в статье про конфликт плагина с модом, методика поиска там пересекается с этой.

Дополнительно проверьте логи на характерные сообщения:

• Java: OutOfMemoryError, GC overhead limit exceeded в логе краша или консоли;
• generic Linux: dmesg | grep -i "killed process" покажет, убивал ли OOM Killer процесс и с каким PID — по логам сервера можно сопоставить время убийства с временем последнего рестарта.

dmesg -T | grep -i oom

Флаг -T выводит человекочитаемое время вместо секунд с загрузки — так проще сопоставить с логами игры.

Шаг 4: диагностика пика — считать реальную потребность

Если проблема в пиках, задача другая — понять, укладывается ли пиковая потребность в лимит тарифа с запасом, или сервер балансирует на грани постоянно.

Ориентировочно: если пиковое потребление регулярно превышает 85-90% от выделенной RAM, это уже не запас, а систематический риск OOM при малейшем дополнительном скачке (например, обновление игры, которое на старте требует чуть больше памяти на прогрев кэшей). Точные цифры зависят от игры и конфигурации — не существует универсального "безопасного" процента, но подход "меньше 90% на пике" — разумный ориентир, а не измеренный факт.

Что обычно провоцирует пики:

• Minecraft — генерация новых чанков при исследовании карты, особенно с модами, добавляющими новые измерения или биомы (world generation держит в памяти сгенерированные, но ещё не выгруженные чанки);
• ARK/Rust — одновременный вход большого числа игроков после рестарта или вайпа, когда сервер загружает данные всех подключившихся сразу;
• FiveM — скрипты, которые кэшируют данные по каждому онлайн-игроку без выгрузки при дисконнекте.

Если пики предсказуемы (например, вы знаете расписание ивента), временное решение — заранее увеличить тариф на этот период, если хостинг это позволяет, а после ивента вернуться к базовому.

Шаг 5: swap как временная мера — и её реальные границы

Swap (подкачка на диск) не решает нехватку RAM — она просто отодвигает момент OOM, платя за это скоростью. Для игрового сервера, где важна отзывчивость в реальном времени, активное использование swap означает лаги и просадки тикрейта, потому что диск на порядки медленнее оперативной памяти даже на NVMe.

Тем не менее swap полезен как страховка от жёсткого краша, пока вы разбираетесь с истинной причиной. Проверить текущий swap:

swapon --show
free -h

Если swap не настроен, добавить временный swap-файл (пример на 2 ГБ, требует root-доступа):

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

Чтобы swap выжил перезагрузку, добавьте строку в /etc/fstab:

/swapfile none swap sw 0 0

Настройте параметр vm.swappiness — он определяет, насколько агрессивно ядро уходит в swap до того, как исчерпает RAM полностью. Для игрового сервера имеет смысл снизить значение по умолчанию (обычно 60) до 10, чтобы swap использовался только как последний рубеж, а не постоянно:

sysctl vm.swappiness=10
echo "vm.swappiness=10" >> /etc/sysctl.conf

Важно: если у вас VPS с ограничением дискового пространства или тариф с NVMe-хранилищем небольшого объёма, лишний swap-файл может съесть место, нужное под мир/сохранения. Проверяйте df -h перед созданием swap-файла.

Если хостинг работает в контейнерах (LXC/Docker) без прямого доступа к ядру хоста, swap может быть недоступен вообще или настраиваться только на стороне провайдера — уточните это в панели или у поддержки, прежде чем тратить время на команды выше.

Шаг 6: когда пора увеличивать тариф, а не бороться с симптомом

После утечки-фикса или анализа пиков наступает момент честного решения: чинить дальше или расти. Вот признаки, что дело не в конфигурации, а в том, что проект перерос текущий RAM:

• вы уже прошли бинарный поиск, отключили все подозрительные моды/плагины по одному — а базовое потребление всё равно близко к лимиту даже без них;
• онлайн игроков стабильно вырос (новый сезон, реклама, вайп привлёк аудиторию) — и это постоянный, а не временный фактор;
• количество контента на сервере (сохранённые чанки, база данных экономики, количество построек/баз) органически растёт и не будет уменьшаться;
• swap используется не эпизодически, а постоянно, даже вне пиков — по free -h видно ненулевой Swap used в спокойные часы.

Примерные ориентиры по RAM для базового старта (это именно ориентир, не гарантия — конкретная цифра зависит от версии игры, количества модов и онлайна):

Актуальный список игр и рекомендованных ресурсов по каждой — в каталоге на games.maatrix.io, там цифры подобраны под конкретную сборку.

Если вы регулярно сталкиваетесь с той или иной игрой, у нас есть отдельные разборы конкретных случаев: для Minecraft — статья про низкий TPS и лаги, для выживалок с ростом потребления памяти во времени — переполнение памяти в Project Zomboid и чрезмерное потребление памяти в Palworld — там разобраны игро-специфичные причины, которые дополняют общий подход из этой статьи. Если проблема шире, чем память — общая методика мониторинга TPS и лагов описана в статье про мониторинг TPS и лагов.

Частые вопросы