Лаги на большой карте Rust

MAATRIX GAMES

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

Почему worldsize — это не просто "больше метров"

Параметр server.worldsize задаёт сторону квадратной карты в игровых единицах — от 1000 (совсем тесная) до теоретических 6000+, хотя на практике мало кто уходит выше 4500-5000. Проблема в том, что рост worldsize — это не линейный, а примерно квадратичный рост площади: карта 4500 занимает не в полтора раза больше места, чем 3000, а почти в 2,25 раза. И каждая единица этой площади — это не просто визуальный рельеф, а данные, которые серверу нужно держать в памяти и периодически пересчитывать: процедурно сгенерированные ноды ресурсов (деревья, камни, металлические и серные залежи), monuments со своим лутом и NPC, зоны радиации, маршруты анимал-спавнов.

При процедурной генерации сервер на старте буквально строит весь этот мир в память целиком, а не подгружает его кусками по требованию, как это делают некоторые другие игры. Отсюда и время генерации карты при первом запуске — на worldsize 3500 это обычно 3-10 минут в зависимости от CPU, а на 4500+ может уйти заметно дольше. Чем больше карта, тем больше объектов серверу нужно держать в оперативной обработке одновременно, даже если физически на ней сейчас играет всего 20 человек, а не 100 — пустая, но большая карта уже тяжелее, чем плотная, но компактная.

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

Второй источник нагрузки: постройки, которые не исчезают сами

Даже если вы всё рассчитали под конкретный worldsize на старте вайпа, нагрузка на сервер не статична — она растёт в течение всего цикла жизни карты. Причина простая: игроки строят. Каждая дверь, шкаф, стена, турель, автоматическая ферма на конвейерах (conveyor-система крафта и сортировки) — это отдельная сущность (entity), которую сервер обязан обсчитывать каждый тик: коллизии, состояние, таймеры распада.

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

Регулярные вайпы — это не только про "надоела старая карта", это ещё и прямой сброс накопленной нагрузки от построек. Если у вас на сервере уже настроена кастомная экономика и вы думаете о балансе между удержанием прогресса игроков и техническим здоровьем сервера, стоит заглянуть в статью про экономику сервера Rust через плагины — там как раз разбирается, что решение сбрасывать или сохранять баланс при вайпе влияет не только на геймплей, но и на то, насколько быстро карта снова обрастёт entity после рестарта.

Диагностика: смотрим, что реально происходит

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

FPS сервера через консоль. В серверной консоли Rust текущий FPS обсчёта тика виден прямо в заголовке окна процесса, а команда server.fps в консоли или через RCON выводит это значение явно, без необходимости смотреть на заголовок. Ориентируйтесь на стабильность, а не на разовое число: если FPS ровно держится в районе привычных для вашего железа значений и проседает только в пиковые часы онлайна — это про нагрузку от игроков и построек. Если FPS низкий даже почти без игроков на пустой в остальном карте — вероятнее сама генерация мира (worldsize) или проблема в конкретном плагине.

Количество активных сущностей. RCON-команда serverinfo показывает текущее число entity на карте вместе с онлайном — если это число стабильно и заметно растёт от недели к неделе на одной и той же карте без вайпа, вы наблюдаете именно накопление построек, о котором шла речь выше.

Ресурсы хоста. Load average и потребление RAM через htop по SSH, либо график CPU/RAM в панели хостинга (в MAATRIX GAMES это видно прямо в личном кабинете сервера без консоли) — покажут, упирается ли машина в физический потолок, или ресурсов ещё достаточно, а проблема в логике самого тика. Подробный разбор диагностики лагов, применимый не только к Rust, но полезный как общий чек-лист — в статье про мониторинг TPS и лагов на игровом сервере.

Если по всем трём пунктам ресурсов достаточно, а FPS всё равно просажен — ищите виновника среди плагинов Oxide/uMod (плохо написанный плагин-мост экономики или античита может незаметно жрать время тика) или среди слишком агрессивных настроек спавна ресурсов.

Балансируем размер карты и слоты под реальный тариф

Здесь стоит быть честным с собой на этапе планирования, а не после жалоб игроков: worldsize и maxplayers нужно выбирать под тариф, который у вас реально есть, а не под то, что "может пригодится в будущем".

Ориентировочные связки, которые на практике работают стабильно (точные цифры зависят от количества плагинов и стиля застройки вашего комьюнити, это не строгая формула):

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

Настройки запуска, влияющие на этот баланс, подробно разобраны в статье про установку Rust-сервера — там же таблица с портами и системными требованиями под разный размер карты.

Что реально можно подкрутить без смены тарифа

Прежде чем резать worldsize или повышать тариф, есть бесплатные рычаги, которые стоит проверить:

• Регулярная чистка брошенных построек. Плагин уровня decay-менеджера или ручная проверка раз в несколько дней снимает часть нагрузки от баз игроков, которые давно не заходили — постройка без активного владельца всё равно продолжает существовать как entity до истечения таймера распада.
• Лимиты на количество построек на игрока/группу через плагин. Жёсткий, но рабочий способ не дать одной активной группе застроить половину карты фермами и турелями.
• Аккуратность с плагинами, спавнящими объекты. Кастомные ивенты, дополнительные лутбоксы, фермы через плагины экономики — каждый добавленный источник объектов на карте стоит проверять отдельно на предмет того, не плодит ли он entity быстрее, чем они распадаются.
• server.saveinterval не слишком частый. Слишком короткий интервал автосохранения на большой заполненной карте — это регулярные просадки FPS именно в момент записи сейва, особенно на HDD вместо SSD/NVMe.

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

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

Если вы прошли диагностику, почистили карту, проверили плагины — а FPS сервера всё равно стабильно просажен именно в часы пикового онлайна, и CPU при этом упирается в 90-100% выделенных ресурсов — это честный сигнал, что текущий тариф физически не тянет выбранную связку worldsize и maxplayers, а не что где-то в конфиге спрятана ошибка. Для сервера с активным сообществом на большой карте это нормальная стадия роста, а не провал администрирования: сервер, который держал 30 человек на 3000-й карте, объективно не обязан так же держать 100 человек на карте 4500 без апгрейда CPU и RAM.

Здесь разумнее заранее закладывать запас, а не расширяться до предела и упираться в потолок в самый неподходящий момент — например, во время ивента или на пике популярности после апдейта.

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