Лаги на сервере Palworld: причины и решение

Траблшутинг лагов Palworld: низкий serverfps и CPU, сетевой лаг и rubberbanding, фризы при автосейве. Диагностика через REST metrics, ss, iostat и рабочие фиксы.

Лаги на сервере Palworld почти всегда сводятся к трём разным проблемам, которые внешне ощущаются одинаково - “все дёргается”. Одно дело, когда просаживается serverfps и мир начинает тормозить у всех сразу (это CPU), другое - когда конкретного игрока откидывает назад при беге (это сеть), и третье - когда сервер замирает на пару секунд с регулярным интервалом (это автосейв на медленном диске). Лечатся они совершенно по-разному, поэтому первый шаг - не крутить настройки наугад, а поставить диагноз. Ниже разбираем каждый вид лага: как его распознать, чем измерить и что конкретно менять. Установку сервера здесь не дублируем - если он ещё не поднят, смотрите установку Palworld dedicated server.

Три вида лагов и как их различить

Прежде чем что-то чинить, определите категорию по симптому. Это экономит часы.

Дальше - подробно по каждому пункту.

Лаг №1: низкий serverfps (CPU-bound)

Palworld написан на Unreal Engine 5 и симулирует AI каждого пала, физику баз и загрузку чанков вокруг игроков. Целевой тик сервера - 30 кадров в секунду (serverfps=30). Когда одного из горячих потоков CPU не хватает, serverfps падает, и это ощущается как общая заторможенность: палы стоят столбом, двери открываются с лагом, урон применяется с задержкой.

Диагностика через REST API

Самый точный способ увидеть serverfps - REST API. Включите его в PalWorldSettings.ini:

RESTAPIEnabled=True,RESTAPIPort=8212

REST слушает 8212 TCP и требует Basic Auth с админ-паролем (AdminPassword). Запрос метрик:

curl -s -u admin:strong-admin-pass \
  http://127.0.0.1:8212/v1/api/metrics | jq

Ответ:

{
  "serverfps": 28,
  "currentplayernum": 14,
  "serverframetime": 35.7,
  "maxplayernum": 32,
  "uptime": 42130
}

Ключевое поле - serverfps. Ориентиры:

• 28-30 - здоровый сервер, игроки лагов не замечают.
• 20-27 - лёгкие подтормаживания под нагрузкой, терпимо.
• ниже 20 - явные лаги и rubberbanding у всех, нужен фикс.

Снимайте метрику именно в пик онлайна - на пустом сервере serverfps всегда 30. Удобно повесить опрос в цикл:

watch -n 5 'curl -s -u admin:pass http://127.0.0.1:8212/v1/api/metrics | jq "{fps:.serverfps, players:.currentplayernum}"'

Параллельно смотрите top - если у процесса PalServer один поток стабильно висит на 100%, а serverfps низкий, это классический CPU-bound по частоте одного ядра.

Фиксы для CPU-лага

Флаги многопоточности. Первое, что нужно сделать, - убедиться, что сервер запущен с правильным набором флагов:

./PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS

Эти три флага включают распараллеливание и убирают узкое место асинхронной загрузки ассетов, давая по данным сообщества 15-30% к serverfps. Подробно про них и другие тюнинги - в оптимизации Palworld сервера.

Апгрейд частоты CPU. Palworld плохо масштабируется вширь: 16 медленных ядер проиграют 6 быстрым. Решает высокая частота одного ядра. Ryzen 7000/9000 с бустом 5+ ГГц держит serverfps лучше, чем серверный Xeon с кучей медленных ядер. Если сервер CPU-bound и флаги уже стоят - переезд на хост с более высокочастотным CPU даёт самый заметный эффект.

Меньше нагрузки в мире. Снизьте то, что нагружает симуляцию:

OptionSettings=(DropItemMaxNum=1500,DropItemAliveMaxHours=1.000000,BaseCampMaxNumInGuild=3,bAutoResetGuildNoOnlinePlayers=True,AutoResetGuildTimeNoOnlinePlayers=168.000000)

• DropItemMaxNum с дефолтных 3000 до 1500 - сервер реже пересчитывает предметы на земле.
• BaseCampMaxNumInGuild=3 - каждая база держит активных палов-рабочих, а это постоянная AI-нагрузка. Меньше баз = выше serverfps.
• bAutoResetGuildNoOnlinePlayers удаляет заброшенные гильдии, чтобы мир не зарастал базами оффлайн-игроков.

