FiveM: лаги при большом онлайне на сервере

MAATRIX GAMES

Сервер летал на 20 игроках и начал тупить на 60? Знакомая история почти для каждого RP-проекта, который вырос из друзей-тестировщиков в живое комьюнити. Проблема в том, что причин у этого может быть штук пять сразу — от кривого скрипта фреймворка до банально слабого по частоте процессора — и лечить их нужно по-разному. Разберём, куда смотреть по порядку, чтобы не гадать вслепую.

Сначала — диагностика, а не догадки

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

Базовый инструмент — встроенная клиентская команда resmon 1 (открывается по ~/F8, подключившись к серверу). Она показывает нагрузку по каждому ресурсу отдельно: CPU-время в миллисекундах и потребление памяти. Если один-два ресурса стабильно занимают львиную долю списка — вот и подозреваемый, дальше не нужно гадать по всему серверу.

Второй источник данных — вкладка Resource Monitor в txAdmin: она агрегирует нагрузку по ресурсам прямо со стороны сервера, без привязки к конкретному клиенту, и полезна, когда нужно смотреть картину не глазами одного игрока, а в целом. Там же на вкладке производительности видно общую загрузку основного потока сервера — это то число, которое многие по привычке называют «тикрейтом FXServer», хотя технически это не совсем тот тикрейт, что в шутерах (ниже разберём почему это важно понимать правильно).

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

profiler record 30 profile.json

Команда пишет детальный профиль выполнения скриптов за 30 секунд в файл, который потом можно разобрать через инструменты профилирования Cfx — это уже уровень «нашли виновный ресурс, но непонятно, какая именно функция внутри жрёт CPU».

Отдельно проверьте нагрузку на самой VPS через htop по SSH, пока сервер под живым онлайном: если CPU упирается в потолок на одном ядре, а остальные простаивают — это прямое подтверждение, что дело не в сети и не в диске, а именно в вычислительной части.

Что на самом деле называют «тикрейтом» в FXServer

Важная оговорка, которая многих сбивает с толку: FXServer устроен иначе, чем Source-движок в CS2 или подобных играх, где tickrate — это явный, свободно настраиваемый параметр запуска. У FXServer нет единого универсального конвара уровня «поставил число — получил тикрейт», который одинаково работал бы во всех билдах и версиях — это то, что реально отличается от сборки к сборке, поэтому не доверяйте статьям (включая эту), где называется конкретная цифра как истина в последней инстанции — сверяйтесь с changelog своей версии артефактов на fivem.net/builds.

То, что реально происходит: основной поток сервера (game/sync-тик) считает мир последовательно — позиции сущностей, синхронизацию через OneSync, обработку ивентов ресурсов — и делает это настолько часто, насколько успевает при текущей нагрузке. В txAdmin это отражается как общая частота обработки основного потока на графике производительности. Когда онлайн растёт, а частота этого потока проседает — вы физически видите те же симптомы, что и «низкий тикрейт» в шутерах: игроки телепортируются, взаимодействия с объектами подвисают, синхронизация машин и NPC рассинхронизируется.

Вывод простой: не гоняйтесь за мифическим «правильным значением sv_tickrate», которое где-то прописать. Гоняйтесь за тем, что реально нагружает этот основной поток — а это почти всегда OneSync-синхронизация и тяжёлые ресурсы, разберём оба пункта дальше.

OneSync и onesync_population: цена синхронизации большого онлайна

OneSync — это подсистема, без которой сервер физически не может держать больше 32 игроков (стандартный лимит легаси-режима синхронизации). Включается в server.cfg:

onesync on
sv_maxclients 64

Именно OneSync берёт на себя синхронизацию состояния мира между десятками и сотнями клиентов одновременно — сущности, машины, NPC, физику подбираемых предметов. И чем больше игроков онлайн, тем больше объектов нужно синхронизировать каждый цикл, что напрямую нагружает тот самый основной поток из предыдущего раздела.

Отдельный конвар, который стоит проверить в первую очередь на RP-серверах с высоким онлайном — onesync_population:

onesync_population true

Он отвечает за синхронизацию окружающей популяции — фонового трафика, случайных пешеходов, которых генерирует сам движок GTA V вне зависимости от скриптов вашего фреймворка. На 20-30 игроках эта нагрузка почти незаметна, но на 80-128 синхронизация ambient-population по всей карте одновременно для всех клиентов может ощутимо давить на сервер, особенно если у вас и так плотный RP-скрипт поверх. Многие крупные RP-проекты сознательно отключают или ограничивают этот трафик через собственные скрипты управления плотностью (например, снижая SetPedDensityMultiplierThisFrame и аналогичные клиентские нативные функции по зонам), оставляя серверу OneSync только то, что реально важно для геймплея — игроков, их машины, взаимодействия.

