Enshrouded: лагает при большой базе/поселении игроков

MAATRIX GAMES

Полгода назад сервер летал на голом энтузиазме, а теперь при заходе в зону главной базы фризит на секунду-другую, курсор в инвентаре тормозит, а в чате кто-то уже написал "у меня лагает". Знакомая история для проекта на Enshrouded, где база не заброшена, а постоянно строится: каждая новая грядка, алтарь и стена — это не косметика, а нагрузка, которая копится молча и вылезает ровно тогда, когда народу жалко всё бросать. Разберёмся, что именно проседает от застройки, что можно реально ограничить, а что — миф, и как настроить сервер под растущее поселение, а не воевать с симптомами.

Почему тормозит именно от построек, а не от версии сервера

Первое, что нужно понять: Enshrouded не подгружает мир кусками, как Minecraft чанки, которые можно выгрузить, если рядом никого нет. Здесь весь исследованный игроками мир остаётся в памяти сервера целиком, пока сервер жив — снятая пелена (Shroud) не наступает обратно, а значит, и построенное на расчищенной территории никуда не девается из RAM до следующего рестарта. Чем больше карты открыто и чем плотнее застроены открытые зоны, тем выше базовое потребление памяти, и это накапливается за недели активной игры, а не сбрасывается само.

Отдельно стоит знать: с ноября 2024 года часть владельцев серверов Enshrouded сталкивается с сообщением "Server Overloaded" / "High Server Load" даже на мощном железе с солидным запасом ресурсов — это подтверждённая особенность серверного бинарника, а не всегда признак того, что вам не хватает CPU или RAM. Если видите такое сообщение при явно свободных ресурсах — не спешите сразу апгрейдить тариф, сначала попробуйте рестарт (ниже расскажу, почему это часто помогает) и посмотрите на загрузку в динамике, а не в моменте.

Зоны Shroud (пелены) тяжелее для сервера, чем открытая поверхность — там генерируется и держится в памяти больше сущностей (враги, точки спавна, декоративные эффекты). Если ваша большая база стоит рядом с расчищенным Shroud-разломом или сама разрослась в сторону пелены, часть лагов может идти именно оттуда, а не от количества сундуков на полке.

Сколько на самом деле "весит" застройка

Официальный минимум для дедика — 8 ГБ RAM, но это комфортно только для свежего мира с парой игроков и минимумом построек. По ориентировочным наблюдениям хостеров, на каждого дополнительного игрока стоит закладывать около 100 МБ сверху база, а плотная застройка (много объектов на единицу площади: мебель, декор, факелы, грядки, животные в загонах) ест заметно больше памяти, чем такая же по площади дикая местность — точных коэффициентов Keen Games не публикует, так что ориентируйтесь на факт роста, а не на конкретный процент.

Примерные ориентиры под растущее поселение (не жёсткие цифры, а отправная точка для планирования):

Если сервер тормозит сильнее именно после захода новых игроков или при подходе к определённому участку базы — это почти всегда память, а не тикрейт: сервер не "не успевает считать", а начинает упираться в своп или GC-паузы движка. Проверить просто: free -h во время лага покажет, осталась ли реально свободная память, или сервер уже на грани.

Лимиты построек в Enshrouded: что реально ограничено

Тут придётся немного разочаровать любителей "поставить в конфиге максимум блоков" — жёсткого лимита на число объектов постройки в enshrouded_server.json нет, в отличие от некоторых других выживалок. Игра ограничивает не количество деталей, а зоны: постройка привязана к алтарю (Flame Altar) и его области действия, и внутри этой зоны формального потолка на число элементов не задокументировано — люди строят весьма масштабные комплексы без явного "капа".

Зато есть реальные ограничения, о которых стоит знать:

• Высота застройки ограничена не случайно — разработчики специально урезали возможность строить супервысокие "стартовые площадки", чтобы игроки не улетали на глайдере в любую точку карты мгновенно. Это анти-эксплойт, а не производительность, но при большой базе с несколькими высотными платформами вы можете упереться именно в этот потолок.
• Незаявленные (без огненного алтаря/факела claim) временные постройки — грядки, костровища, верстаки, поставленные во время разведки — со временем исчезают при бездействии. Это не баг: считайте это встроенной "сборкой мусора" для брошенных времянок, и на постоянную базу с закреплённым алтарём это не распространяется.
• Некоторые сюжетные и квестовые зоны заблокированы под застройку намеренно, чтобы не грифили квестовые локации на общих серверах.

Практический вывод: раз формального лимита на объекты нет, единственный реальный ограничитель — это ваша RAM и терпение игроков к фризам. "Лимит построек" на практике вводится не движком, а вами: договоритесь с командой о разумных рамках (не десять факелов подряд ради красоты, не ферма животных на сотню голов) или разнесите крупные проекты по разным алтарям, чтобы снизить плотность объектов в одной точке карты.

CPU: что важнее — частота или число ядер

