Оптимизация Palworld-сервера: TPS, лаги, флаги запуска
Глубокая оптимизация Palworld dedicated server: флаги -useperfthreads, -NoAsyncLoadingThread, -UseMultithreadForDS, параметры конфига под нагрузку, CPU-affinity, NVMe и измерение serverfps.
Оптимизация Palworld-сервера - это не одна галочка, а связка из флагов запуска, параметров конфига под нагрузку, правильного железа и мониторинга tickrate. Palworld написан на Unreal Engine 5, и его серверная нагрузка растёт не столько от числа игроков, сколько от количества баз и палов, работающих на них. В этой статье разбираем, что именно грузит CPU, что делает каждый флаг запуска, какие параметры конфига снижают нагрузку и как измерять serverfps через REST API. Установку и базовую настройку не дублируем - для них есть отдельные материалы: установка Palworld dedicated server и настройка PalWorldSettings.ini.
Почему Palworld грузит CPU
Прежде чем крутить настройки, нужно понять, куда уходят такты процессора. У Palworld три главных потребителя CPU, и все они масштабируются нелинейно.
Radius load: чанки вокруг каждого игрока
UE5 подгружает участок мира в радиусе вокруг каждого подключённого игрока и держит его активным - симулирует физику, спавн мобов, деревья, руду. Два игрока рядом делят один загруженный регион, но два игрока в разных концах карты - это два независимых активных участка. Поэтому распределённый по карте онлайн дороже, чем сгруппированный. Каждый активный регион добавляет фиксированную нагрузку на CPU и RAM независимо от того, что игрок там делает.
AI палов на базах: главный убийца tickrate
Самый недооценённый источник лага - палы на базах. Каждый пал, назначенный на базу, - это отдельный AI-агент: он ищет работу, идёт к объекту, взаимодействует, ест, спит. Palworld просчитывает этих палов даже когда владелец базы оффлайн (если не включено автоудаление гильдий). Считаем: гильдия с 4 базами по 15 палов - это 60 постоянно тикающих AI. Десять таких гильдий на сервере - 600 AI-агентов, каждый со своим pathfinding по навмешу. Именно это, а не игроки в бою, чаще всего кладёт tickrate.
Однопоточность игрового тика
Даже с флагами многопоточности главный игровой тик (game thread) остаётся преимущественно однопоточным - так устроен Unreal Engine. Флаги выносят в отдельные потоки загрузку ассетов и часть вспомогательной работы, но симуляция мира упирается в производительность одного ядра. Отсюда правило: для Palworld важнее высокая частота ядра (single-thread performance), чем их количество. Ryzen 9 с высоким бустом обгонит многоядерный, но медленный Xeon.
Флаги запуска: что делает каждый
Рекомендованная строка запуска Palworld dedicated server:
./PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS port=8211 players=32Разберём по флагам.
| Флаг | Что делает | Эффект |
|---|---|---|
-useperfthreads | Включает пул потоков производительности UE, распределяя фоновые задачи (сериализация, задачи движка) по свободным ядрам | Снижает пики нагрузки на главный поток |
-NoAsyncLoadingThread | Отключает отдельный поток асинхронной подгрузки ассетов. На клиенте он полезен для плавности, на сервере создаёт лишние переключения контекста | Убирает конкуренцию за ядро с game thread |
-UseMultithreadForDS | Ключевой флаг именно для dedicated server (DS): разрешает движку задействовать несколько потоков для серверной симуляции | Основной прирост tickrate |
По замерам сообщества полный набор из трёх флагов даёт 15-30% прирост устойчивого tickrate при онлайне 16 и выше. Важный момент: флаги работают в связке. Если поставить только -UseMultithreadForDS без остальных, -NoAsyncLoadingThread не уберёт паразитный поток загрузки, и часть выигрыша съестся. Ставьте все три.
Флаги прописываются как в ручном запуске, так и в systemd-unit в строке ExecStart. Порядок флагов значения не имеет, но они должны идти до port= и players=.
Параметры конфига под нагрузку
Часть настроек PalWorldSettings.ini напрямую влияет на CPU и RAM. Полный разбор конфига - в статье про настройки Palworld, здесь только то, что касается производительности.
Дроп предметов
DropItemMaxNum=1500
DropItemMaxNum_UNKO=100
DropItemAliveMaxHours=1.000000DropItemMaxNum (дефолт 3000) - это потолок числа предметов, лежащих на земле в мире. Каждый такой предмет - объект, который движок отслеживает и синхронизирует. На загруженном сервере снижение до 1500 заметно разгружает и CPU, и сеть. DropItemAliveMaxHours=1.0 заставляет дроп исчезать через час - без этого выкинутые вещи копятся и живут постоянным фоном. Для высокого онлайна можно поставить 0.5 (30 минут).
Ограничение баз и палов
BaseCampMaxNumInGuild=3
BaseCampWorkerMaxNum=15
BaseCampMaxNum=128
GuildPlayerMaxNum=20BaseCampMaxNumInGuild (дефолт 4) - самый мощный рычаг. Уменьшение до 3, а на тяжёлых серверах до 2, режет число активных AI-палов линейно. BaseCampWorkerMaxNum (дефолт 15) - сколько палов работает на одной базе. Снижение до 10-12 уменьшает AI-нагрузку без большого ущерба для геймплея. BaseCampMaxNum=128 - глобальный потолок баз на весь сервер, страхует от бесконтрольного роста.
Автоудаление брошенных гильдий
bAutoResetGuildNoOnlinePlayers=True
AutoResetGuildTimeNoOnlinePlayers=168.000000Это критично для долгоживущих серверов. Когда игрок бросает сервер, его базы и палы остаются в мире и продолжают тикать вечно, отъедая CPU. bAutoResetGuildNoOnlinePlayers=True включает автоудаление гильдий, все участники которых оффлайн дольше AutoResetGuildTimeNoOnlinePlayers часов. 168 часов = неделя. На активных серверах это единственный способ не дать миру зарасти мёртвыми базами. Учтите: настройка удаляет прогресс, предупреждайте игроков в правилах.
Прочие рычаги
PalSpawnNumRate=0.800000
bIsUseBackupSaveData=TruePalSpawnNumRate (дефолт 1.0) снижает плотность диких палов в мире - меньше спавнящихся AI. 0.8 почти незаметно для игры, но разгружает регионы. bIsUseBackupSaveData на нагрузку не влияет, но защищает от потери мира при крэше - держите включённым.
Pterohost - игровой хостинг на Ryzen 9 с высоким бустом ядра и NVMe, где Palworld держит стабильный tickrate. Промокод 4START даёт -20% на первый заказ. Арендовать Palworld сервер
Железо: CPU-affinity, приоритет и NVMe
Частота ядра важнее числа ядер
Как разобрали выше, главный тик Palworld однопоточный. При выборе железа смотрите на single-thread performance и частоту буста, а не на суммарное число ядер. Восемь ядер Ryzen 9 на 5+ ГГц обслужат Palworld лучше, чем 32 медленных ядра серверного Xeon прошлых поколений.
NVMe обязателен
Palworld сохраняет мир целиком, синхронно, каждые 30 секунд по умолчанию. Чем больше баз и палов - тем крупнее Level.sav (на населённом сервере он вырастает до сотен мегабайт). На HDD запись такого файла занимает 10-15 секунд, и всё это время сервер стоит - игроки видят фриз и резиновые перемещения. SATA SSD снимает большую часть проблемы, NVMe убирает её полностью: сейв укладывается в доли секунды. Для сервера от 16 игроков NVMe - не роскошь, а обязательное условие.
CPU-affinity и приоритет
На выделенном железе с несколькими сервисами имеет смысл закрепить процесс Palworld за конкретными ядрами и повысить приоритет. Это уменьшает миграцию потока между ядрами и потерю кэша.
# Запустить Palworld на ядрах 0-5 с повышенным приоритетом
taskset -c 0-5 nice -n -5 ./PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS port=8211 players=32В systemd-unit то же самое задаётся декларативно, без обёрток:
[Service]
CPUAffinity=0 1 2 3 4 5
Nice=-5CPUAffinity привязывает процесс к ядрам 0-5, Nice=-5 даёт ему приоритет над фоновыми задачами. Не выделяйте под сервер все ядра до последнего - оставьте одно-два системе и ядру, иначе автосейв и сеть начнут конкурировать с игровым тиком.
Плановые рестарты против утечек RAM
Palworld-сервер медленно накапливает потребление RAM за счёт фрагментации и не всегда освобождаемых объектов - за сутки-двое аптайма память может вырасти на несколько гигабайт без роста онлайна. Одновременно постепенно проседает tickrate. Лечится плановым рестартом раз в сутки.
Скрипт с предупреждением игроков и корректным сейвом через RCON:
#!/bin/bash
RCON="rcon -a 127.0.0.1:25575 -p strong-admin-pass"
$RCON "Broadcast Scheduled_restart_in_5_minutes"
sleep 240
$RCON "Broadcast Restart_in_60_seconds"
sleep 50
$RCON "Broadcast Saving_world"
$RCON "Save"
sleep 5
$RCON "Shutdown 5 Restarting_now"Cron на 6 утра, когда онлайн минимальный:
0 6 * * * /home/palworld/restart.shВажно: рестарт - это профилактика утечки RAM, а не средство от лагов вообще. Если сервер начинает тормозить уже через час после старта, проблема в перегрузке (мало ядер, слишком много баз или дропа), и рестарт лишь ненадолго прячет симптом. Разница между оптимизацией и лечением разовых лагов - в следующем разделе.
Как измерять tickrate через REST API
Без цифр оптимизация - это гадание. Palworld отдаёт метрики через REST API. Включаем его в PalWorldSettings.ini:
RESTAPIEnabled=True
RESTAPIPort=8212Метрики берутся с эндпоинта GET /v1/api/metrics с Basic-авторизацией (логин admin, пароль - AdminPassword из конфига):
curl -s -u admin:strong-admin-pass http://127.0.0.1:8212/v1/api/metrics | jqПример ответа:
{
"serverfps": 29,
"currentplayernum": 14,
"serverframetime": 34.5,
"maxplayernum": 32,
"uptime": 43200
}Ключевое поле - serverfps, это и есть фактический tickrate сервера. Ориентиры:
| serverfps | Состояние |
|---|---|
| 28-30 | Здоровый сервер, потолок ванильного движка - 30 |
| 22-27 | Ощутимая нагрузка, палы двигаются рывками, стоит снизить число баз |
| ниже 20 | Перегрузка, заметные лаги AI и физики, нужна оптимизация железа или конфига |
Для непрерывного мониторинга опрашивайте эндпоинт по cron или скармливайте в Prometheus - падение serverfps в динамике покажет, когда именно (после какого события, при каком онлайне) сервер начинает захлёбываться. Подробный разбор эндпоинтов - в материале про Palworld REST API.
Оптимизация против лечения лагов
Важно различать две задачи. Оптимизация - это профилактика: флаги запуска, разумные лимиты баз, правильное железо, плановые рестарты. Она нужна всегда и настраивается один раз при запуске сервера. Лечение лагов - это диагностика уже возникшей проблемы: сервер стабильно работал и вдруг начал фризить, serverfps просел, игроки жалуются на телепорты палов.
Если у вас именно второй случай - разовые или внезапно появившиеся лаги, - оптимизация конфига их не вылечит, пока не найдена причина. Причиной может быть одна гильдия, настроившая 4 базы по 15 палов, всплеск дропа после массового боя, сетевой флуд или деградация после многих часов аптайма. Пошаговую диагностику именно таких ситуаций мы вынесли в отдельную статью: устранение лагов Palworld-сервера. Эта же статья - про то, как настроить сервер так, чтобы до лагов дело не доходило.
Pterohost - Palworld-хостинг с NVMe, DDoS-защитой L3/L4 и мониторингом tickrate из коробки. Промокод 4START даёт -20% на первый заказ. Заказать Palworld сервер
Часто задаваемые вопросы
Что реально дают флаги запуска Palworld -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS?
Они включают многопоточную обработку тиков и убирают отдельный поток асинхронной загрузки, который на сервере только мешает. По замерам сообщества набор поднимает устойчивый tickrate на 15-30% при онлайне 16+ игроков. Ставить нужно все три сразу - по отдельности эффект слабее.
Почему Palworld так грузит CPU даже при небольшом онлайне?
Unreal Engine 5 подгружает чанки в радиусе вокруг каждого игрока (radius load) и просчитывает AI всех палов на всех базах, даже когда владелец оффлайн. Пять баз с 15 работающими палами каждая - это 75 активных AI-агентов, которые тикают постоянно. Именно базы, а не число игроков, чаще всего упирают сервер в одно ядро.
Как измерить tickrate (serverfps) Palworld-сервера?
Включите REST API (RESTAPIEnabled=True, порт 8212) и опросите GET /v1/api/metrics с Basic-авторизацией admin/AdminPassword. В ответе поле serverfps - это фактический tickrate. Ванильный потолок 30, стабильные 28-30 = здоровый сервер, падение ниже 20 означает перегрузку CPU.
Обязателен ли NVMe для Palworld-сервера?
Да. Автосейв мира с большим числом баз на HDD занимает 10-15 секунд и фризит весь сервер на это время, потому что запись синхронна. На NVMe тот же сейв укладывается в доли секунды. SATA SSD - минимум, NVMe - правильный выбор для 16+ игроков.
Помогают ли плановые рестарты от лагов в Palworld?
Плановый рестарт лечит утечку RAM и деградацию tickrate, накопленную за сутки аптайма, но не устраняет причину лага. Если сервер начинает тормозить уже через час после старта - дело в перегрузке (слишком много баз, дропа или мало ядер), и рестарт лишь маскирует проблему. Диагностику разовых лагов смотрите в отдельной статье.