Что касается лимитов выше 48-64 игроков (режимы, которые в старых билдах FXServer требовали отдельных флагов вроде onesync_enableInfinity/onesync_enableBeyond) — в актуальных на конец 2026 года сборках эта логика периодически меняется, так что для серверов на 100+ слотов обязательно свериться с текущей документацией и changelog вашего билда, а не копировать конфиг из статьи трёхлетней давности.

Тяжёлые ресурсы: где обычно теряется CPU-время

Если resmon показывает, что 60-70% нагрузки съедает не движок, а конкретные ресурсы — это почти всегда один из трёх паттернов:

• Бесконечный луп без нормального Citizen.Wait() — ресурс, написанный на Citizen.Wait(0) там, где логике достаточно проверяться раз в секунду, съедает CPU-время на каждый(!) тик впустую. Это топ-1 причина деградации на фреймворках ESX и QBCore, особенно после установки стороннего скрипта без ревью кода.
• Синхронные запросы к базе на каждое действие игрока — если каждый клик по инвентарю или гаражу дёргает MySQL синхронно, на 20 игроках это незаметно, на 80 одновременных запросах превращается в очередь и подвисания. Решение — асинхронные обёртки (oxmysql или аналоги) и кэширование часто читаемых данных вместо запроса к базе на каждое обращение.
• Тяжёлые серверные ивенты, дублирующие работу для каждого игрока отдельно, вместо того чтобы посчитать один раз и разослать всем. Частая находка в самописных экономических и inventory-системах, которые росли инкрементально без рефакторинга.

Если у вас ESX или QBCore — прежде чем чинить свои кастомные скрипты, стоит понимать разницу в архитектуре самих фреймворков: у них разный подход к событиям и структуре данных, и то, что оптимально в одном, может быть узким местом в другом. Разбор отличий есть в статье ESX и QBCore: сравнение фреймворков. А если проблема всплыла именно после установки нового мода — процесс безопасной установки и проверки кастомных скриптов на нагрузку разобран в статье установка кастомных скриптов на FiveM.

Однопоточность: почему решает частота CPU, а не число ядер

Ключевая архитектурная особенность FXServer, которую стоит понять раз и навсегда: основная игровая логика и синхронизация через OneSync выполняются на одном главном потоке. Часть служебных задач (сеть, HTTP, некоторые фоновые операции) может уходить в отдельные потоки, но сама симуляция мира и синхронизация сущностей — последовательная работа, которая физически не размазывается по 8 или 16 ядрам, как бы ни хотелось.

Практический вывод: тариф хостинга с формально впечатляющим числом vCPU не спасёт от лагов при высоком онлайне, если частота этих ядер невысокая. Сервер с 4 сильными по частоте ядрами почти всегда обгонит по стабильности сервер с 16 ядрами низкой частоты — ровно та же логика, что и у большинства однопоточных игровых движков (то же самое, кстати, справедливо для CS2 на Source 2, если вам интересно сравнение подхода в другом жанре).

На что смотреть при выборе или апгрейде тарифа:

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

Практический чек-лист оптимизации по шагам

Если коротко резюмировать порядок действий при жалобах на лаги с ростом онлайна:

1. Снимите resmon 1 на пике онлайна и зафиксируйте топ-5 ресурсов по нагрузке.
2. Проверьте onesync_population — на плотных RP-серверах часто есть смысл ограничить фоновую популяцию через кастомные скрипты плотности.
3. Пройдитесь по топовым ресурсам на предмет Citizen.Wait(0)-лупов и синхронных запросов к базе — это чинится без смены железа.
4. Посмотрите загрузку CPU через htop во время пика — если упирается одно ядро в 100%, дальнейшая оптимизация скриптов даст меньше, чем апгрейд по частоте.
5. Если есть подозрение на конкретный тяжёлый мод — временно отключите его и сравните resmon до/после, это быстрее, чем гадать по логам.
6. Для системного контроля нагрузки на дистанции подключите постоянный мониторинг, а не разовые проверки руками — общий подход к отслеживанию TPS/лагов на игровых серверах (применимо и к FiveM с поправкой на терминологию) разобран в статье мониторинг TPS и лагов на сервере.

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