Производительность сервера Sons of the Forest: RAM, CPU и лаги

Выделенному серверу Sons of the Forest для небольшой компании нужно около 8 ГБ памяти и два быстрых ядра, для сложившейся группы из четырёх-шести игроков - 10 ГБ, а для полного сервера на восемь человек с миром, в который играют уже несколько недель, - 12 ГБ и три ядра. Он тяжёлый, потому что держит в памяти большой подробный мир и просчитывает каждого каннибала, каждое животное и каждую постройку в одном главном потоке, а на Linux к этому добавляется ещё и вес запуска Windows-бинарника под Wine. Два ключа в dedicatedserver.cfg определяют большую часть нагрузки на CPU - ActiveTargetFramerate и IdleTargetFramerate, - а один, SaveInterval, определяет, когда сервер подвисает. Остальное в производительности связано со временем: сервер, проработавший три дня, медленнее такого же свежезапущенного, и плановый перезапуск убирает больше лагов, чем любая настройка.

Эта статья о подборе ресурсов и о том, как сохранять сервер быстрым. Установка, порты и все ключи конфигурации описаны в руководстве по выделенному серверу Sons of the Forest, а устройство самого Wine - в статье Wine и Proton для серверов только под Windows. Повторять их здесь больше необходимого мы не будем.

Почему сервер тяжёлый#

Люди приходят в эту игру из The Forest, сервер которой спокойно работал в 3 ГБ, и удивляются, что продолжению нужно больше чем вдвое больше. Разницу объясняют четыре причины.

• Мир большой и загружен целиком. Остров намного больше и плотнее, чем в первой игре, а сервер хранит состояние всего, что в нём изменилось: срубленные деревья, брошенные предметы, убитых врагов, открытые контейнеры, каждое бревно и каждую палку каждой постройки. Это состояние растёт по мере того, как группа исследует мир и строит, и пока сервер работает, оно не уменьшается.
• ИИ работает на сервере. Группы каннибалов, мутанты, животные и компаньоны просчитываются сервером, а не компьютерами игроков. Чем больше активных игроков в разных местах, тем больше ИИ бодрствует одновременно, а ИИ - самая дорогая часть каждого тика.
• Строительство - это физика. Свободное строительство в Sons of the Forest размещает отдельные брёвна и доски, а не готовые детали, и проверки прочности, решающие, устоит ли конструкция, - это настоящая работа. Большая база - это тысячи объектов, каждый из которых хранится в памяти и синхронизируется с каждым подключающимся клиентом.
• Это игра на Unity, сделанная для клиента. Выделенный сервер - это игра с убранным рендерером, а не специально написанный лёгкий сервер. Многое из того, что держит в памяти клиент, остаётся и в памяти сервера.

Ничто из этого не является дефектом. Это просто цена игры такой, какая она есть, и из этого следует, что тарифы с малым объёмом памяти, подходящие для Terraria или Valheim, - неверная точка отсчёта. Общий подход - как выяснить, на что игра на самом деле тратит память и CPU, - разобран в статье CPU или RAM для игровых серверов.

RAM и CPU по числу игроков#

Endnight не публикует требования к железу для выделенного сервера, поэтому цифры ниже - это ориентиры для планирования, полученные из практики, а не официальная таблица. Они относятся ко всему процессу сервера и на Linux включают слой Wine.

Несколько пояснений к таблице:

• Память определяется скорее миром, чем числом игроков. Двое игроков с огромной базой могут занять больше памяти, чем шестеро на молодом мире. Число игроков важно потому, что люди, разбредшиеся по острову, пробуждают одновременно больше его частей, а каждый подключившийся игрок вводит в активную работу ещё больше мира.
• 8 ГБ - это минимум, а не комфортная середина. Свежий сервер будет простаивать заметно ниже этого значения, что вводит в заблуждение и заставляет покупать меньше. Смотрите на него после недели игры, а не после часа.
• CPU - это про один поток. Главный цикл симуляции на практике однопоточный, поэтому одно быстрое ядро стоит больше, чем четыре медленных. Остальные ядра берут на себя сохранение, сеть и передачу BlobSync подключающимся игрокам, поэтому два ядра - реалистичный минимум, хотя игра "всего лишь" использует одно. Почему сервер может упираться в предел, показывая 40 процентов, объясняет статья как читать загрузку CPU игрового сервера.
• Скорость диска важна в двух случаях: при загрузке мира на старте и при записи его на каждом сохранении. Установка занимает порядка 10-15 ГБ, а каждый слот сохранения - десятки мегабайт, так что ёмкость редко становится проблемой; важна задержка.

