Сколько игроков выдержит игровой сервер: тикрейт как настоящий потолок

MAATRIX

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

Тикрейт — это бюджет процессорного времени в реальном времени

Тикрейт (tick rate) — количество раз в секунду, когда сервер обновляет состояние всего игрового мира: читает накопленный ввод от игроков, двигает объекты, проверяет коллизии, прогоняет физику и AI, формирует пакеты для рассылки клиентам. Число «20 Hz» или «64 Hz» в конфиге — не настройка «под плавность», а жёсткий контракт с реальным временем: сервер обязан закончить весь этот объём работы за строго отведённый интервал, и следующий тик стартует по расписанию независимо от того, готов предыдущий или нет.

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

Поэтому «сколько игроков выдержит сервер» — это в первую очередь «сколько игроков успевает обработать один тик за отведённый бюджет», а не «сколько CPU и RAM останется свободным в среднем». Средняя загрузка CPU в 40% ничего не говорит о пиковом моменте, когда десять игроков одновременно устроили бой посреди базы — именно этот момент и определяет реальный потолок.

Как считать бюджет одного тика

Бюджет тика — это деление секунды на тикрейт:

бюджет_тика_мс = 1000 / tickrate

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

Чем выше тикрейт, тем меньше остаётся времени на всё остальное. На 128 Hz есть 7,8 мс, чтобы разобрать пакеты всех клиентов, посчитать физику и коллизии, прогнать AI, собрать и разослать исходящие пакеты — и уложиться нужно с запасом, потому что часть времени съедает ОС (планировщик, прерывания, а в managed-рантаймах вроде Java у Minecraft — ещё и сборщик мусора).

Внутри бюджета расход делится примерно так:

• чтение входа — разбор пакетов, скопившихся с прошлого тика;
• симуляция — движение, физика, коллизии, взаимодействия сущностей (здесь чаще всего живёт нелинейный рост стоимости);
• логика и AI — скрипты мира, поведение NPC, таймеры, ивенты;
• сериализация и рассылка — сборка пакетов под каждого клиента, часто с учётом interest management (кому что реально видно).

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

Что происходит при превышении бюджета

Превышение бюджета не выглядит как плавная деградация «стало на 10% медленнее» — это очередь, растущая нелинейно по мере приближения утилизации к 100%.

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

Задержка сверх сетевого пинга. Пинг — это только время в пути пакета по сети. Если тик перегружен, к нему добавляется время ожидания в очереди до следующего (запоздавшего) тика. При идеальном пинге в 20 мс, но перегруженном сервере, субъективная задержка реакции может ощущаться как 100+ мс — и никакая смена локации или VPN это не исправит, потому что узкое место не в сети.

Десинхронизация. В играх с client-side prediction перегруженный сервер присылает коррекции с опозданием и пачками — клиент видит характерный «рывок назад» (rubber-banding) собственного персонажа. В lockstep-моделях (характерны для RTS и части кооперативных симуляторов, где все клиенты синхронно выполняют один и тот же шаг) весь сеанс физически не может продолжиться, пока не получен подтверждённый шаг от сервера — подвисает не тот, кто теряет пакеты, а вся сессия целиком, потому что модель по определению синхронна.

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

От чего зависит стоимость игрока в тике

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

Нелинейный рост от взаимодействий. Наивная проверка коллизий и видимости между сущностями имеет сложность порядка O(n²) от числа объектов в зоне — удвоение игроков в одной точке карты может учетверить, а не удвоить стоимость тика именно там. Поэтому 100 игроков, раскиданных по большой карте, обычно дешевле для тика, чем те же 100, собравшихся на рейд-боссе. Движки борются с этим пространственным партиционированием (grid, octree, spatial hashing), которое отсекает заведомо невзаимодействующие пары от полной проверки — но лишь отодвигает порог, а не убирает проблему.

Interest management и стоимость рассылки. Игры с большим view distance или без разбиения зоны видимости платят за рассылку пропорционально не числу игроков, а числу пар «игрок × видимая ему сущность» — тоже нелинейно растущая величина.

AI часто дороже игроков. Стоимость поведения ботов и NPC (pathfinding, принятие решений) на единицу нередко выше, чем у реального игрока, чей клиент сам считает часть логики и присылает готовые команды. Сервер с сотней мобов, гоняющих pathfinding каждый тик, может упереться в потолок при заметно меньшем числе живых игроков, чем PvP-сервер без ботов.

