Palworld: краш сервера при сохранении мира

MAATRIX GAMES

Сервер вроде бы стабильно держит онлайн, все палы бегают, лут капает — и вдруг в самый неподходящий момент процесс PalServer.sh вылетает, а в логах последнее, что видно — начало записи сейва. Знакомая история для тех, кто держит Palworld дольше пары недель: чем больше вырастает мир, тем выше шанс словить краш именно на автосохранении. Разбираем, почему это происходит и что с этим делать — от диагностики до восстановления из бэкапа.

Почему краш случается именно в момент сохранения

Сохранение мира в Palworld — самая тяжёлая операция, которую выполняет сервер за весь цикл своей работы. В отличие от обычного тика симуляции (посчитать позиции палов, применить урон, обновить погоду), запись сейва требует сериализовать в файл состояние буквально всего: координаты и статы каждого призванного пала, содержимое каждого сундука и базы, прогресс технологий каждого игрока, состояние построек. Чем дольше живёт мир и чем активнее в нём строят, тем это дороже по CPU и памяти.

Технически Palworld (как и большинство игр на Unreal Engine с собственной системой сохранений) не переписывает файл сейва на месте — он готовит новую версию данных в памяти, пишет её во временный файл и только потом атомарно подменяет старый сейв новым. Это защищает от половинчатой записи при обычном сбое, но у подхода есть цена: в момент сохранения в оперативной памяти на короткое время держится одновременно старое состояние мира (для симуляции, которая не останавливается) и новое, готовящееся к записи. На большом мире это может быть ощутимый скачок потребления RAM — именно поэтому крash так часто ловится не во время боя с боссом, а через секунду-две после лога Saving world... в консоли.

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

Нехватка памяти в момент записи

Самая частая причина. Официальный минимум Pocketpair — 16 ГБ RAM для комфортной игры компанией, но многие держат сервер и на 8 ГБ, пока мир небольшой. Проблема в том, что потребление памяти растёт не линейно от числа онлайн-игроков, а от накопленного размера мира: чем больше построек, палов и истории, тем тяжелее каждое сохранение — и тем выше пиковый расход RAM именно в момент записи.

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

dmesg | grep -i "out of memory"

Если там есть строка про Out of memory: Killed process с именем процесса PalServer-Linux-Shipping или похожим — это OOM Killer линукса, который принудительно убил процесс сервера, потому что памяти не хватило на всех. Это не баг игры, а закономерное поведение системы при исчерпании RAM.

Что делать:

• Смотреть текущее потребление в реальном времени: free -h и htop (или top) во время работы сервера, особенно в момент автосохранения.
• Снизить ServerPlayerMaxNum в PalWorldSettings.ini — каждый слот в теории увеличивает пиковую нагрузку, даже если он не занят активным игроком постоянно.
• Добавить swap-раздел как страховку (не решение проблемы, но смягчает резкие пики и превращает жёсткий краш в замедление):

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

• Если мир вырос за пределы возможностей текущего тарифа — честно апгрейдить VPS. Это самый надёжный вариант для сервера с активной стройкой на 8+ игроков, где 8-12 ГБ RAM уже не хватает.

Нехватка места на диске

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

Проверка свободного места:

df -h

Если раздел с игрой близок к 100% заполнения — это и есть причина. Отдельно стоит посмотреть, сколько именно весят сами сейвы, потому что со временем они растут:

du -sh ~/palworld-server/Pal/Saved/SaveGames/*

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

Что чистить в первую очередь:

• Логи сервера, если они не ротируются (journalctl по умолчанию ограничен, но самописные логи в Saved/Logs/ могут расти бесконтрольно).
• Старые бэкапы сейвов — оставляйте разумную глубину хранения (например, последние 7-14 копий), а не всё подряд.
• Кэш SteamCMD, если сервер обновлялся много раз (~/Steam/steamapps/downloading и временные файлы загрузки).

Если места стабильно не хватает — это тоже повод задуматься об апгрейде диска, а не только о разовой чистке: мир Palworld со временем только растёт, и через месяц проблема вернётся снова.

Повреждённый файл сохранения

Если сервер один раз уже упал прямо во время записи (по памяти, по диску или просто из-за случайного сбоя процесса), высокий шанс, что временный файл не успел атомарно подменить старый сейв — и теперь на диске лежит битый или неполный Level.sav. При следующей попытке загрузки или сохранения именно этого мира сервер может падать уже стабильно, при каждом запуске.

Признаки повреждённого сейва:

• Сервер падает не время от времени, а строго каждый раз в одной и той же точке (обычно сразу после запуска или на первом же автосохранении).
• В логах перед крашем нет явной причины вроде OOM или ошибки диска — просто обрыв.
• Размер файла Level.sav в папке мира заметно отличается от соседних резервных копий (сильно меньше — верный признак незавершённой записи).

Посмотреть структуру сохранений мира:

ls -la ~/palworld-server/Pal/Saved/SaveGames/<SteamID>/<WorldID>/

Там лежат Level.sav, LevelMeta.sav и папка Players/ с отдельным файлом на каждого игрока. Если Level.sav подозрительно мал или его дата изменения не совпадает с ожидаемым временем последнего автосохранения — скорее всего, дело именно в повреждении. В этом случае единственный надёжный выход — восстановление из последней рабочей резервной копии, это подробно разберём ниже. Подробнее о том, как читать логи и краш-репорты сервера, чтобы точно определить причину, а не гадать — в отдельной статье: логи и краш-репорты — как читать и искать причину.

Настройка AutoSaveSpan: баланс частоты автосохранений

Интервал автосохранения задаётся параметром AutoSaveSpan внутри строки OptionSettings=(...) в файле PalWorldSettings.ini. Значение указывается в минутах, по умолчанию обычно стоит около 30 минут — это ориентировочная цифра из дефолтного конфига, а не жёстко зафиксированное разработчиками число, так что сверяйтесь со своим файлом при настройке.

AutoSaveSpan=30.000000

Тут есть компромисс в обе стороны:

• Слишком частые сохранения (например, каждые 5-10 минут) на большом мире означают, что тяжёлая операция записи повторяется чаще — а значит, чаще случаются и пиковые нагрузки на память, которые могут закончиться крашем. На активно растущем мире с большим количеством построек это ощутимо.
• Слишком редкие сохранения (раз в час и больше) снижают частоту рискованных моментов, но увеличивают потери в случае краша между сохранениями — если сервер упадёт через 50 минут после последнего сейва, все действия игроков за это время пропадут.

Рабочий подход для сервера, который уже ловит краши на сохранении: временно увеличить AutoSaveSpan до 45-60 минут, чтобы снизить частоту тяжёлых операций, и параллельно настроить внешние резервные копии на регулярной основе через cron — так вы не зависите только от встроенного автосохранения. О том, как выстроить расписание автобэкапов игрового сервера правильно, есть отдельный разбор: автобэкапы игрового сервера — настройка расписания.

После правки AutoSaveSpan перезапустите сервер, чтобы конфиг применился:

sudo systemctl restart palworld

Восстановление сервера из резервной копии

Если сейв уже повреждён и сервер падает стабильно — редактировать битый файл руками бессмысленно, откатывайтесь на последнюю рабочую копию. Порядок действий:

1. Остановите сервис, чтобы исключить параллельную запись в повреждённые файлы:

sudo systemctl stop palworld

1. Отложите битую версию мира в сторону (не удаляйте сразу — иногда часть данных ещё можно вытащить вручную):

mv ~/palworld-server/Pal/Saved/SaveGames/<SteamID>/<WorldID> \
   ~/palworld-server/Pal/Saved/SaveGames/<WorldID>-broken-$(date +%F)

1. Скопируйте последнюю рабочую резервную копию на место:

cp -r /path/to/backups/<WorldID>-latest \
      ~/palworld-server/Pal/Saved/SaveGames/<SteamID>/<WorldID>

1. Проверьте права доступа — если копировали от root, файлы должны принадлежать пользователю, от которого работает сервер:

chown -R palworld:palworld ~/palworld-server/Pal/Saved/SaveGames/<SteamID>/<WorldID>

1. Запустите сервер и сразу проверьте логи на предмет повторного краша:

sudo systemctl start palworld
journalctl -u palworld -f

Важный нюанс: игроки потеряют прогресс за время между последним рабочим бэкапом и моментом краша — это неизбежно, если автосохранение не успело записаться. Именно поэтому регулярные внешние бэкапы (а не только встроенный AutoSaveSpan) — не опциональная страховка, а обязательная часть эксплуатации сервера, который вы не хотите потерять целиком из-за одного неудачного сохранения. Практику восстановления игровых серверов из бэкапов в целом, с типичными граблями, разбирали отдельно: восстановление сервера из бэкапа — практика.

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

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