Лимит в восемь игроков заложен в игре, так что "тарифа на 16 игроков" планировать не нужно. Если вы задумались, поможет ли больший тариф серверу, у которого и так есть запас, - не поможет; общие доводы есть в статье сколько игроков помещается на сервере.

Целевая частота кадров: ActiveTargetFramerate и IdleTargetFramerate#

У сервера нет экрана, но игровой цикл он всё равно выполняет, и эти два ключа задают, сколько раз в секунду этот цикл пытается пройти. Это самое близкое к настройке tick rate, что есть в Sons of the Forest, и главный рычаг влияния на нагрузку CPU.

{  "IdleDayCycleSpeed": 0.0,  "IdleTargetFramerate": 5,  "ActiveTargetFramerate": 60,  "SaveInterval": 600}

Обратите внимание на названия. В руководствах и на форумах это иногда называют "TargetFps" или "TargetFramerate", но таких ключей в файле нет. Сервер читает ActiveTargetFramerate и IdleTargetFramerate, а неверно написанный ключ в JSON-конфигурации игнорируется, а не отвергается, поэтому опечатка здесь выглядит в точности как настройка, которая ничего не делает.

Что делает целевая частота в простое

Когда на сервере никого нет, он опускается до пяти циклов в секунду. Поэтому пустой сервер Sons of the Forest почти не потребляет CPU, а сервер, который сильно греется без игроков, - признак чего-то другого: идущего сохранения, зависшего процесса или, на Linux, сбоя самого Wine. Оставьте IdleTargetFramerate равным 5. Повышать его бессмысленно: при IdleDayCycleSpeed, равном 0.0, игровые часы на пустом сервере всё равно остановлены, и более быстрому циклу простоя просто нечего делать.

Что делает целевая частота при игроках

Когда игроки на сервере, он стремится к 60 циклам в секунду. Каждый цикл выполняет ИИ, физику и обновления мира и отправляет состояние клиентам. Если CPU не справляется, сервер просто выполняет меньше циклов, чем задано, а игроки видят это как врагов, двигающихся рывками, удары, засчитанные с опозданием, и двери или конструкции, реагирующие с паузой.

Снижение ActiveTargetFramerate - вполне законный компромисс для сервера, упирающегося в CPU. При значении 30 сервер выполняет примерно вдвое меньше работы по симуляции в секунду, и на тарифе, упирающемся в лимит CPU, результатом часто становится более плавная игра, а не худшая: стабильные 30 ощущаются лучше, чем целевые 60, которые во время схваток постоянно проваливаются до 20. Цена - более грубые обновления: движение врагов и физика обсчитываются реже, что некоторые игроки замечают в ближнем бою. Endnight не документирует, как именно реагирует на это значение каждая подсистема, поэтому воспринимайте его как параметр, который нужно проверить на своей группе.

Несколько практических правил:

• Не поднимайте значение выше 60. Клиентам это не даёт ничего, а сервер тратит CPU, которого ему и так редко хватает.
• Снижайте шагами - 60, затем 45, затем 30 - и отыграйте по сессии на каждом. Меняйте что-то одно, чтобы понимать, какое изменение помогло.
• Снижение не экономит память. Мир имеет тот же размер при любой частоте кадров. Если проблема в памяти, этот ключ её не решит.
• Значение можно задать из командной строки как -dedicatedserver.ActiveTargetFramerate "30" - именно так его открывают во многих панелях, не редактируя файл.

Общая идея - что означает целевой tick или частота кадров для сервера и почему стабильная частота лучше высокой - разобрана в статье что на самом деле означает tick rate.

Автосохранение и подвисание при сохранении#

Каждые SaveInterval секунд - по умолчанию 600 - сервер сериализует мир и записывает его в слот сохранения. На молодом мире это занимает мгновение. На зрелом мире с большой базой это заметное подвисание: секунда или больше, в течение которой всё на сервере замирает, а затем короткий откат на клиентах, пока они нагоняют состояние.

Это самая частая жалоба на "случайные лаги" на сервере Sons of the Forest, и у неё есть признак: она регулярна. Если подвисание приходит каждые десять минут, примерно в одну и ту же минуту каждого часа, - это сохранение. Подтвердить это можно, наблюдая в консоли строку о сохранении в тот момент, когда игроки жалуются.

Что с этим можно сделать:

• Смириться. Секундная пауза раз в десять минут - это цена того, что при сбое не пропадут десять минут работы. Большинство групп, узнав причину, перестают обращать на неё внимание.
• Увеличить интервал до 900 или 1200, если подвисание действительно мешает. Вы вдвое сократите частоту пауз и вдвое увеличите то, что можно потерять при некорректной остановке. Такой обмен оправдан только вместе с надёжными резервными копиями и корректными перезапусками.
• Не уменьшайте интервал ради безопасности на большом мире. 300 на мире с базой из пяти тысяч деталей означает заметную паузу каждые пять минут.
• Быстрый диск сокращает паузу, но не убирает её: основное время уходит на сбор и сериализацию состояния, а не на саму запись. Где NVMe действительно помогает, честно рассказано в статье что на самом деле меняет NVMe.

