Мониторинг TPS и лагов на игровом сервере

MAATRIX GAMES

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

Три разных "лагает": тики, сеть, клиентский FPS

Первое, с чего стоит начать любую диагностику — развести три независимых явления, которые игроки называют одним словом.

Тик-лаги (tick lag) — сервер не успевает обсчитать игровой мир за отведённое время. У каждой игры с постоянным игровым временем есть свой тикрейт: Minecraft считает 20 тиков в секунду (по 50 мс на тик), Source-движок (CS2, TF2, Left 4 Dead 2) обычно работает на 64 или 128 тиках в зависимости от настроек сервера, Rust и большинство survival-игр держат собственный внутренний цикл обновления мира. Когда сервер не укладывается в бюджет времени на тик — это ощущается как рывки, задержка реакции мира на действия игрока, замедленный респавн.

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

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

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

Встроенная диагностика в разных играх

У большинства серверных игр есть собственные команды или консольные метрики для тиков — начинать стоит с них, а не с внешнего мониторинга.

Minecraft (Paper/Spigot и форки): команда /tps показывает три значения — среднее за 5 секунд, 1 минуту и 5 минут. Норма — стабильные 19.5-20. Если у вас именно Minecraft и тема глубже, чем общий обзор — есть отдельная разборная статья про оптимизацию модов и TPS на Minecraft-сервере с профайлером spark и конкретными настройками spigot.yml — здесь принцип общий для всех игр, там — конкретика именно под Minecraft.

Source-движок (CS2, TF2, L4D2, Insurgency): в консоли сервера команда stats покажет текущую загрузку CPU сервера и FPS тика; на клиенте net_graph 1 выводит пинг, потери пакетов (loss) и choke — забитость канала. Разница между loss и choke важна: loss — пакеты реально потерялись по дороге, choke — клиент или сервер не успевает их обработать вовремя, это уже про производительность, а не про сеть.

Rust: серверная консоль показывает FPS сервера прямо в заголовке окна или через RCON-команду serverinfo — там же видно количество активных объектов (entities) и текущий онлайн. Rust особенно чувствителен к количеству построек и предметов на карте, это частый источник просадки FPS сервера при большом населении.

ARK: Survival (Evolved/Ascended) и подобные survival-песочницы: встроенных команд диагностики тиков заметно меньше, чем у Minecraft или Source — на практике админы чаще опираются на общий мониторинг ресурсов хоста и на RCON-команды для подсчёта существ и построек (getgamelog, сторонние ASA/ASE-менеджеры). Если сервер с модами — учтите, что каждый мод добавляет свою нагрузку на тик, и вычислить виновника без исключения по одному бывает сложнее, чем в Minecraft со spark-профайлером.

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

Логи сервера: что искать

Логи — второй источник правды, особенно когда встроенные команды диагностики недоступны или не объясняют причину.

Что искать в первую очередь:

• сообщения о нехватке памяти (OutOfMemoryError для Java-серверов вроде Minecraft, Out of memory или падения с кодом выхода по сигналу OOM-killer для нативных серверов на Linux);
• прямые предупреждения о просадке тика — например, в Minecraft это строка Can't keep up! Is the server overloaded?, у других движков формулировки отличаются, но суть одна: сервер сам сообщает, что не успевает;
• повторяющиеся ошибки от плагинов/модов — стектрейсы, зацикленные варнинги каждую секунду часто означают, что конкретный плагин ест процессорное время впустую;
• разрывы соединений и таймауты RCON — если админ-консоль периодически отваливается, это косвенный признак, что основной процесс сервера подвисает под нагрузкой.

Логи обычно лежат в папке logs/ рядом с исполняемым файлом сервера (Minecraft — logs/latest.log), либо выводятся в консоль процесса и доступны через панель хостинга или journalctl, если сервер запущен как systemd-сервис на своей VPS. Смотрите не только на момент жалобы игрока, но и на 5-10 минут до неё — часто проблема нарастает постепенно (утечка памяти, накопление сущностей), а не возникает внезапно.

Ресурсы хоста: CPU/RAM и почему это не то же самое, что "игра тормозит"

Здесь важно чётко разделить: тормозит ли игра из-за своей логики (тик-лаг при достаточных ресурсах) или сервер физически упирается в потолок выделенных CPU/RAM. Это разные проблемы с разными решениями.

Проверка на Linux-сервере через SSH:

htop

Смотрите на:

• Load average — если значение стабильно выше количества выделенных ядер, процессор не справляется с общей нагрузкой;
• % CPU конкретного процесса сервера — если один процесс жрёт 100% одного ядра постоянно, а не пиково, это явный сигнал упора в CPU;
• Использование RAM — если сервер вплотную подошёл к лимиту и активно уходит в swap (строка Swp в htop растёт) — это почти гарантированно источник рывков и подвисаний, потому что своп на порядок медленнее оперативной памяти.