Лимит слотов под железо. Не выставляйте players=32, если CPU это не тянет. Реалистичная привязка:

Palworld тяжелее большинства выживалок по требованиям на игрока - детали в системных требованиях Palworld.

Лаг №2: сетевой лаг, пинг и rubberbanding

Если тормозит не у всех, а конкретных игроков “телепортирует” назад при беге - это сеть, а не CPU. Rubberbanding возникает, когда сервер не получает вовремя UDP-пакеты позиции клиента и откатывает игрока к последней подтверждённой точке.

Диагностика сети

Начните с пинга до сервера со стороны жалующегося игрока:

ping -c 20 SERVER_IP

Смотрите две вещи: средний RTT и потери (packet loss). Стабильные 200+ мс или потери выше 1-2% - уже причина rubberbanding. Для детальной картины по маршруту используйте mtr, который показывает, на каком хопе теряются пакеты:

mtr -rwzc 100 SERVER_IP

На самом сервере проверьте очередь и состояние UDP-сокета порта 8211:

ss -u -a -p | grep 8211

Растущие Recv-Q/Send-Q означают, что сервер не успевает разгребать входящий трафик. Дропы на интерфейсе видно так:

ip -s link show eth0     # смотрим RX dropped / overrun
netstat -su | grep -i 'packet receive errors'

Фиксы для сетевого лага

Локация ближе к игрокам. Самое эффективное - разместить сервер географически рядом с основной аудиторией. Для игроков из СНГ хост в России или ближней Европе даёт 10-40 мс вместо 120-200 мс через океан. Пинг никакими настройками не победить, если сервер физически далеко.

Достаточный канал. Palworld при 20+ игроках с активными базами гонит заметный трафик синхронизации. Узкий или переполненный аплинк вызывает потери. Убедитесь, что у хоста гигабитный порт, а не шейпинг на 50-100 Мбит.

Проверьте порт и проброс. Rubberbanding иногда путают с частичной блокировкой UDP. Убедитесь, что 8211/UDP открыт и проброшен корректно - разбор портов в портах Palworld сервера.

Pterohost - игровой хостинг с DDoS-защитой и низким пингом по СНГ. Промокод 4START даёт -20% на первый заказ. Арендовать сервер Palworld

Лаг №3: фризы при автосейве (диск)

Характерный симптом - сервер замирает целиком на 2-15 секунд, и это повторяется с ровным интервалом около 30 секунд. Виноват автосейв: Palworld пишет Level.sav примерно каждые полминуты, и на большом мире (30-100+ МБ) запись на медленный диск блокирует главный поток. Все игроки в этот момент стоят.

Диагностика диска

Поймайте всплеск дисковой активности в момент фриза:

iostat -x 1

Смотрите столбцы %util и w_await для диска с сохранениями. Если в момент фриза %util прыгает к 100%, а w_await (задержка записи) в десятки-сотни миллисекунд - диск не успевает, и это точно он. На HDD такое поведение почти гарантировано на мире 32 игроков.

Проверьте, на каком типе носителя лежат сохранения:

lsblk -d -o name,rota      # rota=1 это HDD, rota=0 это SSD/NVMe
df -h /home/palworld/palserver/Pal/Saved

Фиксы для дисковых фризов

NVMe вместо HDD. Это главный и почти единственный настоящий фикс. На NVMe SSD запись сейва укладывается в доли секунды, и фриз становится незаметным. Если сервер на HDD - переносите папку Pal/Saved на SSD-раздел или переезжайте на хост с NVMe. Никакие настройки движка не компенсируют медленный диск.

Держите резервную копию сейва включённой. Опция страхует от повреждённого сохранения при крэше, не создавая заметной нагрузки:

bIsUseBackupSaveData=True

Не размещайте бэкапы на том же шпинделе. Если крон-скрипт архивирует Saved в момент автосейва на тот же HDD, фризы усилятся вдвое. Пишите бэкапы на отдельный диск или делайте их ночью в низкий онлайн, предварительно вызвав Save через RCON.

Лаг №4: DDoS, замаскированный под лаг

Отдельно стоит UDP-флуд. Атака на порт 8211 забивает канал и очередь пакетов мусорным трафиком, из-за чего у игроков растёт пинг и появляется rubberbanding - внешне неотличимо от обычного сетевого лага. Ключевой отличительный признак: CPU сервера при этом спокоен, serverfps в норме, а игроков всё равно колбасит.

Поймать всплеск входящего трафика:

