Chapter 9.8: 性能调优

首页 | << 上一章: 持久化 | 下一章: 访问控制 >>

摘要: DayZ 的服务器性能归结为三个因素：物品数量、动态事件和 mod/玩家负载。本章涵盖真正重要的设置、如何诊断问题以及什么硬件真正有用——所有内容均基于来自 400 多条 Discord 报告的真实社区数据，涉及帧率下降、延迟和不同步。

影响服务器性能的因素

根据社区数据（400 多条关于 FPS/性能/延迟/不同步的 Discord 讨论），三大性能影响因素是：

物品数量 -- types.xml 中过高的 nominal 值意味着中央经济系统每个循环需要追踪和处理更多物体。这始终是服务器端延迟的首要原因。
事件刷新 -- events.xml 中过多活跃的动态事件（载具、动物、直升机坠毁）消耗刷新/清理循环和实体槽位。
玩家数量 + mod 数量 -- 每个连接的玩家产生实体更新，每个 mod 添加引擎必须在每个 tick 编译和执行的脚本类。

服务器游戏循环以固定的 30 FPS 刻率运行。当服务器无法维持 30 FPS 时，玩家会体验到不同步——橡皮筋效应、延迟的物品拾取和命中注册失败。低于 15 服务器 FPS 时，游戏变得不可玩。

globals.xml 调优

以下是直接影响性能的参数的原版默认值：

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	服务器上感染者的总数上限。每个僵尸运行 AI 寻路。在人多的服务器上降至 500-700 可明显改善服务器 FPS。
`AnimalMaxCount`	200	动物上限。动物的 AI 比僵尸简单，但仍消耗 tick 时间。如果发现 FPS 问题，降至 100。
`ZoneSpawnDist`	300	距玩家多少米时僵尸刷新区域被激活。降至 200 意味着更少的同时活跃区域。
`SpawnInitial`	1200	CE 首次启动时刷新的物品数量。较高的值意味着更长的初始加载时间。不影响稳态性能。
`CleanupLifetimeDefault`	45	没有特定生命周期的物品的默认清理时间（秒）。较低的值意味着更快的清理周期但更频繁的 CE 处理。

推荐的性能配置（针对 40 人以上的服务器有困难时）：

xml

<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 可以完全暂停：

xml

<var name="IdleModeCountdown" type="0" value="60"/>
<var name="IdleModeStartup" type="0" value="1"/>

IdleModeCountdown=60 表示最后一个玩家断开连接后 60 秒进入空闲模式。IdleModeStartup=1 表示服务器以空闲模式启动，只有在第一个玩家连接时才激活 CE。这防止服务器在空闲时不断进行刷新循环。

调整重新刷新速率

xml

<var name="RespawnLimit" type="0" value="20"/>
<var name="RespawnTypes" type="0" value="12"/>
<var name="RespawnAttempt" type="0" value="2"/>

这些控制 CE 每个循环处理多少物品和物品类型。较低的值减少每个 tick 的 CE 负载，但减慢战利品重新刷新速度。上面的原版默认值已经很保守了。

cfgeconomycore.xml 日志

临时启用 CE 诊断日志以测量循环时间并识别瓶颈。在你的 cfgeconomycore.xml 中：

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"。这会在服务器 RPT 日志中输出 CE 循环计时。查找显示每个 CE 循环耗时的行——如果循环超过 1000 毫秒，经济系统已过载。

将 log_ce_lootspawn 和 log_ce_lootcleanup 设为 "true" 可查看哪些物品类型刷新和清理最频繁。这些是你降低 nominal 的候选对象。

诊断后关闭日志。 日志写入本身消耗 I/O，如果一直开启可能会加剧性能问题。

serverDZ.cfg 性能设置

主服务器配置文件中与性能相关的选项有限：

设置	效果
`maxPlayers`	如果服务器有困难，降低此值。每个玩家生成网络流量和实体更新。从 60 降至 40 个玩家可恢复 5-10 服务器 FPS。
`instanceId`	决定 `storage_1/` 路径。不是性能设置，但如果你的存储在慢速磁盘上，会影响持久化 I/O。

你无法更改的内容： 服务器刻率固定在 30 FPS。没有设置可以增加或减少它。如果服务器无法维持 30 FPS，它只是运行得更慢。

Mod 性能影响

每个 mod 添加的脚本类在引擎启动时编译并在每个 tick 执行。影响因 mod 质量而异：

纯内容 mod（武器、服装、建筑）添加物品类型但脚本开销极小。它们的成本在 CE 追踪，而不是 tick 处理。
脚本密集型 mod 带有 OnUpdate() 或 OnTick() 循环，每个服务器帧都运行代码。这些 mod 中优化不佳的循环是 mod 相关延迟最常见的原因。
交易/经济 mod 维护大量库存，添加引擎必须追踪的持久化物体。

