К руководству

Документация 9.6.24

Настройки и производительность

Измеряйте нагрузку на своём сервере. Игроки, ресурсы, запись и индексы влияют на неё; нулевая задержка не гарантируется.

Сначала наблюдайте#

Сравните детекты с обычной игрой до включения kick/ban. Проверьте телепорты, возрождение и законную выдачу оружия. Сигналы клиента не дают права на деньги, оружие или администрирование.

Контролируйте дорогие операции#

Не включайте глубокие проверки и карантин без тестов. Ограничьте одновременные записи. Мост не читает игровую базу в простое, но HTTPS и другие модули потребляют ресурсы. Используйте профилировщик FiveM.

Измерение воспроизводимой нагрузки#

До изменения снимите профиль типичной сессии. Запишите игроков, artifact, версии и действия. Спокойная игра, заполненные гаражи и бой различаются. После одного изменения сравните тот же сценарий. CPU, hitch и запросы полезнее обещаний постоянного FPS.

Команды записывают ограниченную выборку. Дождитесь завершения и найдите ресурс и поток пика. Не связывайте каждый hitch с AC. Сохраните значения и сравнение приватно; короткая запись не охватывает все пики.

profiler record 500
profiler status
profiler view

tosunac_doctor

Снижение затрат с сохранением защиты#

Глубокие сканы и автоматический карантин проверяйте контролируемо. Ограничивайте одновременные записи и отключайте debug в production. Сокращение интервалов увеличивает повторную работу.

  1. Отдельно измерьте простой и чтение панели. Мост не читает игровую SQL-базу в простое, но HTTPS и другие модули потребляют ресурсы.
  2. Большие списки листайте; отказ индекса проверьте с администратором БД.
  3. Измерьте одну тестовую запись до одновременного наблюдения нескольких сотрудников.
  4. При росте нагрузки верните изменённое значение и повторите сценарий прежде других изменений.

Наказание по контексту и доказательствам#

Наблюдайте контекстные проверки и тестируйте обычную игру. Лог не означает бан всем. Проверьте персонажа, реанимацию, телепорты, полицию и скриптовое оружие. Узкая интеграция лучше постоянного исключения.

tosunac_doctor сообщает рискованные действующие значения, не меняя их. Проверьте жёсткие наказания, отключённые защиты, debug и fail-open. Панель может переопределить локальные настройки; смотрите эффективные.

Исключение может скрыть жалобы, не исправляя причину. Сохраните временные исключения, даты и скрипты. После исправления удалите исключение и сравните логи повторённого сценария.

  • Меняйте одно значение, записывая причину, проверяющего и прошлое значение.
  • Сравнивайте повторения с легитимными действиями и временем.
  • После изменения наказания, core или инвентаря тестируйте снова.
  • При новых ложных срабатываниях верните значение и исправьте причину до усиления.

Сравнивайте одинаковую нагрузку до и после#

Запишите число игроков, версии artifact, AC, framework и инвентаря, а также операции панели. Сначала измерьте спокойную сессию без запросов, затем выбор персонажа, гараж и обычный бой. profiler record 500 ограничивает запись; дождитесь её завершения по profiler status.

В profiler view определите ресурс и поток, вызвавшие пик CPU. Проверяйте повторяющиеся долгие операции и связанные hitch-предупреждения, а не только среднее. Измените один параметр и повторите сценарий с похожей нагрузкой. Для проблем в час пик нужна соответствующая сессия; несколько изменений одновременно мешают объяснить результат.

Измеряйте работу моста отдельно#

Обмен состоянием не означает постоянное чтение игроков из игровой базы в простое. Реализация держит один исходящий запрос одновременно. Обычный интервал составляет около десяти секунд; ошибки увеличивают ожидание максимум до двух минут. Это описание реализации, а не доступная настройка скорости или гарантированный срок обновления панели.

Проверьте локальное состояние командой tosunac_db_status. Сравните одну страницу игроков с замером простоя. Списки используют страницы по 25 записей и ограниченный размер ответа, а не выгрузку всей базы. При unsupported_index или schema_unavailable проверьте поддерживаемую схему и индексы с уполномоченным администратором вместо расширения запросов.

Записывайте критерии приёмки и откат#

Задайте критерии для своего сервера: отсутствие новых постоянных hitch, завершение обычного игрового процесса и объяснимые изменения времени. Единая цель FPS не учитывает устройства и другие ресурсы. Более быстрый профиль не оправдывает ложные срабатывания.

Запишите старое и новое значение, время, игроков и эффект. При росте нагрузки восстановите один изменённый параметр и повторите. Не изменяйте балансы ради измерений. Передайте поддержке очищенное описание профиля и предупреждения doctor. Затем наблюдайте обычную производственную сессию, чтобы особые условия теста не скрыли реальную нагрузку.

Отличайте единичный пик от повторяющейся работы#

Не меняйте параметры только из-за самой длинной строки. Изучите повторяющийся ресурс и поток с соответствующим действием. Однократная подготовка при входе отличается от каждого tick. Для первого открытия гаража сравните последующие. Изменение другого ресурса мешает приписать разницу только AC. Короткая запись не охватывает все часы пик.