Более общие компромиссы таймеров сохранения, для этой игры и для других, разобраны в статье интервалы автосохранения игровых серверов.

Windows-бинарник и во что обходится Wine#

Endnight выпускает выделенный сервер только для Windows. На Linux, где работает большая часть игрового хостинга, его запускают под Wine (изредка под Proton), обычно с виртуальным дисплеем вроде Xvfb, поскольку среда выполнения Unity его ожидает. Настройка описана в статье Wine и Proton для серверов только под Windows; для подбора ресурсов важна именно цена.

• Память: на несколько сотен мегабайт больше, чем тот же сервер занял бы на Windows, - на серверный процесс Wine, загруженные библиотеки Windows и виртуальный дисплей. На тарифе в 12 ГБ это шум; на тарифе в 8 ГБ это часть причины, почему 8 ГБ - минимум.
• CPU: небольшая при стабильной игре, потому что код игры выполняется нативно, а транслируются только системные вызовы. Заметнее это в моменты с интенсивной работой с файлами - старт, загрузка мира и сохранения, - то есть именно тогда, когда и так бывают подвисания.
• Шум в логах: собственный диагностический вывод Wine бывает многословным. Установка WINEDEBUG=-all в окружении заглушает его и немного экономит CPU и диск на нагруженном сервере.
• Чувствительность к версии: патч игры иногда требует более нового Wine. Если сервер, до этого работавший плавно, начинает подтормаживать или падать сразу после обновления, а на Windows-хостах такого не наблюдают, первым подозреваемым становится сборка Wine.

На самой Windows ничего из этого не применимо, но Windows-сервер в простое занимает больше памяти, чем Linux-сервер вместе с Wine, так что самостоятельный хостинг на Windows-машине - не такая экономия, как кажется. Более широкое сравнение есть в статье Linux и Windows для игровых серверов.

Долгие сессии: почему сервер замедляется#

Серверы Sons of the Forest деградируют по мере аптайма. Сервер, который в понедельник вечером работает гладко, к четвергу может заметно лагать при тех же игроках и тех же действиях, а перезапуск возвращает его в норму. Этому способствует несколько факторов:

• Состояние мира накапливается. Брошенные предметы, трупы, срубленные брёвна и мусор копятся в течение сессии. Часть убирается, многое - нет, и каждый такой объект сервер отслеживает.
• Память растёт. Долго работающие серверы на Unity склонны наращивать потребление памяти за несколько дней - отчасти из-за описанного выше состояния, отчасти из-за того, что управляемая среда выполнения удерживает уже использованную память. Считать ли это утечкой или нормальным ростом, зависит от сборки и меняется от патча к патчу. Как отличить одно от другого, объясняет статья утечки памяти на игровых серверах.
• Сборка мусора дорожает. Чем больше куча, тем дольше паузы сборки, которые проявляются как короткие нерегулярные подвисания - в отличие от подвисания при сохранении, которое регулярно.
• ИИ и физика "дрейфуют". Группы врагов и симулируемые объекты, которые никак не успокоятся, продолжают расходовать CPU в местах, где никого нет.

Решение неромантичное: перезапускайте сервер по расписанию. Раз в сутки в час, когда никто не играет, подходит большинству групп; очень активному серверу на восемь игроков, возможно, нужно два раза. Перезапуск заново загружает мир из последнего сохранения, отбрасывает накопившийся мусор и сбрасывает память к исходному уровню.

Хорошая последовательность перезапуска:

1. Предупредите игроков, если ваша группа играет в разное время. Серверной команды для оповещения нет, поэтому это делается в Discord.
2. Дайте серверу остановиться корректно, чтобы он сохранился при выходе. Не убивайте процесс.
3. Сделайте резервную копию сохранения после остановки или непосредственно перед перезапуском.
4. Запустите сервер и убедитесь, что мир загрузился из нужного слота.

На RE:NODE вкладка Schedules запускает это как упорядоченные задачи по cron-выражению - резервная копия, затем действие питания Restart, - а копии хранятся вне машины, которую они защищают. Как выбрать время и частоту, рассказано в статье расписания перезапуска, которые помогают.

Читаем графики: память или CPU#

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