Если у вас управляемый тариф в панели хостинга — не обязательно лезть в SSH: у большинства панелей игровых серверов, включая MAATRIX GAMES, есть встроенный график потребления CPU/RAM прямо в личном кабинете сервера, без необходимости поднимать консоль вручную.

Здесь стоит быть честным: если сервер стабильно потребляет 90-100% выделенного CPU в часы пиковой нагрузки при разумных настройках — это не баг конфигурации, а сигнал, что тарифа не хватает под текущее количество игроков/контента, и никакая оптимизация конфига физически не создаст дополнительное процессорное время из воздуха. В этом случае единственное честное решение — апгрейд тарифа сервера на более мощный.

Типичные причины лагов

Если диагностика выше указала на реальную проблему (не сеть, не клиентский FPS), вот с чего обычно начинать поиск виновника — по убыванию частоты:

1. Слишком много активных сущностей/объектов на карте. Фермы мобов в Minecraft, накопленные постройки и предметы в Rust, большое число прирученных существ в ARK — каждая единица требует обсчёта каждый тик. Чем больше построек и NPC/мобов накопилось за долгую жизнь сервера без чистки — тем тяжелее становится каждый тик со временем.
2. Тяжёлые плагины, моды или скрипты. Плохо написанный или устаревший плагин может съедать непропорционально много времени тика относительно того, что он делает. Для серверов с плагинами (Rust на Oxide/uMod, Minecraft на Paper) стоит проверить — есть разбор установки и первых плагинов в статье про Oxide/uMod для Rust, там же принцип «добавляй по одному и проверяй» работает для любой игры с плагинной системой.
3. Слишком много игроков для текущего тарифа. Онлайн, который сервер физически не тянет по CPU — самая частая причина стабильной, а не эпизодической просадки.
4. Сетевые проблемы, а не серверные. Если жалуется один-два игрока, а остальные не замечают проблем — вероятнее всего, дело в их маршруте до дата-центра, а не в сервере. Здесь помогает tracert (Windows) или traceroute/mtr (Linux/macOS) с клиентской машины до IP сервера — если потери пакетов видны на конкретном промежуточном узле маршрута, это не то, что чинится настройками игрового сервера. В таких случаях иногда помогает просто выбор ближе расположенной локации хостинга к основной аудитории игроков — например, между UK, US и RU-регионами разница в пинге для игроков из конкретной страны может быть заметной.
5. Раздутые для конкретной игры настройки прогрузки/дистанции. Там, где применимо (view-distance-подобные параметры), избыточный радиус прогрузки контента вокруг игроков — постоянный источник лишней нагрузки, которая растёт нелинейно с увеличением радиуса.

Как снизить нагрузку: практические рычаги

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

• Лимиты на количество объектов. Где игра это позволяет — ограничивайте максимум сущностей/построек на карте или на игрока. В модовых и плагинных сборках это обычно настраивается в конфиге самого мода или через отдельный плагин очистки (для Minecraft — периодический /kill дропнутых предметов, для Rust — лимиты на количество построек в скрипте на Oxide/uMod).
• Снижение view-distance / render-distance там, где применимо. Не все игры вообще имеют этот параметр, но там где есть (Minecraft, некоторые survival-игры на кастомных серверных биндах) — это один из самых быстрых способов уменьшить нагрузку без изменения правил игры.
• Регулярная очистка накопленного мусора. Заброшенные постройки неактивных игроков, горы дропа, старые чанк-лоадеры — банальная уборка карты раз в 1-2 недели снимает часть нагрузки почти бесплатно.
• Обновление и пересмотр плагинов/модов. Заброшенный или устаревший плагин, который никто не обновлял под текущую версию игры, — частый скрытый источник лагов. Проверка актуальности установленных плагинов/модов — рутинная, но недооценённая мера.
• Плановые перезапуски. Для серверов с утечками памяти (когда RAM постепенно растёт без явной причины) регулярный рестарт раз в сутки — грубый, но рабочий костыль, пока не найдена коренная причина утечки.
• Проверка совместимости модов между собой — актуально не только для Minecraft, но и для, например, ARK с большим количеством структурных модов: разбор популярных сборок есть в статье про топ модов для ARK: Survival, логика отбора и тестирования там применима к любой модовой игре.

Если после всех этих шагов сервер всё ещё упирается в потолок CPU в часы пик — это уже не зона конфига, а честный сигнал для апгрейда тарифа.

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