Сколько ядер CPU нужно под стабильный тикрейт сервера

MAATRIX GAMES

Почти каждый второй вопрос в саппорте звучит так: «у меня 8 ядер, а сервер всё равно лагает». И это не парадокс, а следствие того, как устроены игровые движки: Minecraft, Rust, ARK, FiveM и CS2 считают игровой мир одним потоком, и этому потоку плевать, сколько ещё ядер простаивает рядом. Разберём, почему так вышло, когда ядра реально нужны, и как выбрать CPU под конкретную игру, не переплачивая за ватт, который не используется.

Почему число ядер — не главное

Тикрейт — это частота, с которой сервер пересчитывает состояние мира: позиции игроков, физику, урон, ИИ мобов, крафт, редстоун. Каждый тик — это законченный расчёт, который должен уложиться в фиксированное окно времени. У Minecraft это 20 тиков в секунду, то есть 50 мс на тик. У CS2 тикрейт настраивается (обычно 64 или 128), у Rust — задаётся через конвар и по умолчанию заметно ниже клиентского, в районе 10 тиков в секунду (это ориентир, точное значение зависит от версии и настроек владельца сервера).

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

Отсюда практический вывод: если один тик не укладывается в бюджет времени, добавление ядер серверу не поможет — потому что тик считает одно ядро, а остальные в этот момент ждут. Поможет более быстрое ядро (выше частота, лучше IPC) или снижение нагрузки на сам тик (меньше мобов, меньше tile entities, меньше активных скриптов).

Что реально происходит в один тик

Возьмём Minecraft на Paper — самой распространённой сборке для выживания. Главный поток за 50 мс должен успеть: обновить всех мобов и игроков, применить редстоун-логику, обработать тайл-энтити (печи, хопперы, воронки), выполнить события плагинов, разослать пакеты клиентам. Всё это — один поток, Server thread в дампе потоков Java. Если посмотреть /timings (Paper) или профиль через spark, почти всегда видно, что 90%+ времени тика съедает именно этот поток, а не фоновые.

Похожая картина в Rust: основной game thread через движок Unity считает симуляцию, коллизии, инвентари построек. Часть задач — сериализация мира при автосохранении, декомпрессия при загрузке карты — раскидана по фоновым потокам через job-систему Unity, но сама игровая логика тика остаётся завязана на один поток, который у Facepunch исторически является узким местом на серверах с высоким онлайном.

В ARK: Survival (что оригинал, что Survival Ascended на Unreal Engine 5) ситуация ещё жёстче: ShooterGameServer печально известен тем, что забивает одно ядро в 100% почти сразу после старта, если на карте много прирученных динозавров и построек — а остальные ядра хоста в это время могут быть загружены на 10-15%.

FiveM для GTA V устроен похоже: ресурсы (Lua/JS-скрипты) выполняются кооперативно на главном потоке citizen-сервера. Один «тяжёлый» ресурс, который не отдаёт управление вовремя, тормозит вообще всё — включая ESX или QBCore.

Когда ядра всё же критичны

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

• Запросы к базе данных. FiveM-фреймворки ESX и QBCore держат почти все данные игроков в MySQL. Драйвер вроде oxmysql выполняет запросы асинхронно в пуле фоновых потоков — это не блокирует основной тик, но пул реально работает быстрее и без очередей на CPU с запасом ядер, особенно при высоком онлайне и частых сохранениях инвентарей.
• Генерация и загрузка чанков. В Minecraft генерация новых чанков и частично их загрузка с диска асинхронны с версии 1.14+, и Paper это ещё улучшил. Когда десяток игроков одновременно исследуют новую территорию, лишние ядра реально снижают фризы на границе прогруженного мира — хотя сам тик мобов и редстоуна всё равно считается в главном потоке.
• Плагины и моды с фоновой работой. Dynmap/BlueMap генерируют тайлы карты в отдельных потоках. LuckPerms синхронизирует права через сеть. Плагины бэкапов (типа автоматического сжатия мира) грузят CPU параллельно с игровым тиком — и если для них не осталось свободного ядра, они начинают конкурировать за то же ядро, что считает тик, и роняют TPS.
• Несколько независимых серверов на одном хосте. Если вы держите кластер из трёх карт ARK или два инстанса Minecraft на одной машине — это не «многопоточность одного тика», а параллельная работа нескольких независимых процессов, и здесь чем больше ядер, тем больше процессов можно развести без взаимной конкуренции.
• Античит и сетевая обработка на CS2/шутерах. Валидация пакетов, VAC-проверки, обработка голосового чата (например, Simple Voice Chat в Minecraft) чаще работают в отдельных потоках и выигрывают от лишних ядер, не трогая основной тик напрямую.

