常见性能杀手

内存泄漏是导致服务器崩溃最常见的原因。未被正确垃圾回收的对象会随时间推移不断累积，直到服务器超过其分配的 RAM 并被强制关闭。请检查从未被移除的事件监听器以及无限增长的静态集合。

一个有用的测试是，内存使用量是否随玩家数量呈线性增长。如果玩家数量保持平稳，而内存使用量却在攀升，那么您遇到的是泄漏问题，而非容量问题。

CPU 密集型操作会阻塞游戏主循环并导致卡顿。物理计算、寻路算法和复杂的 AI 例程应在独立的线程上运行，或使用时间切片技术将工作分配到多个帧中。同时要注意线程竞争，因为从外部看，图表中停滞的任务与消耗高昂的任务非常相似。

读取 CPU 图表时有一点需要注意：游戏引擎在服务器初始化期间往往会出现峰值。这是正常现象。如果启动后两到三分钟内使用率仍未稳定，问题则出在您的服务器代码或分配的资源上。

网络瓶颈

过多的网络流量会耗尽服务器带宽并导致“橡皮筋”（rubber-banding）效应。每秒发送 60 次玩家位置在 10 个玩家时运行良好，但在 100 个玩家时就会失效。请实现增量压缩，仅发送发生变化的数据，并将完整的快照复制保留为去同步恢复的备用方案。

通常还有两个更低成本的优化方案。缩减复制属性上的数据类型以减小数据包大小，并将永远不会分开发生的动作合并为一个参数化的 RPC，而不是触发多个 RPC。

糟糕的 tick 率配置会导致不一致的游戏体验。与 64Hz 相比，在 20Hz 下运行的服务器会让人感觉反应迟钝，但更高的速率会消耗更多 CPU 并产生更多消息传递操作。请在服务器容量、玩家数量与 tick 率之间取得平衡。

如果网络代码优化后卡顿仍然存在，那么剩下的距离就是物理距离了。关于这一半问题的更多信息，请阅读 Edgegap 的指南：为什么更多的位置能降低延迟。

先分析，后推测

大多数团队凭直觉进行优化。而性能分析（Profiling）用数字代替了猜测。

服务器性能分析是指从专用服务器收集和分析性能数据，以了解其在真实多人游戏负载下如何消耗 CPU、内存和带宽的过程。在 Unreal Engine 中，这意味着两个工具协同工作。Unreal Trace Server 是收集器，它是一个轻量级服务，用于收集在运行时发出的跟踪数据。Unreal Insights 是查看器，您可以在其中剖析 CPU 执行、内存分配、资产加载和复制流量。

在修改任何代码之前，值得解答以下问题：

• 哪些 Actor 消耗的内存最多？什么条件会导致内存不足（OOM）崩溃？

• 哪些函数或功能正在消耗 CPU 周期？驱动因素是玩家数量、tick 率、AI、物理还是复制？

• 哪些功能主导了单次 tick 的开销？改变 tick 率如何影响模拟稳定性和网络使用？

• 是什么导致了抖动、延迟尖峰或服务器端去同步？

您可以使用 -tracefile 将跟踪数据保存到磁盘并进行离线分析，或者在开发测试期间通过 UDP 开放内部端口 1981，从运行中的部署实时流式传输数据。Edgegap 的完整演练请参阅 如何通过服务器性能分析来分析和优化 Unreal Engine 的游戏服务器。

一旦跟踪数据告诉您开销在哪里，解决方法通常是您尚未触及的构建设置。Edgegap 为该步骤准备了针对特定引擎的清单：Unreal、Unity 和 Godot。

资源监控

在游戏会话期间，持续跟踪内存使用情况、CPU 利用率和网络吞吐量。突然的尖峰表明存在优化机会，而逐渐增加则表明存在内存泄漏。

部署详情页上的容器指标涵盖了这三项。免费层级中的历史指标是以一分钟为窗口进行平均的；而在免费账户中添加卡片可以解锁一秒汇报间隔的原始、未聚合指标，这也是捕获持续三帧的尖峰所需的 resolution。

每个部署还会获得一个唯一标识符。这使您能够将测试人员关于“在第二轮结束时发生卡顿”的报告，与具体的比赛以及具体的资源曲线联系起来，无论是实时还是事后。

容器日志是您跟随堆栈轨迹找到问题代码的方式，前提是您在构建中附带了调试符号。一个经常让人防不胜防的警告：容器日志在部署停止时会被删除。请在需要之前配置好第三方 S3 日志存储，而不是在您想要查看的崩溃发生之后。

随着玩家数量的增加，数据库查询往往会成为性能瓶颈。在内存中缓存常用数据，并使用连接池来减少数据库开销。对于数据密集型操作，请考虑使用只读副本。

基础设施优化

服务器硬件直接影响性能上限。内存不足会迫使操作系统将内存交换到磁盘，从而产生严重的卡顿。CPU 核心不足则限制了并发玩家容量。

Edgegap 的编排平台可根据需求在 615 个以上的位置 动态部署实例，并实时报告每个部署的处理器、内存和网络指标。崩溃和 OOM 强制关闭会根据您的进程重启策略触发自动重启尝试，因此故障会被限制在单场比赛中，而不会影响共享实例。重启时服务器状态仍会丢失，因此值得提前决定您的会话可以重建什么，以及不能重建什么。

减少资源消耗的好处是双向的。更紧凑的服务器打包意味着更低的计算成本，而更小的实例尺寸意味着您可以负担起您真正想要的 tick 率。要更广泛地了解编排层，Edgegap 提供了 即时编排与传统编排 的对比。

调试策略

启用详细日志记录以便进行崩溃分析，同时不影响性能。异步写入日志并轮转文件，以防止磁盘空间问题。在日志条目中包含时间戳、玩家数量和资源使用情况。

使用模拟真实玩家行为的负载测试工具，在受控环境中重现问题。合成测试可以在影响真实玩家之前揭示问题，并为调试提供一致的条件。

资产流式传输和运行时加载也需要单独进行检查。在复制或保存操作期间的磁盘 I/O 尖峰和序列化开销在 CPU 和网络图表中显示，就好像它们是逻辑问题一样，这会导致团队去优化错误的系统。

验证修复效果

无法衡量的优化只是一种带有额外步骤的猜测。针对特定问题构建两个或多个变体，使用后端细分将它们提供给一小部分人群，然后对比标准化指标，并在推广之前检查差异是否具有统计学显著性。

然后不断迭代。那些在大规模下保持服务器稳定的团队，绝不是只做过一次性能分析的团队。