Insurgency: лагает при большом онлайне

MAATRIX GAMES

На 6-8 игроках сервер летает, а стоит набраться полным составом 20-24 человека — начинаются рывки, задержка отклика на выстрел и ощущение, что противник телепортируется на полкорпуса. Знакомая картина для админов Insurgency (2014, Source engine), и в 9 случаях из 10 дело не в канале и не в объёме RAM, а в том, что сервер физически не успевает пересчитывать тики так быстро, как нужно при полном онлайне. Разберём, что тут реально можно подкрутить, а что упирается в железо.

Почему сервер лагает именно при росте онлайна

Insurgency — командный шутер, где каждый игрок добавляет серверу работы: позиция, ввод, попадания, физика гранат и пробитие укрытий пересчитываются на каждом тике для каждого клиента. На 6 игроках движок с этим справляется без проблем даже на скромном железе. На 20+ объём вычислений на тик растёт нелинейно — добавляются пересечения хитбоксов, звуковые события, синхронизация состояния между всеми клиентами разом.

Source-движок (та же линия, что у CS:S, DoD:S, Insurgency и их наследников) в своей основе однопоточный: логика симуляции тика идёт последовательно, а не параллелится по ядрам процессора. Поэтому симптом «на малом онлайне всё гладко, на полном — лаги» почти всегда указывает на то, что сервер упирается в потолок одного ядра CPU, а не в нехватку RAM или пропускной способности канала. RAM и сеть, конечно, тоже стоит проверить, но начинать разбор нужно именно с тикрейта и загрузки CPU.

Тикрейт: что это и как он связан с плавностью

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

Как и другие игры на Source, Insurgency поддерживает запуск с параметром -tickrate, максимум — 128 (это верхний предел, который держит движок Source в принципе). По опыту серверных админов, дефолт при обычном запуске без явного указания параметра — около 64 тиков в секунду; точное значение стоит перепроверять на своей сборке, а не полагаться на память или чужие конфиги. Важный нюанс: тикрейт — это не FPS клиента и не пинг игрока, а отдельная серверная метрика. Можно иметь отличный пинг 20 мс и при этом просевший тикрейт — и хитреги всё равно будут «не засчитываться», потому что сервер не успевает пересчитать мир так часто, как заявлено.

Сам по себе высокий тикрейт не панацея: если под него не хватает CPU, сервер, настроенный на 128, реально может отдавать 60-80 с просадками — и тогда заявленное значение существует только в конфиге, а не в реальности.

Смотрим реальные цифры: как проверить, что творится на сервере

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

stats

Она показывает загрузку CPU, использование памяти и фактическую частоту тиков — сравните это число с тем, что реально прописано в скрипте запуска. Если в параметрах стоит -tickrate 128, а stats стабильно показывает 60-70 под нагрузкой — сервер не тянет заявленную частоту, и это не баг отображения.

Со стороны клиента (полезно попросить нескольких игроков на пике онлайна) включается сетевая статистика:

net_graph 1

В правом нижнем углу появляется блок с параметрами: tick — интервал обновления, на который реально ориентируется клиент, var — вариация между тиками (чем ближе к нулю, тем стабильнее), loss/choke — это уже больше про сеть, чем про тикрейт. Если var держится высоким долго, а не только в моменты гранатных взрывов и толкучки на точке — это симптом, что сервер не успевает считать тики равномерно именно под нагрузкой. Общий подход к разделению «тормозит симуляция» и «проблема с сетью» подробнее разобран в статье про мониторинг TPS и лагов на игровом сервере — логика диагностики универсальна для шутеров на Source.

Настраиваем tickrate и сетевые конвары под высокий онлайн

Если проверка подтвердила, что тикрейт реально просаживается, для начала убедитесь, что параметр запуска явно прописан, а не оставлен на дефолт:

./srcds_run -game insurgency +exec server.cfg -port 27015 -maxplayers 24 -tickrate 64

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

