FiveM — продвинутые параметры OneSync

MAATRIX GAMES

Сервер уже поднят, фреймворк накатан, базовый onesync on в конфиге стоит с первого дня — а дальше начинаются вопросы, на которые форумные конфиги отвечают через раз: почему на 48 игроках всё ровно, а на 90 начинает плыть, нужен ли Infinity именно вам или это просто модное слово из чужого server.cfg, и что вообще делает onesync_population, кроме того что "лучше не трогать". Разберём три главных параметра синхронизации построчно — не как чинить симптомы (для этого есть отдельный разбор лагов при высоком онлайне), а как эти конвары реально устроены и когда каждый из них действительно нужен.

Три уровня синхронизации: legacy, OneSync, OneSync Infinity/Beyond

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

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

OneSync — подсистема, которая переписывает синхронизацию сущностей (игроки, машины, NPC, объекты) так, чтобы она масштабировалась за пределы 32 слотов. Включается одной строкой:

onesync on

Без неё sv_maxclients выше 32 попросту не заработает как задумано — сервер либо откажется стартовать с таким лимитом, либо (в зависимости от билда артефактов) поведение будет непредсказуемым. Первым делом при любых плясках с лимитом игроков проверяйте именно этот конвар.

OneSync Infinity / OneSync Beyond — расширенные режимы для по-настоящему большого онлайна (тот самый случай "128+ слотов и выше"). В более ранних билдах FXServer это включалось отдельными флагами вроде onesync_enableInfinity 1 или onesync_enableBeyond 1 поверх базового onesync on. Важная оговорка: в актуальных на конец 2026 года сборках эта логика периодически меняется — часть флагов объединяется, часть уходит в default-поведение самого onesync on при определённом sv_maxclients. Прежде чем копировать конкретную строчку конвара из этой или любой другой статьи — сверьтесь с changelog вашей версии артефактов на fivem.net/builds, потому что здесь риск скопировать устаревший флаг выше, чем в большинстве других настроек.

sv_maxclients: что этот лимит реально означает

sv_maxclients 64

Казалось бы, простая цифра — но на практике sv_maxclients не гарантирует, что сервер одинаково хорошо потянет заявленное число слотов. Это верхний потолок подключений, а не обещание производительности при этом потолке. Два сервера с одинаковым sv_maxclients 128 могут вести себя совершенно по-разному в зависимости от того, что происходит внутри: сколько ресурсов грузят основной поток, насколько плотный RP-скрипт поверх фреймворка, какая частота CPU у ноды.

Практический принцип, который стоит взять за правило: выставляйте sv_maxclients под реальную ожидаемую посещаемость, а не "с запасом на вырост". Раздутый лимит на 256 при среднем онлайне 40 ничего не оптимизирует и не защищает — избыточный лимит сам по себе не грузит сервер (нагрузка идёт от реально подключённых игроков), но провоцирует держать резервы по RAM и создаёт ложное ощущение, что сервер "рассчитан" на нагрузку, которую вы ни разу не тестировали вживую.

Если growth реальный и онлайн стабильно подпирает текущий лимит — поднимайте sv_maxclients постепенно, шагами, и после каждого шага смотрите на поведение основного потока через txAdmin (вкладка производительности) при живом пиковом онлайне, а не сразу прыгайте с 48 на 200.

onesync_population: фоновый трафик, который считается за всех разом

onesync_population true

Этот конвар отвечает не за игроков, а за окружение — случайных пешеходов, фоновый автотранспорт, которых движок GTA V генерирует сам по себе вне зависимости от логики вашего фреймворка. Механика важная: без OneSync каждый клиент рисует своё локальное окружение независимо (условно "у каждого своя массовка"). С onesync_population true сервер синхронизирует эту популяцию между всеми клиентами централизованно — то есть считает её один раз для всех, а не оставляет каждому клиенту генерировать своё.

Казалось бы, централизованный расчёт должен быть дешевле — и на средних онлайнах так и есть. Но при плотном RP-скрипте поверх (кастомные экономики, системы работ, спавн NPC под квесты) синхронизация ambient-популяции по всей карте для каждого клиента одновременно превращается в дополнительную статью расхода того самого основного потока, который и так занят логикой фреймворка. На 20-30 игроках это практически незаметно, но с ростом онлайна нагрузка растёт нелинейно — не потому что параметр "плохой", а потому что синхронизировать больше данных для большего числа клиентов объективно дороже.

Что реально делают крупные RP-проекты с высоким онлайном:

• Ограничивают плотность population точечно, а не глобально отключают параметр — через клиентские нативные функции вроде SetPedDensityMultiplierThisFrame и аналогичные для транспорта, снижая плотность именно в людных зонах (спавны, рынки, гаражи), где и без ambient-трафика хватает нагрузки от реальных игроков.
• Держат onesync_population true включённым, потому что полное отключение убирает и часть визуальной "живости" мира, которую многие RP-игроки прямо ожидают от сервера — это компромисс между атмосферой и производительностью, а не однозначный переключатель "выключил и стало быстрее без последствий".
• Замеряют разницу через resmon 1 до и после правки плотности на живом пиковом онлайне, а не на глаз — субъективное "вроде бы стало плавнее" часто обманывает.

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

Когда реально нужен Infinity/Beyond, а когда ещё рано

Главная ошибка, которую видно в чужих конфигах — Infinity/Beyond включают "на всякий случай" на сервере с онлайном 50-60, хотя базового onesync on для такой нагрузки более чем достаточно. Расширенные режимы решают конкретную проблему: снятие ограничений на число одновременно синхронизируемых сущностей и клиентов при по-настоящему большом онлайне, а не общее "ускорение" сервера.

Ориентировочные сигналы, что пора смотреть в сторону расширенных режимов синхронизации:

• Онлайн стабильно приближается к границе 128 слотов и вы упираетесь именно в лимиты стандартного OneSync, а не в производительность конкретных ресурсов (это разные проблемы — сначала исключите вторую через resmon).
• Плотный мир с большим числом одновременно активных сущностей — не только игроков, но и синхронизируемых машин, объектов, NPC от фреймворка — который стандартный режим не успевает уложить в лимиты сущностей на клиента.
• Вы уже прошли базовую оптимизацию — вычистили Citizen.Wait(0)-лупы, синхронные запросы к базе, тяжёлые дублирующиеся ивенты — и упираетесь именно в архитектурный потолок синхронизации, а не в кривые скрипты поверх неё.

Если ни один из пунктов не про вас — расширенные режимы синхронизации, скорее всего, добавят сложности конфигурации без ощутимой пользы: больше нагрузки на сетевой стек и память сервера ради лимитов, которые вы всё равно не упираете. Держите базовый onesync on и разберитесь сначала с ресурсами — практический разбор именно такого пути диагностики (от resmon до профилировщика FXServer) есть в статье про лаги при большом онлайне на FiveM.

Владение сущностями и culling: невидимая часть нагрузки

Помимо самих параметров конфига, на производительность синхронизации напрямую влияет то, как устроено владение сущностями (entity ownership) в OneSync. Каждая синхронизируемая сущность — машина, NPC, физический объект — в моменте "принадлежит" конкретному клиенту, который берёт на себя часть расчётов по ней (например, физику), а сервер синхронизирует итоговое состояние остальным. Это распределяет часть нагрузки с сервера на клиентов, но создаёт свой класс проблем: если клиент-владелец отключается или лагает, передача владения другому клиенту (миграция) должна пройти чисто, иначе сущность может "залипнуть" или начать вести себя рвано у всех вокруг.

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

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

Готовые связки параметров под разный онлайн

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

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

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