График памяти, который стабильно растёт в течение нескольких дней и падает при каждом перезапуске, - это нормально. График, который за считаные часы после перезапуска доходит до лимита, означает, что мир перерос тариф. График CPU, упирающийся в лимит только во время игры, - это сервер, которому нужна более быстрая или большая доля CPU либо более низкая целевая частота; а высокая нагрузка без игроков - проблема процесса, а не подбора ресурсов.

На RE:NODE консоль показывает графики памяти, CPU и диска на фоне лимитов тарифа, и именно такое сравнение вам и нужно. CPU жёстко ограничивается купленной долей: сервер на 100 процентах работает медленнее, но его никогда не приостанавливают из-за этого. С памятью иначе - на лимите контейнер останавливается и запускается заново, а не уходит в своп, что для этой игры означает потерю всего, что произошло после последнего сохранения. Если это происходит, это самый сильный сигнал перейти на тариф выше, а смена тарифа не пересоздаёт сервер и не затрагивает мир. Подробнее о формах графиков рассказывает статья как читать график нагрузки сервера, а само решение разобрано в статье когда пора менять тариф.

Диагностика медленных серверов#

Сервер лагает, но график CPU далёк от лимита. Смотрите на отдельное ядро, а не на суммарную нагрузку. Главный цикл может полностью занимать один поток, пока общий процент выглядит спокойным. В этом случае снижение ActiveTargetFramerate поможет больше, чем добавление ядер.

Все откатываются в один и тот же момент, каждые десять минут. Это автосохранение на большом мире. Проверьте в консоли строку о сохранении в момент, когда это происходит.

Лагает один игрок, а остальные нет. Это его соединение или его компьютер, а не сервер. Проблема сервера затрагивает всех в одном месте одновременно. Разобраться, что именно происходит, поможет статья задержка, джиттер и потеря пакетов.

Подключение занимает несколько минут, и сервер подтормаживает, пока кто-то заходит. Подключающийся игрок загружает состояние мира через порт BlobSync. На зрелом мире это большая передача, и пока она идёт, сервер тратит на неё силы. Это нормально, и чем больше база, тем хуже.

Память упирается в лимит, и сервер перезапускается с откатом. Миру нужно больше памяти, чем есть на тарифе, либо сервер работает слишком долго. Сначала добавьте ежедневный перезапуск; если лимит всё равно достигается в течение суток, переходите на тариф выше. Другие причины незапланированных перезапусков разобраны в статье почему игровой сервер постоянно перезапускается.

Изменение целевой частоты ничего не дало. Проверьте написание ключа и то, что файл - корректный JSON. Ошибочно написанный ключ молча игнорируется, а повреждённый файл заставляет сервер стартовать со значениями по умолчанию. Запустите с -verboseLogging, чтобы увидеть, что было прочитано.

Сервер замедлился сразу после обновления игры. Либо само обновление тяжелее, что бывает и что нельзя убрать настройками, либо на Linux сборка Wine отстала. Прежде чем что-то менять у себя, сверьтесь с другими владельцами серверов.

FAQ#

Хватит ли 8 ГБ для сервера Sons of the Forest?

Для двух-четырёх игроков на не слишком огромном мире - да. Это минимум, а не комфортный запас, и давно существующий мир с большой базой его перерастёт. Следите за памятью после недели игры, а не в первый вечер.

Вредит ли снижение ActiveTargetFramerate игровому процессу?

Немного, в обмен на стабильность. При 30 движение врагов и физика обновляются реже, что некоторые игроки замечают в ближнем бою. На сервере, который всё равно не держит 60, стабильные 30 обычно ощущаются лучше, чем нестабильные 60. Попробуйте одну сессию, прежде чем решать.

Почему мой пустой сервер почти не использует CPU?

Из-за IdleTargetFramerate. Когда никто не подключён, сервер работает на пяти циклах в секунду, а при IdleDayCycleSpeed, равном нулю, игровые часы остановлены. Так задумано, и менять это незачем.

Замедляет ли работа под Wine сервер?

Лишь слегка. Код игры выполняется нативно; Wine добавляет несколько сотен мегабайт памяти и небольшие накладные расходы на операции с файлами вроде сохранений. Лаги на сервере под Wine почти всегда вызваны собственной нагрузкой игры, а не слоем трансляции.

Как часто нужно перезапускать сервер Sons of the Forest?

Раз в сутки в тихий час подходит большинству групп. Загруженному серверу на восемь игроков может быть полезно два раза в сутки. Всегда давайте ему остановиться корректно, чтобы он сохранился, и делайте резервную копию вместе с перезапуском.

Ускорит ли сервер больше ядер CPU?

После двух-трёх ядер - редко. Симуляция опирается на один главный поток, поэтому скорость этого ядра важнее их числа. Дополнительные ядра помогают при сохранении и подключении игроков, но не в главном цикле.