В server.cfg вместе с тикрейтом имеет смысл выровнять сетевые конвары — если они занижены относительно тикрейта, сервер физически режет обновления, даже если сама симуляция успевает:

sv_maxupdaterate 64
sv_minupdaterate 20
sv_maxcmdrate 64
sv_mincmdrate 20
sv_maxrate 0
sv_minrate 0

• sv_maxupdaterate — сколько обновлений мира в секунду сервер максимум шлёт клиенту, логично держать не выше тикрейта
• sv_maxcmdrate — как часто клиент присылает свой ввод серверу
• sv_maxrate/sv_minrate — ограничение полосы на клиента; 0 снимает верхний предел и отдаёт решение клиенту, но на переполненном канале хостинга иногда полезнее явно ограничить, чтобы один клиент с плохим интернетом не тянул закачку у остальных

После правки конфига обязательно перезапустите сервер и перепроверьте через stats, что значения реально применились — server.cfg подхватывается при старте через +exec, но старый процесс продолжает жить со старыми значениями до рестарта.

CPU: почему частота ядра важнее их числа

Это ключевой момент, который чаще всего упускают при выборе тарифа. Раз симуляция тика в Source — последовательная работа одного потока, сервер с 8 слабыми виртуальными ядрами почти всегда проиграет серверу с 4 ядрами, но высокой частотой на ядро и хорошим IPC. Добавление ядер не ускоряет пересчёт одного тика — оно помогает только побочным вещам вроде обработки сети или античит-проверок, которые всё равно вторичны по сравнению с самой симуляцией.

На практике при выборе железа под Insurgency с прицелом на 20-24 игрока стоит смотреть в первую очередь на:

Честно: если процессор слабый или хостинг сильно переподписан по CPU, никакие конвары из предыдущего раздела не вылечат просадку тикрейта до конца — можно только сгладить симптомы (снизить лимит слотов, уменьшить тикрейт под реальную мощность). Подробный разбор того, сколько ядер и какая частота реально нужны под стабильный тик, — в статье сколько ядер CPU нужно под стабильный тикрейт. Похожая логика (однопоточная зависимость от частоты) актуальна и для соседних Source-игр — например, в материале про лаги тикрейта на CS2-сервере разобрана та же диагностика на другом движке той же линии.

Боты, карты, моды и постоянный мониторинг

Кроме CPU и тикрейта, на нагрузку при большом онлайне влияет ещё несколько вещей, которые легко упустить:

• Боты (bot_quota) — если держите гибридные лобби с ботами при неполном онлайне игроков, помните, что каждый бот считается сервером как полноценная сущность с ИИ и добавляет вычислительную нагрузку на тик. При заполнении слотов реальными игроками стоит снижать квоту ботов до нуля.
• Карты с тяжёлой геометрией — уровни с большим числом разрушаемых объектов, дверей, скриптованных событий требуют больше вычислений на тик, чем компактные карты вроде Sinjar. Если онлайн растёт, а лагает конкретно на одной-двух картах — дело может быть не в тикрейте вообще, а именно в карте.
• Плагины и моды через Workshop, если такие используете — неоптимизированный скрипт, дёргающий тяжёлые операции каждый тик вместо таймера, забирает время у самой симуляции. Если лаги появились после установки нового плагина — временно отключите его и сравните показания stats.
• mp_maxplayers — не задирайте лимит слотов выше того, что реально тянет ваше железо на выбранном тикрейте; лучше стабильные честные 20 слотов, чем рваные 32.

Для регулярного контроля, а не разового замера, полезно смотреть загрузку CPU процесса сервера через top/htop прямо во время пиковых часов онлайна и держать под рукой journalctl -u insurgency -f, если сервер оформлен как systemd-сервис — так видно, не падает ли он молча в моменты нагрузки. Если сервер только разворачиваете и настраиваете с нуля, базовые шаги — от установки через SteamCMD до systemd-автозапуска — описаны в статье как поднять сервер Insurgency.

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