Запишите длительность, частоту и действие вместе. Много коротких задач накапливают время, одна длинная может совпадать с hitch. Время серверного profiler не равно клиентскому FPS. Сопоставьте клиентскую задержку с серверным интервалом; сеть и assets требуют отдельной оценки. Обратитесь с очищенным фрагментом и сценарием вместо сокращения всех интервалов при неясности.

Измеряйте стоимость наблюдения#

Мониторинг и диагностика тоже создают работу. Долгая запись, множество чтений, доказательства и постоянный debug вместе мешают объяснить нагрузку. Ограничьте инструменты, затем сравните один включённый. Несколько обновляемых вкладок не улучшают измерение действия; разное время и старые результаты путают. Запись денег не инструмент нагрузки.

Укажите сессии сотрудников, экран и число доказательств. Сравните обычную сессию, чтение игрока и снимок отдельно. Отключите лишнюю диагностику и наблюдайте нормальный режим. Собирайте достаточно данных для причины, не максимум. Результат текущего сервера не гарантируется на другом оборудовании или числе игроков. Проверьте отключение временных инструментов после обслуживания.

Ведите небольшой ежедневный журнал состояния#

Каждый день примерно в одинаковое показательное время делайте короткую запись; постоянный profiler или сеансы снимков не нужны. Укажите установленную версию, число игроков, новые повторяющиеся ошибки запуска и состояние моста при необходимости. Если операция сотрудника ожидает, смотрите её статус вместо множества одинаковых чтений. Один обычный сценарий персонажа и при необходимости одна страница — меньший объём обслуживания, чем обход всей истории только ради сбора данных.

Не сохраняйте всю неизменную конфигурацию заново ежедневно. Сопоставьте новое предупреждение doctor с прежней записью и выясните причину: автоматического ремонта нет. Пересмотрите временное исключение с ответственным к назначенной дате, не придумывая автоматический срок истечения. Без новых симптомов завершите запись наблюдаемым нормальным состоянием. Для нового hitch или ошибки измерьте только соответствующее время и действие. Это рабочая привычка администратора, а не новая автоматическая задача или функция панели.

Измеряйте рост архива отдельно от нагрузки игроков#

Число сохранённых персонажей, машин и обнаружений может расти вместе с онлайном. Если архив обнаружений вырос в десять раз при прежнем количестве игроков, отдельно измерьте первую страницу логов, следующую страницу и данные известного персонажа. Если архив прежний, а онлайн вырос, исследуйте обычную игру. Не меняйте обе переменные, приписывая разницу только AC. Временные результаты панели не означают автоматическую очистку исходных таблиц банов или обнаружений.

Первый запрос может готовить метаданные таблиц, следующие используют кэш: записывайте холодные и тёплые измерения отдельно. Страницы и индексы ограничивают перенос всего архива сразу, но не устраняют рост хранилища. Измеряйте следующую страницу в том же контексте вместо повторной первой. При заметном увеличении времени ответственный за БД должен проверить планы и индексы на тестовой копии. Удаление истории, переименование таблиц или полный экспорт не являются измерением. Решение опирается совместно на объём данных, онлайн и конкретную операцию.

Регистрация событий с серверной проверкой#

Изменение исключений клиентом не создает общего серверного исключения. Локальная помощь меню/интеграций ограничена движением и видимостью; деньги, оружие и события проверяются отдельно. Широкие исключения выдаются доверенными серверными ресурсами.

Проверка прав и их отзыва#

ACE, идентификаторы администраторов и разрешения панели проверяются сервером. all — не идентификатор и не разрешение. В allowedIds нужны полные license:..., discord:... или fivem:... из серверного списка идентификаторов игрока.

  1. Выдайте тестовому администратору только нужные права.
  2. Отзовите разрешение панели и повторите проверку тем же игроком; новый интервал опроса по умолчанию около пяти секунд.
  3. Проверьте также независимые ACE/admins.lua. Телеметрия игроков онлайн не даёт прав.
  4. Обычный тестовый игрок должен остаться без доступа; чувствительные действия проверяйте на тестовых данных.
ts.AdminMenu.allowedIds = {
    "license:YOUR_EXACT_PLAYER_IDENTIFIER",
    "discord:YOUR_DISCORD_USER_ID"
}
# Examples are placeholders, not grants.

Не повторять лишний анализ после перезапуска#

При каждом запуске проверяются SHA256-отпечатки содержимого ресурсов. Неизменённые файлы и правила используют аутентифицированные результаты KVP сервера вместо повторного дорогостоящего анализа сигнатур и событий. Изменение файлов, исключений или правил запускает новый анализ. Проверка отпечатков по-прежнему читает файлы; фиксированное значение resmon не гарантируется.

  1. При обычном обновлении сохраняйте KVP-кэш; повреждённые или непроверяемые записи анализируются заново.
  2. Начальный каталог собирает явно заданные имена событий Lua/JS. Динамические имена, нечитаемые или escrow-файлы и DLL не считаются полностью проверенными.
  3. Ручная автоматическая настройка ждёт завершения анализа. Неполные, подозрительные, изменённые ресурсы и тайм-ауты не получают автоматического разрешения.
  4. На тестовом сервере проверьте вход игроков, обычную игру и действия администратора; оценивайте resmon вместе с числом игроков и нагрузкой framework.