Планируй ОЗУ и CPU для Palworld на основе требований разработчика и повторяемых замеров нагрузки. На наших клиентских серверах с числом одновременно активных игроков до 4 потребление ОЗУ при ежедневной перезагрузке оставалось ниже 6 ГБ. Сколько игроков может играть плавно, зависит прежде всего от лимита CPU. Увеличение ОЗУ помогает только тогда, когда память действительно ограничивает работу.
Последняя проверка: 25 сентября 2026 г. с Palworld v1.0.5 и документацией сервера Pocketpair по состоянию на v1.0.4.
Как правильно читать официальные требования
Для выделенного сервера Palworld Pocketpair указывает 16 ГБ ОЗУ, минимум четыре рекомендуемых ядра CPU и быстрый SSD. Эти данные являются рекомендацией разработчика, но не таблицей «игроков на ГБ». Они не означают, что определённый объём ОЗУ автоматически гарантирует определённое число игроков.
Актуальный источник от разработчика ты найдёшь в официальных требованиях к серверу Palworld. Pocketpair там же предупреждает, что медленное хранилище может повредить данные сохранений. Поэтому планируй ОЗУ, CPU и хранилище вместе.
Что мы измерили на наших серверах
На наших работающих клиентских серверах с числом одновременно активных игроков до 4 потребление ОЗУ при ежедневной перезагрузке оставалось ниже 6 ГБ, без аварийных остановок из-за нехватки памяти (14-дневный замер, октябрь 2026). Пики лежали в диапазоне от 3,4 до 5,3 ГБ независимо от забронированного тарифа. Узким местом, напротив, был CPU: с каждым дополнительным игроком нагрузка на CPU заметно росла, а сервер с 4 игроками временами работал на пределе лимита CPU. Для более крупных групп у нас нет собственных измеренных значений.
Если должно играть больше игроков одновременно, выбери тариф с более высоким лимитом CPU или добавь дополнительное ядро: +1 vCPU за 2,99 € в месяц, не более 2 дополнительных ядер.
| Компонент | Официальная оценка | Вывод для твоего планирования |
|---|---|---|
| ОЗУ | 16 ГБ эксплуатационное требование | Данные разработчика; на наших клиентских серверах с числом игроков до 4 потребность оставалась ниже 6 ГБ |
| CPU | рекомендуется минимум четыре ядра | определяет, сколько игроков может играть плавно; для большего числа игроков нужен более высокий лимит CPU |
| Хранилище | рекомендуется быстрый SSD | не пренебрегай данными сохранений и I/O |
Почему число игроков само по себе не даёт формулы для RAM
Два мира с одинаковым числом подключённых игроков могут создавать совершенно разную нагрузку. Новый мир, в котором группа путешествует вместе, ведёт себя иначе, чем давно существующий мир с разбросанными базами, множеством рабочих Pals, крупными комплексами построек и повышенной скоростью спауна. Также на работу, которую должен выполнять выделенный сервер, влияют одновременно активные области мира, автоматизация и изменённые настройки сервера.
Поэтому максимальное число участников — это лимит доступа, а не прямой измеритель ресурсов. Универсальное утверждение вроде фиксированного объёма ОЗУ на игрока игнорирует состояние мира, нагрузку на CPU и обращения к памяти. Используй число игроков как контекстное значение, но решай об апгрейде только вместе с воспроизводимыми данными замеров.
Как построить пригодную базовую линию замеров
Сначала определи типичное окно нагрузки. Это может быть вечер сообщества, событие с боссом или фаза, когда несколько групп одновременно работают на разных базах. В течение этого окна фиксируй как минимум число одновременно подключённых игроков, загрузку ОЗУ и CPU, серверные FPS, frame time, количество баз и заметные события в логах. Серверные FPS и frame time ты получаешь через REST API сервера (RESTAPIEnabled=True в PalWorldSettings.ini, затем GET /v1/api/metrics): он возвращает serverfps, serverframetime, currentplayernum и uptime. Также отметь, какие скорости спауна и значимые для производительности настройки были активны.
Одного пика недостаточно в качестве доказательства. Повтори наблюдение в сопоставимое время и задокументируй, возникает ли насыщение постоянно или только кратковременно. Зафиксируй также версию патча: начиная с версии 1.0 Palworld строго проверяет версию, и необновлённый сервер отклоняет клиентов с более новой версией как несовместимых. Кроме того, обновление игры или новая фаза мира могут изменить нагрузку без роста числа игроков. Эта базовая линия делает возможными последующие сравнения «до и после».
Отдели нехватку RAM от других причин
Прежде чем увеличивать RAM, сравни потребление памяти и время работы процесса при схожей нагрузке. Если при одинаковой активности потребление растёт в течение долгого времени и падает после перезапуска, запланированный перезапуск может временно сгладить симптом. Предварительно сохрани состояние мира. И всё же исследуй причину и доступные обновления: такая картина не доказывает, что апгрейд в принципе не нужен.
Увеличение RAM оправдано, если процесс неоднократно упирается в доступный предел, возникают события OOM или сервер при сопоставимой нагрузке воспроизводимо стабильнее работает с дополнительной памятью. Высокое занятое значение само по себе ещё не доказывает нехватку: операционная система и приложение могут использовать свободную память как кэш. Решающее значение имеют насыщение, картина ошибок и повторяемое поведение.
Параллельно проверь CPU. На наших клиентских серверах он был узким местом чаще, чем ОЗУ. Если отдельные ядра постоянно загружены, а запас ОЗУ ещё есть, увеличение оперативной памяти не устраняет настоящее узкое место. Падающие серверные FPS или растущий frame time могут быть связаны как с работой CPU, так и со сложным состоянием мира. Поэтому не меняй одновременно ОЗУ, распределение CPU и скорость спауна; иначе будет невозможно определить, какая мера оказалась действенной.
Учитывай хранилище и сохранность данных
Pocketpair рекомендует быстрое SSD-хранилище и указывает на риск для данных сохранений при слабом хранилище; от Docker Desktop страница требований прямо отговаривает, поскольку он повышает риск повреждения сохранений. bIsUseBackupSaveData (по умолчанию включён) создаёт скользящие бэкапы в папке сохранений и за это даёт дополнительную нагрузку на диск. Поэтому следи за ошибками I/O, необычно долгими операциями сохранения и свободным местом. Перед любым тестом с модами, крупными изменениями конфигурации или обновлениями сервера создавай проверяемый бэкап. Подходящий порядок действий описан в руководстве Резервное копирование и восстановление мира Palworld.
Бэкап надёжен лишь тогда, когда ты знаешь, где он лежит, какое состояние мира в нём содержится и как работает восстановление. Не проводи рискованные нагрузочные тесты на единственной копии своего боевого мира. Так расследование производительности само не приведёт к потере данных.
Тестируй изменения под контролем
Перед изменением составь короткий план проверки: какой симптом должен исчезнуть, какое измеряемое значение должно улучшиться и в каком сопоставимом окне нагрузки будет проверка? Затем сделай резервную копию мира и измени ровно одну переменную. При предполагаемой нехватке ОЗУ это объём памяти; при нехватке CPU — более высокий лимит CPU, например через дополнительное ядро, или значимая для производительности настройка.
После изменения аккуратно перезапусти сервер и повтори задокументированное окно нагрузки. Сравнивай не только пиковое значение, но и стабильность, события OOM, RAM, CPU, серверные FPS и время кадра. Если проблема не изменилась, откати изменение или изучи следующее обоснованное узкое место. Если поведение воспроизводимо улучшилось, задокументируй новую базовую линию и причину.
Для изменений конфигурации используй руководство Настройка параметров сервера Palworld. Официальный список аргументов от Pocketpair объясняет, среди прочего, порт прослушивания, максимальное число участников и актуальные указания по аргументам производительности. Не копируй параметры запуска вслепую из старых постов сообщества: для версии 1.0 и новее производитель прямо указывает, что без некоторых прежних параметров многопоточности поведение может быть лучше.
Проверка ёмкости после обновлений и роста мира
Начиная с v1.0.3 параметр bAllowEnemyCampSpawnNearBaseCamp=False ограничивает спавн рейдов рядом с базами игроков, а с v1.0.4 MaxBuildingLimitNum ограничивает число строительных элементов на игрока; оба переключателя важны для производительности. Кластеризация серверов, анонсированная в июне 2026 года, не выпущена вплоть до v1.0.5, так что распределение нагрузки между несколькими экземплярами по-прежнему недоступно.
Однажды измеренная величина не остаётся верной навсегда. Повторяй проверку после крупных обновлений Palworld, сильного роста баз, изменённых скоростей спауна и заметно выросшего сообщества. Всегда сравнивай с последней стабильной базовой линией. Так ты поймёшь, действительно ли изменилась потребность в ресурсах или возникла новая ошибка, не связанная с ОЗУ и CPU.
Для каждого решения используй один и тот же порядок: проверить официальную минимальную базу, сделать резервную копию мира, зафиксировать замеры, классифицировать узкое место, протестировать ровно одно изменение и задокументировать результат. Так ты избежишь как слишком маленьких инстансов, так и дорогих апгрейдов, которые не решают проблему с CPU, хранилищем или конфигурацией.
FAQ
Хватит ли 6 ГБ ОЗУ для сервера Palworld?
На наших работающих клиентских серверах с числом одновременно активных игроков до 4 потребление ОЗУ при ежедневной перезагрузке оставалось ниже 6 ГБ, без аварийных остановок из-за нехватки памяти (14-дневный замер, октябрь 2026). Pocketpair указывает 16 ГБ ОЗУ в качестве эксплуатационных требований. Для более крупных групп у нас нет собственных измеренных значений.
Сколько RAM нужно на одного игрока?
Надёжной фиксированной формулы для этого не существует. Число игроков, базы, рабочие Pals, постройки, скорость спауна, настройки и одновременно активные области мира влияют на нагрузку совместно. На наших серверах с каждым игроком росла прежде всего нагрузка на CPU, а ОЗУ почти не росла. Решай о дополнительных мощностях на основе повторяемых измерений.
Когда мне нужно больше ОЗУ или более высокий лимит CPU?
Больше ОЗУ помогает, если насыщение ОЗУ или OOM-события воспроизводимо возникают при сопоставимой нагрузке. Если CPU постоянно работает на пределе, а ОЗУ свободна, тебе нужен более высокий лимит CPU, например через дополнительное ядро.
Поможет ли больше RAM от любых лагов?
Нет. Насыщение CPU, медленное хранилище, сложность мира, проблемы с сетью и неподходящие настройки могут вызывать похожие симптомы. Проверь вместе ОЗУ, CPU, серверные FPS, frame time, логи и хранилище, прежде чем определять причину.
Что нужно сохранить перед тестом производительности?
Создай проверяемую резервную копию мира и задокументируй версию патча и настройки. Затем измени только одну переменную и повтори сопоставимое окно нагрузки. Так результат останется воспроизводимым, а рабочий мир можно будет восстановить.
Используй перезапуск для сравнения
Запиши ОЗУ и серверные FPS перед запланированной, корректно сохранённой перезагрузкой и после повторного входа той же группы. Подожди, пока те же базы снова станут активны; пустой сервер после запуска не является сопоставимой точкой измерения. Если при сопоставимой активности загрузка остаётся низкой, изучи динамику за время работы. Если память снова сразу исчерпана, проверь нагрузку мира. Перезагрузка может временно уменьшить симптом, но не доказывает ни ошибку памяти, ни слишком маленький тариф. Принимай решение на основе нескольких сопоставимых периодов работы.