Общий паттерн: ядра решают всё, что можно посчитать «сбоку» от игрового мира. Частота решает то, что является самим игровым миром.

Частота против количества: как выбирать

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

Если хостер даёт выбор между CPU с 4 быстрыми ядрами и высоким бустом и CPU с 16 ядрами средней частоты — для одиночного игрового сервера почти всегда выгоднее первый вариант. Второй имеет смысл, только если на машине реально живут несколько процессов одновременно (кластер карт, несколько игр, БД рядом с игровым сервером).

Разбор по конкретным играм

Minecraft (Paper/Purpur, ванильная 1.21.x). Тик — строго один поток. Ядра нужны только на фоновую генерацию чанков и плагины с сетевыми/файловыми операциями. Для сборки с модами (Forge/Fabric) ситуация та же — модовые тик-хендлеры выполняются в том же главном потоке, если явно не написаны асинхронно. Проверить, кто ест тик, можно через /timings report на Paper или плагин spark (/spark profiler start — /spark profiler stop).

Rust. Основной тик — узкое место при большом онлайне (100+ игроков) и большом количестве построек на карте. Автосохранение мира и декомпрессия при загрузке частично распараллелены, но столкновения, крафт, инвентарь построек — нет. server.tickrate в консоли позволяет снизить нагрузку ценой отзывчивости, если частоты процессора не хватает.

ARK: Survival (обе версии). Самый требовательный к одному ядру движок из перечисленных — прирученные динозавры, структуры и таймеры прогрева, тухнущего мяса и т. п. считаются на главном потоке ShooterGameServer/ArkAscendedServer. На Linux-хостах администраторы иногда закрепляют процесс за самым быстрым ядром через taskset -c, чтобы исключить миграцию потока планировщиком ОС — это не ускоряет саму логику, но убирает случайные просадки от переключения ядра.

FiveM (GTA V). Ресурсы ESX/QBCore выполняются кооперативно на одном потоке — «тяжёлый» скрипт с плохо написанными циклами душит весь сервер независимо от количества ядер хоста. Асинхронные запросы к MySQL через oxmysql — исключение, они реально используют дополнительные ядра через пул соединений (mysql_connection_count в конфиге ресурса).

Counter-Strike 2. Тикрейт задаётся при запуске (-tickrate 64 или -tickrate 128 для сборок, где это разрешено) и считается на одном потоке движка Source 2; сетевые потоки и SourceTV — отдельно. 128-тик ощутимо чувствительнее к частоте ядра, чем 64-тик, именно потому, что окно на расчёт тика вдвое короче.

Если делаете выбор между несколькими играми сразу — общая методика подбора описана в статье про то, какой тариф выбрать под конкретную игру, там же логика применима и к CPU, не только к RAM.

Как понять, что упираетесь именно в CPU

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

• Linux: top или htop — смотрите загрузку конкретного ядра, а не среднюю по системе; mpstat -P ALL 1 покажет по-ядерную картину за интервал в 1 секунду.
• Windows: диспетчер задач → вкладка «Производительность» → «Ядра логического процессора» (клик правой кнопкой на графике CPU → «Изменить график» → «Логические процессоры»).
• Minecraft: команда /tps показывает тики в секунду за 1/5/15 минут; если TPS ниже 20 при не загруженном на 100% ядре — проблема, скорее всего, не в CPU (чаще в GC-паузах Java из-за нехватки heap).
• Rust/ARK: серверная консоль и RCON-команды статуса (serverinfo в Rust) показывают frametime — если он растёт синхронно с загрузкой одного ядра до 100%, это подтверждает CPU-bound.
• FiveM: resmon в консоли клиента или сервера показывает, какой именно ресурс ест время кадра сервера — часто оказывается, что «упирается в CPU» на деле означает «один плохой скрипт».

Если хочется системно разобраться с диагностикой лагов и связкой TPS/CPU/RAM — подробный разбор есть в статье про мониторинг TPS и лагов на игровом сервере, а конкретно про тикрейт CS2 — в статье почему лагает тикрейт на CS2-сервере. Если же диагностика подтвердила, что CPU действительно не хватает, но апгрейд тарифа пока не вариант — есть набор настроек и приёмов, которые снижают нагрузку на тик без смены железа, они собраны в статье оптимизация сервера под высокую нагрузку.

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