iftop -i eth0 -P            # видно аномальный входящий поток на 8211/udp
vnstat -l -i eth0           # текущая скорость в реальном времени

Если при 10 онлайна входящий трафик внезапно исчисляется сотнями Мбит - это флуд, а не игроки. Программно на одном сервере такое почти не отбить: пакеты уже дошли до канала. Реальное решение - фильтрация на уровне сети (L3/L4), которая режет мусорный UDP до вашего сервера. Как это устроено - в защите от DDoS.

Плановый рестарт против накопительных лагов

Если serverfps и сеть в норме утром, но к вечеру всё лагает, а после рестарта снова хорошо - это накопительная деградация: фрагментация памяти или медленная утечка. Palworld известен ростом потребления RAM за долгий аптайм. Проверяйте:

free -m                     # смотрим used и особенно swap
htop                        # RES процесса PalServer растёт со временем?

Если сервер начал уходить в swap - это мгновенно убивает производительность, диск становится узким местом даже на NVMe. Лечится либо добавлением RAM, либо профилактическим рестартом раз в сутки через RCON в низкий онлайн:

rcon -a 127.0.0.1:25575 -p strong-admin-pass "Broadcast Restart_in_60_seconds"
sleep 60
rcon -a 127.0.0.1:25575 -p strong-admin-pass "Save"
rcon -a 127.0.0.1:25575 -p strong-admin-pass "Shutdown 10 Daily_restart"

systemd с Restart=on-failure поднимет процесс обратно. Ночной рестарт по крону снимает 90% жалоб на “к вечеру начинает лагать”.

Чек-лист диагностики за 5 минут

Быстрый алгоритм, когда пришли жалобы на лаги:

1. curl -u admin:pass http://127.0.0.1:8212/v1/api/metrics - serverfps ниже 20? Это CPU, идём в лаг №1.
2. top - один поток PalServer на 100%? Подтверждает CPU-bound.
3. ping и mtr со стороны игрока - потери или высокий RTT? Это сеть, лаг №2.
4. Фризы ровно раз в ~30 сек? iostat -x 1, смотрим диск - лаг №3, скорее всего HDD.
5. Пинг растёт, но CPU спокоен? iftop - аномальный трафик? Это DDoS, лаг №4.
6. Лаги только под вечер, RAM/swap растут? Плановый рестарт.

Такой порядок отсекает 95% случаев за несколько минут и не даёт крутить настройки вслепую.

Pterohost - Palworld на NVMe и высокочастотных Ryzen, с фильтрацией DDoS из коробки. Промокод 4START даёт -20% на первый заказ. Заказать Palworld хостинг

Часто задаваемые вопросы

Почему на сервере Palworld игроков откидывает назад (rubberbanding)?

Rubberbanding - это признак либо потери UDP-пакетов на порту 8211, либо просадки serverfps ниже 20. Сначала проверьте пинг и потери через ping и ss, затем serverfps через REST /metrics. Если serverfps низкий - виноват CPU, если пакеты теряются - сеть или DDoS-фильтр.

Как посмотреть serverfps (tickrate) сервера Palworld?

Включите REST API (RESTAPIEnabled=True, порт 8212 TCP) и запросите GET /v1/api/metrics с Basic Auth админ-пароля. В ответе поле serverfps - целевое значение 30, стабильно работающий сервер держит 25-30. Ниже 20 игроки чувствуют лаги и rubberbanding.

Почему сервер Palworld фризит на пару секунд каждые полминуты?

Это автосейв. Palworld пишет Level.sav каждые 30 секунд, и на HDD запись большого мира занимает 3-15 секунд, блокируя главный поток. Лечится переносом сохранений на NVMe SSD - там сейв укладывается в доли секунды и фриз пропадает.

Сколько слотов можно ставить на сервер Palworld без лагов?

Palworld упирается в один-два потока CPU, поэтому число слотов привязано к частоте ядра. На CPU 3.5+ ГГц реально держать 16-24 игрока, на 3.0 ГГц - 8-12. Ставить players=32 на слабом железе бессмысленно: serverfps просядет и лагать будут все.

Может ли DDoS-атака выглядеть как обычные лаги?

Да. UDP-флуд на порт 8211 забивает канал и очередь пакетов, из-за чего у игроков растёт пинг и появляется rubberbanding, а на сервере CPU выглядит спокойным. Отличить помогает всплеск входящего трафика в iftop при низкой нагрузке CPU. Решение - L3/L4 DDoS-фильтрация.