Valheim лагает в определённых биомах — как исправить

MAATRIX GAMES

Группа спокойно бегает по Meadows и Black Forest, а стоит зайти в Plains или добраться до Mistlands — начинаются рывки, персонажей подёргивает, атаки долетают с задержкой. Первая мысль — "хостинг слабый", но если в лугах и лесу всё гладко, дело не в тарифе вообще, а в том, что именно эти биомы устроены иначе и грузят сервер сильнее остальных. Разберём, почему так происходит, как отличить настоящую проблему от разовой просадки и что реально можно подкрутить, прежде чем нести деньги за апгрейд.

Почему именно Plains и Mistlands грузят сервер сильнее других биомов

Valheim не подгружает мир целиком — он разбит на зоны примерно 64×64 метра, и активными (то есть по-настоящему просчитываемыми сервером) становятся только те зоны, где рядом есть игрок. Пока вы стоите в Meadows, сервер обсчитывает несколько соседних зон вокруг вас — и всё, остальной мир "спит". Проблема в том, что не все зоны одинаково "тяжёлые", даже если их количество одно и то же.

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

Итог такой: на одинаковом количестве активных зон Plains и Mistlands требуют от сервера больше вычислений просто потому, что в каждой такой зоне физически больше сущностей, которые нужно держать в памяти, синхронизировать между игроками и периодически пересчитывать. Meadows и Black Forest в среднем ощутимо реже подводят именно поэтому — не из-за какой-то отдельной "оптимизации" этих биомов разработчиками, а из-за более редкой изначальной генерации.

ZDO и мировая симуляция: что на самом деле считает сервер каждый тик

Ключевое понятие в архитектуре Valheim — ZDO (Zone Data Object). Это единица состояния, которая закреплена практически за каждым объектом мира, у которого есть какое-то изменяемое состояние: деревом, которое можно срубить, камнем ресурса, мобом, сундуком, стеной постройки, брошенным предметом. Чем больше активных ZDO одновременно требует внимания сервера, тем больше циклов уходит на их обработку и синхронизацию с клиентами каждый тик мировой симуляции.

Активные зоны с высокой плотностью объектов (тот же Mistlands) естественным образом дают больше ZDO на квадратный метр, чем разреженные Meadows. А застроенный Plains добавляет к природным ZDO ещё и десятки-сотни ZDO от построек — каждая стена, дверь, сундук, точило, кузница — это отдельная синхронизируемая единица, причём постоянная, в отличие от моба, который может деспавниться.

Отдельный нюанс: когда несколько игроков одновременно находятся в разных "тяжёлых" биомах — скажем, один в Mistlands фармит чёрный металл, другой строит ферму в Plains — сервер держит активными сразу несколько плотных кластеров зон параллельно, и нагрузка от них не усредняется, а складывается. Это ощутимо отличается от ситуации, когда вся группа идёт компактно по Meadows — там активна, по сути, одна зона нагрузки на всех.

Как проверить, что дело именно в биоме, а не в чём-то другом

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

Простой полевой тест. Соберите группу и пройдите одним и тем же составом через несколько биомов подряд: Meadows → Black Forest → Plains → Mistlands. Если лаги стабильно начинаются именно на границе Plains или Mistlands и стабильно проходят при возврате в Meadows — это подтверждает биом-зависимую природу проблемы, а не разовый сетевой сбой или проблему на стороне конкретного клиента.

Ресурсы хоста. Загляните в мониторинг CPU/RAM хостинга (в панели MAATRIX GAMES это видно прямо в кабинете сервера без консоли) в момент, когда группа заходит в тяжёлый биом. Если CPU резко подскакивает к потолку выделенных ресурсов именно в этот момент — вы видите прямое подтверждение нагрузки от активных зон. Общий подход к диагностике лагов и метрикам, которые стоит смотреть в первую очередь, подробно разобран в статье про мониторинг TPS и лагов на игровом сервере — принципы там применимы и к Valheim, хотя сама игра не даёт консольных TPS-метрик так же прямолинейно, как некоторые другие проекты.

Размер файла мира. Файлы <world>.db и <world>.fwl растут по мере исследования карты — чем больше зон когда-либо были активны хотя бы раз, тем больше данных сервер хранит и подгружает при старте. Если мир взрослый (много недель активной игры, вся карта исследована) и весит уже сотни мегабайт — сама подгрузка и периодическое сохранение такого файла становится заметно тяжелее, чем у свежего мира, независимо от текущего биома игроков.

