Palworld: чрезмерное потребление памяти сервером

MAATRIX GAMES

Сервер Palworld запускался на 6-8 ГБ и первую неделю жил спокойно, а через месяц активной стройки RAM забита под завязку, и процесс то и дело падает по OOM без внятной строки в логе — знакомая картина почти для любого админа Palworld-сервера. Это не баг конкретно вашей сборки и не кривые руки — это известная особенность движка, с которой можно и нужно работать, а не бороться героическим "докупить ещё RAM". Разберём, откуда растёт потребление памяти, как настроить автоматический рестарт как рабочий обходной путь, и как реально следить за процессом, а не гадать по ощущениям.

Почему память вообще растёт: что происходит внутри процесса

Palworld построен на Unreal Engine, и у долгоживущих серверов на UE есть общая черта — со временем накапливается фрагментация памяти и растёт объём данных, которые движок держит активными в рантайме, даже если формально их можно было бы выгрузить. Это не классическая "утечка памяти" в смысле забытого free() в коде — скорее постепенное разрастание рабочего набора данных сервера, которое усугубляется спецификой именно Palworld как игры.

Три источника, которые дают основной вклад:

• Размер мира и история сохранений. Каждая построенная стена, каждый сундук, каждый заспавненный ресурс на карте — это объект, который сервер держит в памяти постоянно, пока игрок не снесёт постройку или не покинет регион надолго. Мир только растёт, редко уменьшается сам по себе.
• Количество активных палов. Каждый пал на базе или в мире — это ИИ-агент, который постоянно что-то считает: путь до цели, состояние задачи, анимации, взаимодействие с другими палами. Это не просто память под данные, а ещё и постоянная нагрузка на CPU, которая растёт нелинейно с числом палов.
• Накопление состояния между сессиями. Сервер, который не перезапускался неделями, копит в рантайме мелкий мусор — кэши, устаревшие ссылки на объекты, которые уже не нужны игре, но формально ещё не подчищены сборщиком мусора движка. По отдельности это копейки, за месяц — уже гигабайты.

Официально Pocketpair не публиковали подробный технический разбор причин роста памяти на длинной дистанции, так что дальше — не измеренные цифры, а практика админов, которые держат такие серверы месяцами: заметный рост памяти на активно застроенном сервере за 2-3 недели без рестарта — обычное дело, это стоит закладывать в планирование VPS сразу.

Как быстро распознать проблему, а не спутать её с чем-то другим

Прежде чем городить обходные пути, стоит убедиться, что дело именно в постепенном росте, а не в разовом всплеске от конкретного действия игрока. Разница простая: постепенный рост памяти — линейный график, который ползёт вверх часами и днями. Разовый скачок — резкий рывок за секунды, обычно привязанный к конкретному событию (массовый спавн, крупная стройка, генерация нового региона карты).

Смотрим потребление в реальном времени:

htop

Ищем процесс PalServer-Linux-Shipping или PalServer.sh в списке, смотрим колонку RES (резидентная память — то, что реально занято в RAM, а не виртуальный лимит) и %MEM. Если хотите зафиксировать динамику без постоянного присутствия за терминалом — снимайте показания раз в час скриптом и пишите в файл:

#!/bin/bash
# palworld-mem-log.sh
ts=$(date '+%Y-%m-%d %H:%M:%S')
mem=$(ps -o rss= -C PalServer-Linux-Shipping)
echo "$ts;$mem KB" >> /home/palworld/mem-usage.log

Добавьте команду в cron раз в час — через пару недель у вас будет реальный график роста именно вашей сборки, а не чужие бенчмарки: у каждого сервера свой набор модов, размер карты и темп стройки, универсального "через N дней память кончится" не существует.

Резкий скачок за секунды, а не плавный рост — отдельная проблема: ищите конкретное событие (массовая постройка, спавн существ через админ-команду, загрузка тяжёлого сейва), плановый рестарт её не лечит.

Настройка автоматического рестарта как рабочего обходного пути

Раз утечку на уровне движка вы не почините (это задача Pocketpair, а не ваша), логичный практический ответ — не дать памяти дорасти до OOM-килла, перезапуская процесс по расписанию раньше, чем это случится само. Причём делать это нужно аккуратно — не просто kill, а с корректным сохранением мира.

Схема на systemd + cron, аналогичная той, что применяется для других игровых серверов (подробный разбор общего подхода — в статье про автоматический рестарт по расписанию).

Если у вас уже настроен systemd-юнит для Palworld (см. статью про подъём сервера Palworld с нуля), достаточно добавить задачу в crontab пользователя palworld:

crontab -e

0 5 * * * systemctl restart palworld.service

Это разово в сутки, в 5 утра по времени сервера — время выбирайте по своей аудитории, для международного сервера с игроками из разных часовых поясов найти по-настоящему "тихое" окно бывает сложно, тогда берите наименее загруженный слот по факту, а не теоретически идеальный.

Для более мягкого рестарта, с предупреждением игроков через RCON перед остановкой (если включён RCON в PalWorldSettings.ini через RCONEnabled=True), можно обернуть в небольшой shell-скрипт:

#!/bin/bash
# palworld-graceful-restart.sh
RCON_PASS="ваш_admin_password"
RCON_PORT=25575

