Требования сервера Palworld: сколько ресурсов нужно на игроков
Par Benjamin D. · PDG
· Mis à jour le 1 сентября 2026 г. · Lecture 8 min
Содержание
Требования сервера Palworld редко совпадают с тем, что написано в системных рекомендациях клиента: выделенная часть игры ведёт себя иначе, а память растёт вместе с числом баз, Палов и построек. Ниже — практический расчёт RAM и нагрузки на CPU под конкретное число игроков, плюс разбор параметров PalWorldSettings.ini, которые реально влияют на тикрейт.
Из чего складываются требования сервера Palworld
Выделенный процесс PalServer построен на Unreal Engine 5 и почти всю симуляцию мира тянет в одном основном потоке. Отсюда два практических вывода: частота ядра важнее их количества, а объём памяти зависит не от онлайна как такового, а от того, сколько объектов игроки успели создать в мире.
RAM: базовый расход и рост во времени
Свежий мир после первого запуска занимает примерно 6–8 ГБ. Это уже базовая планка, ниже которой процесс просто не живёт стабильно. Дальше память растёт по трём направлениям:
- Игроки в сети — каждый активный игрок тянет за собой свою партию Палов, инвентарь, состояние экипировки: ориентировочно 250–500 МБ.
- Базы гильдий — крупный лагерь с 15 рабочими Палами, конвейерами и сотнями построек стоит дороже, чем сам игрок. Считай 1–2 ГБ на активную развитую базу.
- Мусор в мире — выпавшие предметы, яйца, брошенные постройки неактивных гильдий. Именно они превращают 12 ГБ на старте в 26 ГБ через месяц.
CPU: решает частота, а не количество ядер
Основной игровой поток обрабатывает физику, ИИ Палов и репликацию. Когда он упирается в потолок, ты видишь классику: резиновый рубберband при беге, задержку срабатывания ударов, Палы «телепортируются» на базе. Добавление ядер эту проблему не решает — помогает только более быстрое ядро. Поэтому платформа на Ryzen с высокой тактовой частотой и NVMe-накопителем даёт заметно более ровный тикрейт, чем машина с большим числом медленных потоков.
Диск и сеть
Сохранение мира (Level.sav и папка Players/) пишется целиком при каждом автосейве. На HDD это выливается в микрофризы на 1–3 секунды для всех подключённых. NVMe снимает проблему почти полностью. Порты по умолчанию: 8211/UDP для игры, 27015/UDP для Steam-запросов, 25575/TCP для RCON.
Если ты не хочешь заниматься подбором железа вручную, готовая площадка под этот проект — хостинг Palworld с панелью Pterodactyl, автоматическими бэкапами и защитой от DDoS-атак по умолчанию. Остальные поддерживаемые проекты собраны на странице Все наши игровые серверы.
Расчёт RAM и CPU под число игроков
Рабочая формула, которая нормально бьётся с реальными замерами:
RAM = 8 ГБ (база процесса)
+ 0,4 ГБ × число одновременных игроков
+ 1,5 ГБ × число активных развитых баз
+ 20 % запаса на фрагментацию памятиОриентировочная таблица
| Онлайн | RAM минимум | RAM с запасом | Потоки CPU | Диск под мир |
|---|---|---|---|---|
| 2–4 игрока | 8 ГБ | 12 ГБ | 2–4 | 15 ГБ |
| 5–8 игроков | 12 ГБ | 16 ГБ | 4 | 20 ГБ |
| 9–16 игроков | 16 ГБ | 24 ГБ | 4–6 | 30 ГБ |
| 17–24 игрока | 24 ГБ | 32 ГБ | 6–8 | 40 ГБ |
| 25–32 игрока | 32 ГБ | 48 ГБ | 8 | 50 ГБ+ |
Цифры в колонке «RAM минимум» — это то, при чём процесс запустится и проживёт вечер. «С запасом» — то, при чём он проживёт месяц без OOM-kill. Разница принципиальная: Palworld не отдаёт память обратно системе, пока не будет перезапущен.
Почему память растёт даже при пустом сервере
Известное поведение выделенной части: резидентная память процесса монотонно увеличивается за время аптайма. Через 24–48 часов непрерывной работы расход может вырасти в полтора-два раза от стартового. Лечится это не докупкой памяти, а плановым рестартом.
Практика, которая работает: перезапуск раз в 6–12 часов в ночное время. В панели Pterodactyl это задача в разделе Schedules — cron-выражение и действие «Restart». Перед рестартом полезно отправить в консоль команду сохранения через RCON:
# Сохранить мир перед плановым перезапуском
Save
# Корректное завершение с уведомлением игроков за 60 секунд
Shutdown 60 "Плановый перезапуск, вернёмся через минуту"Как проверить фактический расход
Если у тебя есть доступ к машине по SSH, реальные цифры смотрятся так:
# Резидентная память и загрузка CPU процессом
ps -o pid,%cpu,%mem,rss,etime,comm -C PalServer-Linux-Shipping
# Живой мониторинг с деревом процессов
htop -p $(pgrep -d, PalServer)
# Размер мира — главный индикатор будущих проблем
du -sh ~/Pal/Saved/SaveGames/0/*/Ориентир по Level.sav: до 40 МБ — всё нормально; 60–90 МБ — начинаются подтормаживания при автосейве; выше 100 МБ — время чистить мир. Растёт файл в первую очередь за счёт данных гильдий, которые больше не заходят в игру.
PalWorldSettings.ini: параметры, которые реально нагружают железо
Файл лежит по пути Pal/Saved/Config/LinuxServer/PalWorldSettings.ini и представляет собой одну длинную строку OptionSettings=(...). Редактировать его нужно при остановленном процессе, иначе изменения затрутся при выходе. Полное описание всех ключей есть в официальной технической документации Palworld.
Ключи с прямым влиянием на нагрузку
| Параметр | По умолчанию | Что делает с производительностью |
|---|---|---|
ServerPlayerMaxNum |
32 | Потолок онлайна. Ставь по фактическому пику, а не «на вырост» — лишние слоты провоцируют перегруз. |
BaseCampMaxNumInGuild |
4 | Число баз на гильдию. Каждая база симулируется постоянно. Уменьшение до 2–3 заметно разгружает поток. |
BaseCampWorkerMaxNum |
15 | Рабочие Палы на базу. Самый дорогой ИИ в игре. При онлайне выше 16 держи 12–15, не поднимай до 20+. |
DropItemMaxNum |
3000 | Лимит валяющихся предметов в мире. Снижение до 1500–2000 сокращает и память, и размер сейва. |
DropItemAliveMaxHours |
1.0 | Время жизни лута. Значения выше 2 часов копят мусор в сохранении. |
AutoSaveSpan |
30.0 | Интервал автосохранения в секундах. На большом мире 30 секунд означает постоянные микрофризы — 300–600 комфортнее. |
ServerReplicatePawnCutOff |
0 | Дистанция репликации Палов. Большие значения = больше сетевого трафика и работы для CPU. |
bIsUseBackupSaveData |
True | Дублирует сейв при каждом сохранении. Оставляй включённым, но следи за местом на диске. |
bEnableInvaderEnemy |
True | Рейды на базы. Спавнит волны NPC — короткие, но заметные пики нагрузки. |
Готовые профили конфигурации
Профиль для кооператива до 8 человек — комфорт важнее экономии ресурсов:
ServerPlayerMaxNum=8,
BaseCampMaxNumInGuild=4,
BaseCampWorkerMaxNum=15,
GuildPlayerMaxNum=8,
DropItemMaxNum=3000,
DropItemAliveMaxHours=2.000000,
AutoSaveSpan=300.000000,
bIsUseBackupSaveData=TrueПрофиль для публичного проекта на 24–32 слота — приоритет на стабильный тикрейт:
ServerPlayerMaxNum=32,
BaseCampMaxNumInGuild=2,
BaseCampWorkerMaxNum=12,
GuildPlayerMaxNum=10,
BaseCampMaxNum=128,
DropItemMaxNum=1500,
DropItemAliveMaxHours=1.000000,
AutoSaveSpan=600.000000,
ServerReplicatePawnCutOff=0,
bEnableInvaderEnemy=False,
bIsUseBackupSaveData=True,
RCONEnabled=True,
RCONPort=25575,
AdminPassword="длинный_случайный_пароль"Флаги запуска процесса
Стандартный набор аргументов, который снимает часть нагрузки с основного потока:
./PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS \
-port=8211 -queryport=27015 -players=32 -RconEnabled=TrueФлаг -useperfthreads перераспределяет часть работы по дополнительным потокам, -UseMultithreadForDS включает многопоточность выделенной части. На машинах с 4+ потоками эффект измеримый, на двухъядерных — почти нулевой.
Диагностика тикрейта и обслуживание мира
Лимит открытых файлов на Linux
Классическая причина падений на самостоятельно настроенной машине: PalServer открывает тысячи дескрипторов и упирается в лимит 1024. Проверка и исправление:
ulimit -n
# Постоянное увеличение лимита
echo "* soft nofile 1048576" | sudo tee -a /etc/security/limits.conf
echo "* hard nofile 1048576" | sudo tee -a /etc/security/limits.conf
# Для systemd-юнита
sudo systemctl edit palworld
# [Service]
# LimitNOFILE=1048576
sudo systemctl daemon-reload
sudo systemctl restart palworldРабота с RCON
RCON — самый быстрый способ понять, что происходит внутри, не заходя в игру. Пароль задаётся ключом AdminPassword и должен быть длинным и случайным: порт 25575 сканируется ботами постоянно.
# Кто в сети сейчас
ShowPlayers
# Информация о версии и имени мира
Info
# Принудительное сохранение
Save
# Модерация
KickPlayer <SteamID>
BanPlayer <SteamID>Чистка мира при разросшемся сохранении
Когда Level.sav переваливает за 100 МБ, а рестарты уже не помогают, порядок действий такой:
- Останови процесс и сделай полную копию папки
SaveGames— без бэкапа к чистке не приступать. - Снизь
DropItemMaxNumиDropItemAliveMaxHours, чтобы мусор перестал накапливаться заново. - Удали данные гильдий, которые не заходили несколько недель: это освобождает и постройки, и связанных с ними Палов.
- Попроси игроков разобрать заброшенные базы вручную — это самый безопасный вариант без внешних утилит.
Признаки, по которым видно упор в ресурс
- Упор в CPU — рубберband при движении, Палы на базе замирают и рывками догоняют состояние, задержка между ударом и уроном. Онлайн при этом может быть небольшим.
- Упор в RAM — процесс внезапно исчезает, в
dmesgвидно сообщение OOM-killer, игроков выбрасывает всех разом. - Упор в диск — короткие одинаковые фризы строго по расписанию автосейва.
- Проблема сети — высокий пинг у части игроков при нормальной нагрузке процесса.
В панели Pterodactyl графики RAM и CPU отображаются в реальном времени, а консоль показывает логи запуска — этого достаточно, чтобы за пару минут отделить проблему железа от проблемы конфигурации. Логика расчёта, кстати, переносится и на другие выживалки со схожей архитектурой: например, Сервер Valheim так же чувствителен к количеству объектов в мире, а не к числу игроков. Другие разборы по администрированию собраны в разделе Блог Fly-Serv.
Итог
Считай ресурсы не по онлайну, а по количеству баз и объектов в мире: 8 ГБ на процесс плюс запас на каждого игрока и каждую развитую базу. Держи AutoSaveSpan адекватным размеру сейва, ограничивай рабочих Палов и мусор, ставь плановые рестарты. Быстрое ядро, NVMe и регулярные копии решают девять из десяти жалоб на лаги.
FAQ
Сколько RAM нужно на 10 игроков в Palworld?Рабочий минимум — 16 ГБ, комфортная цифра с учётом роста мира — 20–24 ГБ. Десять игроков быстро строят 20–30 баз, а каждая развитая база стоит дороже, чем сам игрок. Если памяти всего 12 ГБ, обязательно ограничь BaseCampMaxNumInGuild до 2 и настрой автоматический перезапуск каждые 8 часов.
Это штатное поведение выделенной части: она не возвращает освобождённую память системе. Решение — плановый рестарт по расписанию раз в 6–12 часов через задачи панели с предварительной командой Save по RCON. Дополнительно снизь DropItemMaxNum и DropItemAliveMaxHours, чтобы мир меньше засорялся.
Частота. Основная симуляция мира выполняется в одном потоке, поэтому 4 быстрых ядра дают более ровный тикрейт, чем 12 медленных. Флаги -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS разгружают главный поток частично, но не отменяют зависимость от частоты ядра.