Однопоточность тика — архитектурный предел, а не железный. У большинства движков основной игровой цикл принципиально однопоточный: состояние мира обновляется детерминированно и последовательно, иначе клиенты начнут расходиться в результатах одних и тех же событий. Тикрейт почти никогда не масштабируется линейно от добавления ядер: сервер с большим числом ядер, но низкой частотой каждого, может держать более низкий тикрейт под нагрузкой, чем сервер с меньшим числом ядер, но лучшей однопоточной производительностью. Часть движков выносит второстепенные задачи (сеть, фоновую физику, часть AI) в отдельные потоки, но ядро игровой логики почти всегда остаётся на одном потоке — при выборе конфигурации под игровой хостинг стоит смотреть в первую очередь на частоту и IPC, а не на число ядер. Общий подход к подбору конфигурации под конкретный тип нагрузки — в статье как рассчитать конфигурацию сервера под нагрузку.

Как замерить реальную ёмкость своего сервера

Чужие цифры «сервер X держит Y игроков» посчитаны на другой карте, с другим составом активности и часто на другом железе — переносить их на свой случай бессмысленно. Рабочий путь — замерить порог на своём сервере, своей игре и своей типичной нагрузке.

1. Включите замер длительности тика. Многие Java-серверы (в духе Minecraft) умеют показывать текущий TPS и профилировать, какая система тика тратит больше всего времени; движки на нативном коде часто логируют предупреждения о превышении бюджета или дают метрики через консольные настройки. Если встроенного счётчика нет — оберните цикл тика собственным замером (start = now(); tick(); duration = now() - start) и пишите длительность в лог каждые N тиков.
2. Считайте распределение, а не среднее. Среднее время тика маскирует именно хвост распределения. Считайте p95/p99 отдельно за тихие периоды и отдельно за пиковые (бои, массовые события) — p99 в пике показывает, насколько близко вы к порогу.
3. Нагружайте синтетическими ботами волнами — пачками по 10-20, с реалистичным поведением (движение, взаимодействие с объектами, а не «висят молча»), и после каждой волны фиксируйте p95/p99 длительности тика и загрузку по ядрам.
4. Собирайте системные метрики параллельно:

top -H -p $(pgrep -f your_game_server)   # загрузка по потокам процесса
mpstat -P ALL 1                          # загрузка по ядрам физической машины
vmstat 1                                 # признаки давления на память/своп

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

1. Зафиксируйте точку, где p99 длительности тика начинает регулярно превышать бюджет. Это и есть настоящий потолок по числу игроков/сущностей для конкретной карты и активности — не точка падения сервера, а точка систематического отставания.
2. Берите рабочий лимит с запасом — половина-две трети от найденного порога, чтобы оставался резерв на всплеск активности, а не только на устойчивую нагрузку.

Та же логика — искать не факт падения, а первый систематический признак отставания от собственного расписания — работает и для других видов «настоящего потолка»; для постоянных соединений в реальном времени она разобрана в статье про потолок WebSocket-соединений: источник насыщения там другой, но методика поиска порога (волнами, с замером хвоста распределения) та же самая.

Что реально поднимает потолок, а что нет

Раз тик почти всегда упирается в один поток и в стоимость взаимодействий, а не в общий объём CPU/RAM, способы поднять потолок отличаются от типичного «добавить ресурсов».

Обычно помогает:

• снижение тикрейта до реалистичного минимума под жанр — не каждой игре нужны 128 Hz, и бюджет на тик от снижения растёт в разы;
• шардинг/инстансирование мира — несколько серверов вместо одного, каждый со своим куском карты или копией инстанса; прямое лекарство от нелинейного роста стоимости взаимодействий;
• ограничение view distance и агрессивный interest management — отправка клиенту только того, что ему реально нужно видеть;
• пространственное партиционирование в коллизиях и AI, если движок это позволяет настраивать;
• вынос второстепенной логики в отдельные потоки/процессы, оставляя главный цикл только для строго последовательной части;
• выбор процессора с упором на частоту и IPC, а не на число ядер — для однопоточного тика это даёт больше, чем удвоение ядер. Разбор того, какие сценарии упираются в число ядер, а какие в частоту одного, — в статье сколько ресурсов нужно VPS для геймера и низкого пинга.

Почти никогда не помогает само по себе:

• добавить RAM, если сервер не упирается в своп или GC-паузы;
• добавить ядра, если игровой цикл не умеет параллелиться — лишние ядра просто простаивают;
• переехать на более быстрый диск/сеть, если узкое место в CPU-времени самого тика — типичная ошибка диагностики, когда всё внимание уходит на сетевой пинг вместо серверной обработки.

Для первичной настройки выделенного сервера под конкретную игру — базовый разбор установки под Minecraft есть в статье как установить и настроить Minecraft на VPS, а общий обзор выбора VPS под игровой хостинг с низким пингом — в статье VPS для геймера и низкого пинга: что выбрать и как настроить.

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