Однопоточность серверного процесса. Стоит держать в голове: движок Valheim исторически не умеет эффективно раскидывать мировую симуляцию по нескольким ядрам — основная нагрузка ложится на один поток. Поэтому в моменты пиковой нагрузки в тяжёлом биоме решает не количество ядер на тарифе, а частота одного ядра. Если на графике видно, что загружено только одно ядро почти в потолок, а остальные простаивают — это подтверждает данную особенность, а не повод считать сервер "слабым" в целом.

Чистим накопленное: заброшенные базы, порталы, склады

Даже если сейчас в мире активно играет 3-4 человека, а не 10, старый мир может тащить на себе застройку от игроков, которые давно не заходят, или от старых экспериментальных баз, которые никто не сносил.

• Ревизия заброшенных построек. Если кто-то из группы вышел из игры на постоянной основе, а его база в Plains осталась стоять с полным набором грядок и заборов — это чистая нагрузка без пользы. Договоритесь с группой снести то, что точно не используется, особенно крупные фермы с десятками отдельных объектов (каждая грядка, забор, ограда — свой ZDO).
• Лишние порталы. Сеть порталов удобна, но каждый — тоже постоянный объект. Сеть из 15-20 порталов, разбросанных по всей карте ради удобства, добавляет фоновую нагрузку, которая почти никогда не оправдывает себя по сравнению с 4-5 ключевыми точками (база, шахта, торговец, ближайший данж).
• Склады и сундуки-мусорки. Привычка сваливать всё лишнее в сундуки рядом с базой "на всякий случай" незаметно превращает базу в десятки сущностей с инвентарём. Разовая уборка перед активным ивентом или боссом снимает часть нагрузки без всякого вайпа.
• Сброс неиспользуемых аванпостов. Если группа когда-то ставила временный лагерь в Mistlands для фарма и забросила его после получения нужных ресурсов — такой лагерь продолжает быть активной зоной с постройками при каждом визите в биом, даже мимоходом.

В отличие от игр с регулярным принудительным вайпом карты, в Valheim мир не сбрасывается сам — вся накопленная застройка остаётся навсегда, если её не убрать руками. Это удобно для прогресса, но требует периодической ревизии, если карта уже взрослая.

Настройки сервера, которые реально помогают

Valheim не даёт админу прямых рычагов вроде view distance или simulation distance, знакомых по другим играм — сервер сам решает, какие зоны активировать вокруг игроков. Но несколько параметров всё же влияют на общую стабильность именно в моменты пиковой нагрузки.

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

./valheim_server.x86_64 -name "MyServer" -port 2456 -world "Dedicated" \
  -password "supersecret1" -public 1 \
  -saveinterval 1800 -backups 4 -backupshort 7200 -backuplong 43200

• -saveinterval — интервал автосохранения в секундах. Слишком частое сохранение на взрослом, тяжёлом мире добавляет регулярные микро-просадки от записи на диск; 1800 секунд (полчаса) — разумный баланс для большинства групп, реже 3600 — тоже нормально, если группа небольшая.
• -backups / -backupshort / -backuplong — управляют тем, как часто создаются короткие и длинные резервные копии поверх обычного сохранения; на медленном диске лишние копии — это лишняя нагрузка на I/O, стоит не плодить их без нужды.

Если сервер работает через BepInEx с установленными модами — стоит отдельно проверить, не добавляет ли кто-то из модов лишний спавн объектов (кастомные фермы, дополнительные крафтовые станции с эффектами) именно в тяжёлых биомах: один неаккуратно написанный мод способен создать больше нагрузки, чем сама механика игры. Разбор безопасной установки модов через BepInEx — в статье про установку модов на сервер Valheim.

Также не помешает свериться с общими принципами подготовки сервера к росту нагрузки — лимиты ОС, баланс между процессами, мониторинг ресурсов — в статье про оптимизацию сервера под высокую нагрузку: она не заточена под Valheim конкретно, но базовые принципы диагностики железа применимы к любой игре с постоянным миром.

Когда решает только апгрейд ресурсов

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

Ориентировочные связки, которые на практике работают стабильно (это не строгая формула — многое зависит от того, насколько активно группа застраивает Plains и как часто ходит в Mistlands):

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

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