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

MAATRIX GAMES

На небольшом паблике на 12 слотов TF2-сервер обычно работает ровно, а стоит забить его под завязку на 24-32 игрока — начинаются рывки: хитреги засчитываются с задержкой, ракеты Солджера летят дёрганно, крутки Хэви на полном каст-баре ощущаются иначе, чем должны. Дело почти никогда не в «слабом хостинге» как общей формулировке, а в конкретной вещи — серверный движок не успевает пересчитывать мир на каждом тике при возросшей нагрузке от игроков. Разберём, что реально влияет на плавность симуляции TF2 при большом онлайне: тикрейт, серверный fps_max, сетевые конвары и какой CPU под это в принципе нужен.

Почему сервер захлёбывается именно при росте онлайна

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

Симптом почти всегда один: сервер физически не успевает досчитать тик за отведённое время (интервал ~15 мс), и начинает отставать. Игроки при этом видят не «низкий пинг/высокий пинг», а именно рваную симуляцию — противник телепортируется на пару кадров, попадание в упор не засчитывается, гранаты взрываются не там, где ожидалось визуально. Это не проблема сети между клиентом и сервером, а нехватка вычислительных ресурсов на стороне самого сервера — и лечится она не «более быстрым интернетом», а настройками симуляции и, в конечном счёте, процессором.

Тикрейт в TF2: фиксированный не просто так

TF2 — движок Source первого поколения, и по умолчанию сервер симулирует мир с фиксированным интервалом тика interval_per_tick 0.015, то есть около 66.67 тика в секунду. Это не настраиваемый параметр в том смысле, в котором тикрейт настраивают на выделенных серверах CS2 (-tickrate 64/128) — там разработчик официально поддерживает несколько режимов. В TF2 движок технически позволяет передать -tickrate через параметр запуска srcds (это общий для Source-движка флаг), но комьюнити почти единогласно не рекомендует его трогать.

Причина простая: игровая механика TF2 — критические удары, ракетные прыжки Солджера, отдача от воздушного взрыва (airblast) Пиро, сплеш-урон гранат Демомена — тонко подогнана под стандартный интервал тика. На нестандартном тикрейте физика начинает вести себя иначе, чем задумывали разработчики: прыжки получаются другой высоты, отталкивание работает непредсказуемо, а часть плагинов SourceMod, написанных с расчётом на 66 тиков, может выдавать баги. Если вы пришли из CS2, где тикрейт сервера — обычная тема настройки, в TF2 логика другая: лучше оставить тикрейт как есть и искать плавность через другие рычаги — ниже как раз о них.

fps_max: главный рычаг серверной плавности

В отличие от тикрейта, серверный fps_max — это то, что реально стоит крутить. Этот конвар ограничивает, сколько раз в секунду процесс сервера обрабатывает внутренний игровой цикл. Если fps_max установлен слишком низко относительно тикрейта, сервер начинает «пачками» досчитывать несколько тиков за один проход цикла вместо равномерной обработки — а это как раз и ощущается игроками как рывки и нестабильный хитрег, даже если формальный тикрейт не менялся.

Задать значение можно прямо в server.cfg или параметром запуска:

fps_max 300

или в скрипте старта:

./srcds_run -game tf -console -port 27015 +map cp_dustbowl +maxplayers 24 +exec server.cfg +fps_max 300

Конкретное число — не универсальная константа, а вопрос баланса между плавностью и нагрузкой на CPU: чем выше fps_max, тем чаще сервер прогоняет игровой цикл и тем больше ест процессорного времени. На практике многие держат fps_max в диапазоне 300-500 на боевых 24-32-слотовых серверах — это ориентир из опыта комьюнити, а не результат замера на конкретном железе, и его стоит подбирать под свой сервер, поднимая постепенно и проверяя нагрузку через stats в консоли. Значение 0 снимает ограничение вовсе, но на выделенном сервере это обычно не нужно и просто прожигает CPU впустую, особенно если рядом крутятся другие процессы.

Сетевые конвары: updaterate, cmdrate, maxunlag

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

sv_minupdaterate 20
sv_maxupdaterate 66
sv_mincmdrate 20
sv_maxcmdrate 66
sv_maxunlag 1

• sv_maxupdaterate — сколько обновлений состояния мира в секунду сервер максимум отправляет клиенту. Задирать это значение выше реального тикрейта (66) бессмысленно — сервер физически не может отдать больше снапшотов, чем сам просчитал.
• sv_maxcmdrate — то же самое, но про частоту, с которой сервер принимает команды от клиента. Рассинхрон между cmdrate и updaterate не критичен, но держать их равными реальному тикрейту — разумный дефолт.
• sv_maxunlag — окно лаг-компенсации при проверке попаданий (сервер «отматывает» назад позицию противника с учётом пинга стрелка). Стандартное значение — около секунды; уменьшать его ради экономии CPU можно, но это компромисс не в пользу игроков с высоким пингом — попадания у них станут засчитываться менее охотно.

На большом онлайне разумно не задирать updaterate/cmdrate выше реального тикрейта сервера (это не даёт выигрыша, только лишний сетевой трафик и нагрузку), а maxunlag трогать только если CPU реально в потолке и другие меры не помогли.

CPU: частота ядра решает больше, чем число ядер

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

На практике это значит: если тариф хостинга рекламирует «8 vCPU», а сервер всё равно захлёбывается на большом онлайне — смотрите не на количество ядер, а на:

Ориентировочно под 24-32-слотовый сервер с несколькими плагинами SourceMod стоит закладывать 2-3 vCPU с упором на частоту, а не набор ядер ради самого набора — но это отправная точка для подбора тарифа, а не результат бенчмарка. Подробнее логика выбора числа ядер под стабильный тикрейт разобрана в статье сколько ядер CPU нужно под стабильный тикрейт — рассуждение там общее для Source-игр и применимо к TF2 напрямую.

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

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

net_graph 1

Строка tick покажет интервал обновлений, который реально шлёт сервер — если тикрейт не трогали, он должен держаться около 15 мс стабильно, без частых скачков. var — разброс между тиками; постоянно высокий var при заполненном сервере — верный признак, что сервер не успевает считать равномерно.

Достовернее смотреть на сам сервер. В консоли (по RCON или прямо на машине) команда:

stats

покажет реальный CPU load, использование памяти и фактический FPS сервера — сравните его с тем, что задано в fps_max. Если заданное значение и фактическое сильно расходятся именно при заполнении сервера игроками, а не в одиночку — это подтверждает, что дело в нагрузке от онлайна, а не в разовом баге конфига. Общая методика разделения «тормозит симуляция» и «проблема с сетью» разобрана в статье про мониторинг TPS и лагов на игровом сервере — там же про то, как логировать нагрузку не вручную, а по расписанию.

Отдельно проверьте плагины: если на сервере стоит SourceMod, отключите по одному свежедобавленные плагины (sm plugins unload имя.smx) и сравните stats до и после — плагин, который выполняет тяжёлую логику каждый тик вместо использования таймеров, легко может быть причиной просадки именно при большом онлайне, а не в одиночку на тесте.

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