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

MAATRIX GAMES

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

Почему замок — это не декорация, а нагрузка на тик

В V Rising каждый элемент замка — стена, пол, мебель, станок крафта, сундук, ловушка, декоративный светильник — это отдельная сущность, которую сервер обязан учитывать на каждом тике: проверять целостность структуры (замок физически держится на территории через привязку к сердцу замка — Castle Heart), считать зону влияния, обрабатывать таймеры крафта на станках, следить за осадным состоянием во время войны кланов. Чем больше таких элементов на карте одновременно, тем больше работы серверу нужно проделывать за тот же промежуток времени.

Игра ограничивает размер территории замка через настройку CastleHeartMaxLevel в ServerGameSettings.json, которая напрямую определяет, сколько тайлов территории может занимать сердце замка на максимальном уровне прокачки. По умолчанию (уровень 6-7 в зависимости от версии игры) это уже приличная площадь, а если на сервере несколько активных кланов подняли сердца до максимума и построились впритык друг к другу — вы получаете сплошную застроенную зону на полкарты, где сервер вынужден постоянно пересчитывать состояние сотен и тысяч объектов сразу, даже если физически в замках сейчас никого нет.

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

Второй источник нагрузки: брошенные и полузаброшенные замки

Живой сервер редко теряет игроков синхронно — кто-то уходит из игры, оставляя замок стоять нетронутым месяцами, пока Castle Heart не разрушится сам по достижении лимита неактивности (если он вообще настроен). Брошенный замок продолжает существовать как полноценный набор entity ровно до этого момента — он занимает территорию, его объекты по-прежнему обрабатываются на каждом тике, просто в нём никто не открывает двери и не крафтит.

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

Диагностика: где реально узкое место

Прежде чем резать чужие постройки или менять тариф, стоит понять, что именно проседает. У V Rising нет такой богатой RCON-консоли, как у Rust или Minecraft, поэтому диагностика чуть более косвенная, но три источника всё равно стоят проверки по порядку.

Лог сервера. Флаг -logFile "./logs/server.log" при запуске (см. инструкцию по установке сервера V Rising) пишет в файл предупреждения и ошибки — в том числе сообщения о превышении времени обработки тика, если сервер начинает не укладываться в свой цикл. Регулярные записи об этом в логе — прямой сигнал, что дело не в сети и не в клиентах, а в серверной обработке.

Ресурсы хоста. Load average и потребление RAM через htop по SSH, либо график CPU в панели хостинга (в MAATRIX GAMES это видно прямо в личном кабинете сервера без консоли) — покажут, упирается ли машина в физический потолок ядра, которое обрабатывает игровую логику. V Rising, как и большинство серверов на движке Unity, плохо распараллеливает основной игровой цикл на несколько ядер — по факту решает частота одного ядра, а не их количество, так что «добавить ядер» тут работает хуже, чем «взять ядро быстрее».

Момент, когда лагает. Если просадки совпадают строго с моментом автосейва — дело в диске и настройке AutoSaveInterval/CompressSaveFiles (ниже разберём отдельно). Если лаги стабильны и не привязаны к конкретному событию, а просто растут вместе с числом построек на карте — это накопленная нагрузка от замков, о которой шла речь выше. Общий чек-лист диагностики лагов, применимый не только к V Rising, разобран в статье про мониторинг TPS и лагов на игровом сервере.

Настройка автосейва без просадок

Автосохранение в V Rising — частая причина видимых лагов на серверах с большими замками, и лечится это в первую очередь конфигом, а не железом. Ключевые поля — в ServerHostSettings.json:

{
  "AutoSaveInterval": 300,
  "AutoSaveCount": 3,
  "CompressSaveFiles": true
}

• AutoSaveInterval — интервал автосейва в секундах. На активном сервере с большими замками частый автосейв (например, каждые 60-120 секунд) означает, что сервер регулярно сериализует и пишет на диск состояние тысяч объектов — это заметно ощущается как рывок именно в момент записи. 300 секунд (5 минут) — разумный компромисс между сохранностью прогресса и частотой этих просадок; для очень крупных карт с активной застройкой имеет смысл увеличить интервал до 600-900 секунд, если риск потери 10-15 минут прогресса при краше вас устраивает.
• AutoSaveCount — сколько последних сохранений хранить одновременно (ротация). Больше значение — больше места на диске, но не влияет на нагрузку самого момента сохранения.
• CompressSaveFiles — сжатие сейва при записи снижает нагрузку на диск и объём файла, но добавляет нагрузку на CPU в момент сохранения. На NVMe/SSD с запасом по CPU выигрыш обычно того стоит; на слабом по процессору тарифе с медленным диском эффект может быть не так однозначен — стоит проверить на своём железе.

Диск здесь решает не меньше, чем CPU: автосейв на HDD или на перегруженном сетевом хранилище может подвешивать сервер на заметно дольше, чем тот же сейв на NVMe. Если после увеличения интервала просадки в момент автосейва всё ещё заметны, а сама карта не то чтобы огромная — вероятная причина именно в дисковой подсистеме тарифа, а не в конфиге.

Что можно подкрутить без сноса чужих замков

Прежде чем идти к игрокам с просьбой «снесите половину базы», есть рычаги, которые не требуют конфликтов внутри комьюнити:

• Ограничение CastleHeartMaxLevel. Снижение максимального уровня сердца замка на пару ступеней уменьшает предельный размер территории каждого клана — эффект накопится по мере того, как новые и растущие замки будут физически меньше старых. На уже существующем сервере это не сожмёт задним числом текущие постройки, но остановит дальнейший рост нагрузки от расширения.
• Лимит ClanSize. Меньший максимальный размер клана (2-3 человека вместо 6-8) на практике часто означает более компактные замки — просто потому, что меньшей группе физически не нужна такая же территория, как крупному альянсу.
• Регулярная проверка на брошенные замки. У игры есть встроенный механизм разрушения Castle Heart при долгом отсутствии владельца на территории, но конкретные тайминги и точный триггер стоит свериться в актуальной документации на момент вашей версии игры — они периодически менялись между патчами. Если механизм включён, но выставлен на очень долгий срок неактивности, имеет смысл его ужесточить через настройки сложности/выживания сервера.
• Коммуникация с кланами напрямую. Звучит не как техническое решение, но на практике часто самое быстрое: объявление в Discord сервера о ручной чистке неактивных замков через N дней предупреждения работает лучше любого автоматического таймера и не создаёт ощущения, что администрация сносит постройки без предупреждения.

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

Когда дело не в конфиге, а в тарифе

Если автосейв настроен щадяще, CastleHeartMaxLevel разумный, брошенные замки регулярно чистятся — а лаги всё равно стабильно держатся именно в часы пикового онлайна, и CPU при этом упирается в потолок выделенных ресурсов, это честный сигнал, что текущий тариф физически не тянет тот объём построек и игроков, который на нём сейчас живёт. Учитывая, что V Rising слабо распараллеливает нагрузку на несколько ядер, здесь важнее не «докинуть ядер», а взять тариф с более быстрым процессором на ядро — это даст более заметный эффект, чем просто увеличение количества vCPU.

Для сервера с растущим активным сообществом это нормальная стадия роста, а не провал администрирования: конфигурация, которая комфортно держала три небольших замка на старте сезона, объективно не обязана так же держать восемь крупных замков полгода спустя без апгрейда. Разумнее закладывать запас по CPU заранее, чем упираться в потолок в разгар клановой войны, когда объективно не до диагностики.

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