Здесь принципиальный момент, который часто упускают при выборе тарифа: серверная логика Enshrouded сильно завязана на однопоточную производительность. Иными словами, высокая частота ядра (условно от 4.0 ГГц и выше) для стабильности при большой базе важнее, чем формальное число vCPU в конфигурации тарифа. Восьмиядерный процессор с низкой частотой на пике застройки может проседать сильнее, чем четырёхъядерный, но с высокими частотами на ядро.

Это же объясняет, почему вынесенный отдельный dedicated-сервер (не хостинг игры прямо с клиента одного из игроков) обычно стабильнее при росте поселения: локальный хост держит на одном потоке и клиент, и серверную логику одновременно, а отдельный dedicated-процесс использует поток исключительно под серверную часть, не деля его с рендером чьего-то клиента.

Что можно сделать практически:

• При выборе тарифа под растущий проект смотрите не только на "число ядер", но и на заявленную базовую/турбо-частоту CPU у провайдера.
• Если видите, что загрузка одного ядра стабильно выше 80% при в целом свободных остальных — это симптом именно однопоточного упора, а не повод сразу брать тариф с большим числом vCPU: поможет частота, а не количество ядер.
• Мониторить нагрузку удобно через htop (смотрите на конкретное ядро, не только на средний load average) — подробнее про то, как читать метрики нагрузки на игровом сервере, разобрано в статье про мониторинг TPS и лагов на игровом сервере, а сам выбор числа ядер под стабильный тикрейт — в статье сколько ядер CPU нужно под стабильный тикрейт.

Автосейв и диск: почему подвисает именно на сохранении

В enshrouded_server.json нет отдельного поля вроде saveInterval — интервал автосохранения не вынесен в конфиг и управляется внутренним таймером движка, который Keen Games официально не документирует и, судя по поведению между патчами, может меняться. Это значит: вы не можете напрямую "растянуть" автосейв реже через конфиг — доступный вам рычаг влияния лежит не в частоте сохранений, а в том, насколько быстро диск успевает их записать.

Именно поэтому диск — не второстепенный параметр. На HDD или медленном SSD каждое автосохранение большой застроенной базы даёт заметный фриз для всех на сервере: движок в момент записи мира на диск подвешивает тик. На NVMe тот же самый автосейв проходит практически незаметно. Если у вас сейчас сетевой или "бюджетный" диск и лаги совпадают по времени с моментами, когда все синхронно на секунду замирают (а не плавно проседает FPS) — это почти наверняка не CPU и не сеть, а именно запись сохранения.

Что касается бэкапов поверх автосейва — берите snapshot папки saveDirectory (по умолчанию ./savegame) по крону, но без остановки сервера копирование "на живую" безопаснее делать через rsync, а не tar напрямую по большому каталогу, чтобы не растянуть блокировку файлов на дольше обычного автосейва:

rsync -a --delete /home/enshrouded/enshrouded-server/savegame/ /backups/enshrouded-live/
tar -czf /backups/enshrouded-$(date +\%Y\%m\%d-\%H\%M).tar.gz -C /backups enshrouded-live

Подробный разбор установки, портов и базового конфига — в статье как поднять сервер Enshrouded, если у вас ещё не настроен systemd-юнит для автозапуска.

Практические настройки под большую базу

Раз формального "лимита построек" нет, а конфиг не даёт прямого рычага на автосейв, единственный рабочий путь — снижать общую нагрузку через то, что реально настраивается:

Понизьте slotCount до реального числа игроков, а не держите максимум 16 "про запас" — сервер резервирует ресурсы под заявленный слот-каунт, и заниженное значение под фактический онлайн снижает базовую нагрузку:

{
  "slotCount": 8
}

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

{
  "gameSettingsPreset": "Custom",
  "gameSettings": {
    "randomSpawnerAmount": "Few",
    "aggroPoolAmount": "Few"
  }
}

Плановые рестарты каждые 8-12 часов. У серверного процесса есть утечка памяти при длительной работе — это подтверждённое сообществом поведение, не разовый баг. Регулярный перезапуск через systemd-таймер снимает накопленную деградацию лучше любых точечных оптимизаций:

# /etc/systemd/system/enshrouded-restart.timer
[Unit]
Description=Плановый рестарт Enshrouded каждые 10 часов

[Timer]
OnUnitActiveSec=10h
Unit=enshrouded.service

[Install]
WantedBy=timers.target

Держите игроков и стройки территориально ближе друг к другу. Разбросанные по карте отдельные форпосты нагружают сервер сильнее, чем то же количество построек, сконцентрированное в одном-двух местах — меньше зон одновременно "живых" в памяти с активными игроками рядом.

Если поселение выросло настолько, что даже эти меры не спасают — это тот самый практический потолок, о котором честно говорят и разработчики хостингов: при по-настоящему масштабной застройке и большом онлайне сервер Enshrouded упрётся в архитектурные ограничения движка независимо от железа. В этом случае разумная опция — разнести проект на второй сервер (например, отдельная база под "дальний" регион карты) вместо бесконечного апгрейда одного инстанса; общий подход к балансировке нагрузки на игровых серверах разобран в статье оптимизация сервера под высокую нагрузку.

Частые вопросы