Глава 9.8: Настройка производительности
Главная | << Назад: Персистентность | Далее: Контроль доступа >>
Краткое содержание: Производительность сервера в DayZ сводится к трём вещам: количество предметов, динамические события и нагрузка от модов/игроков. Эта глава охватывает конкретные настройки, которые имеют значение, способы диагностики проблем и какое оборудование действительно помогает -- всё на основе реальных данных сообщества из 400+ отчётов Discord о падениях FPS, лагах и рассинхронизации.
Содержание
- Что влияет на производительность сервера
- Настройка globals.xml
- Настройка экономики для производительности
- Логирование cfgeconomycore.xml
- Настройки производительности в serverDZ.cfg
- Влияние модов на производительность
- Рекомендации по оборудованию
- Мониторинг здоровья сервера
- Типичные ошибки производительности
Что влияет на производительность сервера
По данным сообщества (400+ упоминаний FPS/производительности/лагов/рассинхронизации в Discord), три главных фактора производительности:
- Количество предметов -- высокие значения
nominalвtypes.xmlозначают, что Центральная Экономика отслеживает и обрабатывает больше объектов каждый цикл. Это стабильно является причиной номер один серверных лагов. - Спавн событий -- слишком много активных динамических событий (транспорт, животные, крушения вертолётов) в
events.xmlпотребляют циклы спавна/очистки и слоты сущностей. - Количество игроков + количество модов -- каждый подключённый игрок генерирует обновления сущностей, и каждый мод добавляет скриптовые классы, которые движок должен компилировать и выполнять каждый тик.
Игровой цикл сервера работает с фиксированной частотой 30 FPS. Когда сервер не может поддерживать 30 FPS, игроки испытывают рассинхронизацию -- телепортацию, задержку подбора предметов и сбои регистрации попаданий. Ниже 15 серверных FPS игра становится неиграбельной.
Настройка globals.xml
Вот ванильные значения по умолчанию для параметров, напрямую влияющих на производительность:
<var name="ZombieMaxCount" type="0" value="1000"/>
<var name="AnimalMaxCount" type="0" value="200"/>
<var name="ZoneSpawnDist" type="0" value="300"/>
<var name="SpawnInitial" type="0" value="1200"/>
<var name="CleanupLifetimeDefault" type="0" value="45"/>Что контролирует каждое значение
| Параметр | По умолчанию | Влияние на производительность |
|---|---|---|
ZombieMaxCount | 1000 | Предел общего количества заражённых на сервере. Каждый зомби работает с ИИ поиска пути. Снижение до 500-700 заметно улучшает серверные FPS на заполненных серверах. |
AnimalMaxCount | 200 | Предел для животных. У животных более простой ИИ, чем у зомби, но они всё равно потребляют время тика. Снизьте до 100, если видите проблемы с FPS. |
ZoneSpawnDist | 300 | Расстояние в метрах, на котором зоны зомби активируются вокруг игроков. Снижение до 200 означает меньше одновременно активных зон. |
SpawnInitial | 1200 | Количество предметов, которые CE спавнит при первом запуске. Более высокие значения означают более длительную начальную загрузку. Не влияет на стабильную производительность. |
CleanupLifetimeDefault | 45 | Время очистки по умолчанию в секундах для предметов без определённого lifetime. Более низкие значения означают более быстрые циклы очистки, но более частую обработку CE. |
Рекомендуемый профиль производительности (для серверов с проблемами при 40+ игроках):
<var name="ZombieMaxCount" type="0" value="700"/>
<var name="AnimalMaxCount" type="0" value="100"/>
<var name="ZoneSpawnDist" type="0" value="200"/>Настройка экономики для производительности
Центральная Экономика работает в непрерывном цикле, проверяя каждый тип предмета на соответствие целям nominal/min. Больше типов предметов с более высокими nominal -- больше работы за цикл.
Снижение значений nominal
Каждый предмет в types.xml с nominal > 0 отслеживается CE. Если у вас 2000 типов предметов со средним nominal 20, CE управляет 40 000 объектами. Снизьте nominal по всей линейке для уменьшения этого числа:
- Обычные гражданские предметы: снизьте с 15-40 до 10-25
- Оружие: держите низкими (ванильные уже 2-10)
- Цветовые варианты одежды: рассмотрите отключение ненужных вариантов (
nominal=0)
Снижение динамических событий
В events.xml каждое активное событие спавнит и мониторит группы сущностей. Снизьте nominal в событиях транспорта и животных, или установите <active>0</active> для ненужных событий.
Использование режима ожидания
Когда нет подключённых игроков, CE может полностью приостановиться:
<var name="IdleModeCountdown" type="0" value="60"/>
<var name="IdleModeStartup" type="0" value="1"/>IdleModeCountdown=60 означает, что сервер входит в режим ожидания через 60 секунд после отключения последнего игрока. IdleModeStartup=1 означает, что сервер запускается в режиме ожидания и активирует CE только при подключении первого игрока. Это предотвращает работу циклов спавна на пустом сервере.
Настройка скорости респавна
<var name="RespawnLimit" type="0" value="20"/>
<var name="RespawnTypes" type="0" value="12"/>
<var name="RespawnAttempt" type="0" value="2"/>Эти значения контролируют, сколько предметов и типов предметов CE обрабатывает за цикл. Более низкие значения снижают нагрузку CE на тик, но замедляют респавн лута. Ванильные значения по умолчанию уже консервативны.
Логирование cfgeconomycore.xml
Включите диагностические логи CE временно для измерения времени циклов и выявления узких мест. В вашем cfgeconomycore.xml:
<default name="log_ce_loop" value="false"/>
<default name="log_ce_dynamicevent" value="false"/>
<default name="log_ce_vehicle" value="false"/>
<default name="log_ce_lootspawn" value="false"/>
<default name="log_ce_lootcleanup" value="false"/>
<default name="log_ce_statistics" value="false"/>Для диагностики производительности установите log_ce_statistics в "true". Это выводит время циклов CE в серверный RPT-лог. Ищите строки, показывающие, сколько времени занимает каждый цикл CE -- если циклы превышают 1000 мс, экономика перегружена.
Установите log_ce_lootspawn и log_ce_lootcleanup в "true", чтобы увидеть, какие типы предметов спавнятся и удаляются наиболее часто. Это ваши кандидаты на снижение nominal.
Отключите логирование после диагностики. Запись логов сама по себе потребляет ввод-вывод и может ухудшить производительность при постоянном включении.
Настройки производительности в serverDZ.cfg
Основной конфигурационный файл сервера имеет ограниченные опции, связанные с производительностью:
| Настройка | Эффект |
|---|---|
maxPlayers | Снизьте, если сервер не справляется. Каждый игрок генерирует сетевой трафик и обновления сущностей. Переход с 60 на 40 игроков может вернуть 5-10 серверных FPS. |
instanceId | Определяет путь storage_1/. Не является настройкой производительности, но если ваше хранилище на медленном диске, это влияет на ввод-вывод персистентности. |
Что нельзя изменить: частота тиков сервера фиксирована на 30 FPS. Нет настройки для её увеличения или уменьшения. Если сервер не может поддерживать 30 FPS, он просто работает медленнее.
Влияние модов на производительность
Каждый мод добавляет скриптовые классы, которые движок компилирует при запуске и выполняет каждый тик. Влияние сильно различается в зависимости от качества мода:
- Контентные моды (оружие, одежда, здания) добавляют типы предметов, но минимальную скриптовую нагрузку. Их стоимость в отслеживании CE, а не в обработке тиков.
- Скриптоёмкие моды с циклами
OnUpdate()илиOnTick()выполняют код каждый серверный кадр. Плохо оптимизированные циклы в таких модах -- самая частая причина лагов от модов. - Моды торговцев/экономики, поддерживающие большие инвентари, добавляют постоянные объекты, которые движок должен отслеживать.
Рекомендации
- Добавляйте моды поэтапно. Тестируйте серверные FPS после каждого добавления, а не после добавления 10 сразу.
- Мониторьте серверные FPS с помощью админ-инструментов или вывода RPT-лога после добавления новых модов.
- Если мод вызывает проблемы, проверьте его исходный код на дорогие операции в каждом кадре.
Консенсус сообщества: "Предметы (types) и спавн событий наиболее требовательны -- моды, добавляющие тысячи записей types.xml, вредят больше, чем моды с сложными скриптами."
Рекомендации по оборудованию
Игровая логика сервера DayZ однопоточна. Многоядерные процессоры помогают с системными накладными расходами и сетевым вводом-выводом, но основной игровой цикл работает на одном ядре.
| Компонент | Рекомендация | Почему |
|---|---|---|
| Процессор | Максимальная однопоточная производительность. AMD 5600X или лучше. | Игровой цикл однопоточен. Тактовая частота и IPC важнее количества ядер. |
| ОЗУ | Минимум 8 ГБ, 12-16 ГБ для серверов с большим количеством модов | Моды и большие карты потребляют память. Нехватка вызывает подвисания. |
| Хранилище | SSD обязателен | Ввод-вывод storage_1/ для персистентности постоянен. HDD вызывает фризы во время циклов сохранения. |
| Сеть | 100+ Мбит/с с низкой задержкой | Пропускная способность менее важна, чем стабильность пинга для предотвращения рассинхронизации. |
Совет сообщества: "OVH предлагает хорошее соотношение цены и качества -- около $60 USD за выделенную машину с 5600X, которая справляется с 60-слотовыми модовыми серверами."
Избегайте общего/VPS-хостинга для заполненных серверов. Проблема "шумного соседа" на общем оборудовании вызывает непредсказуемые падения FPS, которые невозможно диагностировать с вашей стороны.
Мониторинг здоровья сервера
Серверные FPS
Проверьте RPT-лог на строки, содержащие серверные FPS. Здоровый сервер стабильно поддерживает 30 FPS. Пороговые значения предупреждений:
| Серверные FPS | Состояние |
|---|---|
| 25-30 | Нормально. Незначительные колебания ожидаемы во время интенсивных боёв или перезапусков. |
| 15-25 | Ухудшение. Игроки замечают рассинхронизацию при взаимодействии с предметами и в бою. |
| Ниже 15 | Критическое. Телепортация, невыполнение действий, регистрация попаданий сломана. |
Предупреждения о циклах CE
С включённым log_ce_statistics следите за временем циклов CE. Норма -- менее 500 мс. Если циклы регулярно превышают 1000 мс, ваша экономика слишком тяжёлая.
Рост хранилища
Мониторьте размер storage_1/. Неконтролируемый рост указывает на раздувание персистентности -- слишком много размещённых объектов, палаток или тайников накапливается. Регулярные вайпы сервера или снижение FlagRefreshMaxDuration в globals.xml помогают контролировать это.
Отчёты игроков
Отчёты игроков о рассинхронизации -- ваш самый надёжный индикатор в реальном времени. Если несколько игроков одновременно сообщают о телепортации, серверные FPS упали ниже 15.
Типичные ошибки производительности
Слишком высокие значения nominal
Установка каждого предмета на nominal=50, потому что "больше лута -- веселее", создаёт десятки тысяч отслеживаемых объектов. CE тратит весь свой цикл на управление предметами вместо работы игры. Начинайте с ванильных nominal и увеличивайте выборочно.
Слишком много событий транспорта
Транспорт -- дорогие сущности с физической симуляцией, отслеживанием вложений и персистентностью. Ванильная версия спавнит около 50 единиц транспорта всего. Серверы с 150+ единицами транспорта видят значительное падение FPS.
Запуск 30+ модов без тестирования
Каждый мод нормален в отдельности. Суммарный эффект 30+ модов -- тысячи дополнительных типов, десятки скриптов на каждый кадр и увеличенное давление на память -- может снизить серверные FPS на 50% и более. Добавляйте моды пачками по 3-5 и тестируйте после каждой пачки.
Отсутствие перезапусков сервера
У некоторых модов есть утечки памяти, которые накапливаются со временем. Планируйте автоматические перезапуски каждые 4-6 часов. Большинство хостинг-панелей поддерживают это. Даже хорошо написанные моды выигрывают от периодических перезапусков, потому что собственная фрагментация памяти движка увеличивается при длительных сессиях.
Игнорирование раздувания хранилища
Папка storage_1/, выросшая до нескольких гигабайт, замедляет каждый цикл персистентности. Делайте вайп или обрезку периодически, особенно если вы разрешаете строительство баз без лимитов распада.
Логирование оставлено включённым
Диагностическое логирование CE, логирование отладки скриптов и логирование админ-инструментов записываются на диск каждый тик. Включайте их для диагностики, затем отключайте. Постоянное подробное логирование на загруженном сервере может стоить 1-2 FPS само по себе.
Главная | << Назад: Персистентность | Далее: Контроль доступа >>