# предупреждение за 5 минут
rcon -a 127.0.0.1:$RCON_PORT -p "$RCON_PASS" "Broadcast Сервер перезапустится через 5 минут, сохраните прогресс"
sleep 300
rcon -a 127.0.0.1:$RCON_PORT -p "$RCON_PASS" "Save"
sleep 10
systemctl restart palworld.service

Опирается на консольную утилиту rcon (реализаций под Linux несколько, любая рабочая подойдёт) и команду Save, которая форсирует сохранение мира перед остановкой — без неё последние минуты прогресса игроков могут потеряться, если рестарт попадёт между автосейвами.

Частота рестарта — вопрос эмпирики конкретно вашего сервера по графику из предыдущего пункта: медленный рост к лимиту через 3 недели — хватит рестарта раз в 2-3 дня, быстрый рост при активной стройке — логичнее два раза в сутки в наименее загруженные часы.

Уменьшение лимита палов на базу как второй рычаг

Плановый рестарт лечит симптом на время между перезапусками, но не снижает базовое потребление памяти внутри одной сессии. Второй рычаг — прямо ограничить то, что растит потребление быстрее всего: количество палов на базах.

В PalWorldSettings.ini (путь: ~/palworld-server/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini) за это отвечает параметр внутри строки OptionSettings=(...):

BaseCampWorkerMaxNum=15

Это дефолтное значение — максимум палов-работников на одной базе. Снижение этого числа прямо уменьшает количество одновременно активных ИИ-агентов, которых серверу нужно постоянно просчитывать и держать в памяти. На практике:

Это ориентировочная зависимость, а не измеренный бенчмарк — точный выигрыш в мегабайтах зависит от числа баз на карте и от того, сколько игроков строят активно. Логика простая: меньше одновременно активных палов — меньше объектов ИИ в памяти в любой момент времени.

Дополнительно можно снизить PalSpawnNumRate (например, до 0.8 вместо дефолтного 1.0) — это уменьшает плотность спавна диких существ вне баз игроков и слегка снижает фоновую нагрузку.

Обе настройки требуют перезапуска сервера — совместите изменение конфига с ближайшим плановым рестартом, чтобы не гонять сервер лишний раз.

Другие практические рычаги снижения потребления

Помимо двух основных мер, есть менее очевидные, но рабочие способы притормозить рост памяти:

• Чистка старых построек. Заброшенные базы игроков, которые давно не заходили, продолжают занимать память так же, как активные. На публичном сервере с текучкой периодически проверяйте список баз и сносите явно заброшенные — это ручная операция, автоматизации из коробки нет.
• Ограничение дальности прогрузки. Более широкая зона прогрузки вокруг игроков означает больше активных объектов в памяти одновременно. Точный параметр может отличаться от версии к версии — проверяйте актуальный список опций в сгенерированном конфиге вашего билда.
• Разделение большого сервера на несколько поменьше. Если сообщество растёт и один мир упирается в память даже после оптимизаций — иногда практичнее развернуть второй сервер под отдельную группу, чем бесконечно наращивать RAM под один процесс.
• Своевременные обновления сервера. Pocketpair регулярно выпускают патчи, часть из них включает оптимизации памяти движка — держать сервер на актуальной версии (SteamCMD с app_update) иногда даёт больше эффекта, чем ручная настройка.

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

Мониторинг памяти на постоянной основе

Разовая проверка через htop — это диагностика конкретного инцидента, а для долгосрочной картины нужен постоянный мониторинг, который сам просигналит, когда потребление приближается к опасной черте, а не когда сервер уже упал.

Минимальный вариант — systemd-таймер, который проверяет память процесса и шлёт уведомление при превышении порога:

#!/bin/bash
# palworld-mem-check.sh
THRESHOLD_KB=7000000  # 7 ГБ, подстройте под свой лимит RAM
mem=$(ps -o rss= -C PalServer-Linux-Shipping | tr -d ' ')

if [ "$mem" -gt "$THRESHOLD_KB" ]; then
    echo "Palworld server memory usage high: $((mem / 1024)) MB" | \
    curl -s -X POST -H 'Content-Type: application/json' \
    -d "{\"text\":\"⚠️ Palworld сервер: память $((mem / 1024)) МБ, приближается к лимиту\"}" \
    "https://ваш-webhook-url"
fi

Webhook подставьте под свой канал уведомлений (Discord, Telegram, Slack — у всех похожий формат POST-запроса с JSON). Добавьте в cron раз в 30-60 минут, чтобы ловить тренд заранее, а не постфактум.

Более системный подход к ресурсному мониторингу разобран отдельно в статье про uptime-мониторинг игрового сервера: там же про то, как отличить "сервер жив, но тормозит" от "сервер реально упал".

Если сервер настроен через systemd-юнит, дополнительно смотрите journal:

journalctl -u palworld -f

Здесь видны все рестарты, включая аварийные по Restart=on-failure — частые незапланированные рестарты между окнами cron сигналят, что текущей частоты планового рестарта уже не хватает.

Выбор VPS с запасом под рост памяти

Не арендуйте сервер впритык под текущее потребление — закладывайте запас под естественный рост за недели активной игры, который мы разобрали выше.

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

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