指导原则

逐步添加 mod。每添加一个后测试服务器 FPS，而不是一次添加 10 个后才测试。
添加新 mod 后，使用管理工具或 RPT 日志输出监控服务器 FPS。
如果某个 mod 导致问题，检查其源代码中是否有昂贵的逐帧操作。

社区共识："物品（types）和事件刷新是最消耗性能的——添加数千条 types.xml 条目的 mod 比添加复杂脚本的 mod 影响更大。"

硬件建议

DayZ 服务器的游戏逻辑是单线程的。多核 CPU 有助于操作系统开销和网络 I/O，但主游戏循环在一个核心上运行。

组件	建议	原因
CPU	尽可能高的单线程性能。AMD 5600X 或更好。	游戏循环是单线程的。主频和 IPC 比核心数更重要。
内存	最低 8 GB，重度 mod 服务器 12-16 GB	Mod 和大地图消耗内存。内存不足会导致卡顿。
存储	必须使用 SSD	`storage_1/` 持久化 I/O 是持续的。HDD 会在保存周期中导致卡顿。
网络	100 Mbps+ 低延迟	带宽不如 ping 稳定性对防止不同步重要。

社区提示："OVH 性价比不错——约 60 美元可以租到一台专用 5600X 机器，可以处理 60 人 mod 服务器。"

避免在人多的服务器上使用共享/VPS 主机。共享硬件上的噪声邻居问题导致不可预测的 FPS 下降，而且从你的角度无法诊断。

监控服务器健康状态

服务器 FPS

检查 RPT 日志中包含服务器 FPS 的行。健康的服务器始终维持 30 FPS。警告阈值：

服务器 FPS	状态
25-30	正常。在激烈战斗或重启期间的轻微波动是正常的。
15-25	性能下降。玩家在物品交互和战斗中注意到不同步。
低于 15	严重。橡皮筋效应、操作失败、命中注册损坏。

CE 循环警告

启用 log_ce_statistics 后，注意 CE 循环时间。正常在 500 毫秒以下。如果循环经常超过 1000 毫秒，你的经济系统太重了。

存储增长

监控 storage_1/ 的大小。不受控制的增长表示持久化膨胀——太多放置的物体、帐篷或藏匿点在积累。定期清档或降低 globals.xml 中的 FlagRefreshMaxDuration 有助于控制这一问题。

玩家报告

玩家的不同步报告是你最可靠的实时指标。如果多个玩家同时报告橡皮筋效应，服务器 FPS 已降至 15 以下。

常见性能错误

Nominal 值过高

将每个物品设为 nominal=50 因为"更多战利品更有趣"会创建数万个被追踪的物体。CE 将整个循环花在管理物品上而不是运行游戏。从原版 nominal 开始，有选择地增加。

载具事件过多

载具是具有物理模拟、配件追踪和持久化的昂贵实体。原版刷新大约 50 辆载具。运行 150 辆以上载具的服务器会看到显著的 FPS 下降。

不测试就运行 30 多个 mod

每个 mod 单独运行都没问题。30 多个 mod 的复合效应——数千个额外的 types、数十个逐帧脚本和增加的内存压力——可以使服务器 FPS 下降 50% 以上。每批添加 3-5 个 mod 并在每批后测试。

从不重启服务器

一些 mod 有随时间积累的内存泄漏。安排每 4-6 小时自动重启。大多数服务器托管面板支持此功能。即使编写良好的 mod 也受益于定期重启，因为引擎自身的内存碎片化在长时间运行中增加。

忽视存储膨胀

增长到几 GB 的 storage_1/ 文件夹会减慢每个持久化循环。定期清档或修剪，特别是如果你允许没有衰败限制的基地建造。

日志一直开启

CE 诊断日志、脚本调试日志和管理工具日志都在每个 tick 写入磁盘。启用它们用于诊断，然后关闭。在繁忙服务器上持续的详细日志本身可以花费 1-2 FPS。

首页 | << 上一章: 持久化 | 下一章: 访问控制 >>

Chapter 9.8: 性能调优 ​

目录 ​

影响服务器性能的因素 ​

globals.xml 调优 ​

每个值的控制效果 ​

经济调优与性能 ​

降低 Nominal 值 ​

减少动态事件 ​

使用空闲模式 ​

调整重新刷新速率 ​

cfgeconomycore.xml 日志 ​

serverDZ.cfg 性能设置 ​

Mod 性能影响 ​

指导原则 ​

硬件建议 ​

监控服务器健康状态 ​

服务器 FPS ​

CE 循环警告 ​

存储增长 ​

玩家报告 ​

常见性能错误 ​

Nominal 值过高 ​

载具事件过多 ​

不测试就运行 30 多个 mod ​

从不重启服务器 ​

忽视存储膨胀 ​

日志一直开启 ​