Don't Starve Together: лагает при большой базе/поселении игроков

MAATRIX GAMES

Первые недели сезона сервер держится ровно даже впятером-вшестером, а потом кто-то отстраивает главный лагерь на полкарты — частокол стен, десятки грядок, курятники, шкафы, ловчие башенки — и вот уже при заходе в этот район начинает подтормаживать сама игра: анимации дёргаются, действия выполняются с задержкой в полсекунды, а автосейв ощутимо подвешивает всех сразу. DST считается лёгкой игрой по серверным меркам (не зря она стоит в каталоге с минимумом 1 ГБ RAM), и именно поэтому многие администраторы не сразу понимают, что тормозит не хостинг, а конкретно разросшийся лагерь. Разберём, откуда реально берётся эта нагрузка, что с ней можно сделать без ссор с игроками и когда дело действительно в тарифе.

Почему большая база в DST давит именно на тик

Мир DST не симулируется целиком одинаково активно во всех точках карты одновременно — движок держит полную симуляцию только вокруг тех зон, где сейчас есть игроки, а удалённые от них участки могут переходить в более пассивное состояние и заново "просыпаться", когда кто-то к ним приближается. У объектов в игре есть колбэки на пробуждение и засыпание (в моддинг-API это OnEntitySleep/OnEntityWake — это не выдуманная деталь, а реальная часть движка, которой пользуются и авторы модов), и чем плотнее застроена зона, тем дороже обходится момент, когда игрок физически заходит в её радиус активности: серверу нужно разом поднять состояние сотен объектов вместо десятка.

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

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

Что конкретно создаёт нагрузку в лагере

Не все постройки одинаково "тяжёлые" для сервера — стоит понимать разницу, прежде чем решать, что резать:

• Стены (Wall Stone, Wall Wood, Wall Hay, лунные и руинные варианты). По опыту комьюнити DST именно плотная стена из десятков-сотен секций — один из самых частых источников жалоб на подвисания при приближении к базе: у стен есть физическая коллизия, которую движок обязан обсчитывать при взаимодействии с ней, а не просто отрисовывать как декорацию.
• Фермы, курятники, грядки и другие объекты с активным таймером. Каждая грядка, растущая ферма или курятник — это не статичный спрайт, а объект с собственным таймером роста/производства, который сервер регулярно обновляет. Десяток грядок погоды не делают, но лагерь на 100+ активных ферм — уже заметная постоянная фоновая работа.
• NPC с рабочим ИИ. Свинки, мерм-деревни, ручные тени, стражи руин и другие юниты с поведением дороже статичных объектов кратно — им нужно искать путь, принимать решения и реагировать на окружение каждый тик, пока они активны.
• Заброшенные, но не разрушенные лагеря. Если игрок ушёл с сервера, а его база физически осталась стоять нетронутой (то есть постройки продолжают существовать как полноценные объекты), она продолжает создавать нагрузку ровно так же, как и активная — просто без пользы для комьюнити.

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

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

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

Лог сервера. Сервер запускается с флагом -console, а вывод стоит перенаправлять в файл или смотреть через journalctl, если сервис оформлен через systemd (см. инструкцию по установке сервера DST). В логе видно ошибки скриптов и предупреждения — регулярные записи о превышении времени обработки тика или ошибки Lua-скриптов модов прямо указывают на источник проблемы.

Ресурсы хоста. htop по SSH или график CPU в панели хостинга (в MAATRIX GAMES это видно прямо в личном кабинете без консоли) покажут, упирается ли одно ядро в потолок именно в моменты лагов. Если загрузка растёт синхронно с приближением игроков к конкретной точке карты — это подтверждает версию про базу.

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

Моды. Отдельно стоит временно отключить недавно добавленные моды и проверить, повторяется ли лаг — плохо оптимизированный мод, особенно из тех, что вешают код на OnUpdate каждого объекта на карте, может создавать нагрузку, которая выглядит один в один как "лаг от базы", но на деле не имеет отношения к постройкам вообще.

Автосейв и сохранения без лишних просадок

DST не даёт такого гибкого JSON-конфига автосейва, как некоторые другие выживачи — расписание сохранений завязано на внутреннюю логику движка, а не выставляется произвольным числом секунд через ini-файл. Что это значит на практике:

• Чем больше объектов на карте (то есть чем крупнее и плотнее лагеря игроков), тем больше данных сервер сериализует и пишет на диск при каждом сохранении — а значит, тем заметнее сама просадка в момент записи, вне зависимости от того, как часто она происходит.
• Форсировать сохранение вручную можно консольной командой c_save() — полезно перед плановым перезапуском или обновлением, чтобы не полагаться на автоматический таймер.
• Корректно завершить сервер с сохранением состояния — c_shutdown(true) вместо простого kill процесса: это гарантирует, что мир запишется целиком, а не оборвётся в незавершённом состоянии.

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

Мировые настройки и что можно подкрутить без сноса построек

Прямого административного лимита на количество построек в DST нет — в отличие, например, от плагинов защиты территории в Minecraft. Но несколько рычагов у администратора всё же есть:

• Размер мира. При создании кластера на экране кастомизации можно выбрать размер карты (от компактной до огромной) — это лучше задавать через сам клиент игры при генерации кластера, а не редактировать worldgenoverride.lua вручную: синтаксис этого файла периодически меняется между обновлениями, и ошибка в нём может сломать генерацию мира целиком. Меньшая карта физически ограничивает площадь, на которой могут разрастаться лагеря, но это решение имеет смысл только на старте нового сезона.
• max_players в cluster.ini. Меньший лимит игроков на практике часто означает и более скромный по масштабу общий лагерь — просто потому, что меньшему числу человек физически не нужна такая площадь застройки.
• Флаг -only_update_server_if_client_connected. Реальный, документированный флаг запуска дедик-сервера DST: при отсутствии подключённых игроков мир полностью останавливает симуляцию вместо того, чтобы продолжать тикать вхолостую. Прямо на нагрузку от самой базы он не влияет, но снимает фоновую нагрузку в часы, когда сервер пустует — полезно добавить в systemd-юнит рядом с -cluster и -shard.
• Регулярная чистка заброшенных лагерей. Механизм автоматического разрушения построек при долгом отсутствии владельца в ванильной игре не такой развитый, как хотелось бы, так что на практике чаще помогает ручная политика: объявление в Discord сервера о чистке нетронутых лагерей через N дней предупреждения — работает лучше любого автоматического таймера и не выглядит как снос без предупреждения.
• Мод-ограничители построек. В Steam Workshop периодически появляются пользовательские моды, ограничивающие плотность застройки в радиусе — их состав и актуальность стоит проверять отдельно перед установкой, список активно поддерживаемых вариантов меняется от сезона к сезону.

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

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

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

По памяти DST действительно лёгкая игра — минимальной планки в 1 ГБ хватает для скромного конфига с одним шардом и парой игроков (как отмечено в инструкции по установке сервера), но для кластера с пещерами, активными модами и разросшимся за сезон лагерем комфортнее закладывать заметно больше запаса — нехватка RAM на таком масштабе чаще всего проявляется не крашем, а именно подвисаниями во время сборки мусора Lua и в моменты автосейва. Разумнее увеличить тариф заранее, чем упираться в потолок в разгар сезона, когда чистить лагерь уже поздно, а разбираться с диагностикой некогда.

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