两台实例都能看到相同的玩家峰值，不代表它们能稳定承载相同人数。社区服玩家峰值与实例规格的容量测算，关键是把“在线人数”转换成同一工作负载下的 CPU、内存、网络和延迟表现；规格更高也不一定线性增加容量。
先统一比较条件，再谈人数
比较前固定游戏版本、地图或存档、插件与模组、视距、玩法和运行时长。还要明确峰值是短时涌入，还是持续在线：登录、生成新区域、团战等活动可能带来不同负载。比如 Valheim 多人世界与 Counter-Strike 2 社区对局的负载构成并不相同，不能把一种玩法测出的每实例人数直接套给另一种。
建议记录四类指标：CPU使用率及单核是否长期饱和；内存占用与是否发生交换；网络吞吐、丢包和抖动；玩家侧延迟。若能采集 p95 延迟（95%的观测值不高于该值），比只看平均延迟更容易发现高峰卡顿。
用相同负载做分档压测
- 建立基线：选择低、中、高三档在线人数，尽量使用真实地图、常见玩法和日常插件。记录每档人数及上述指标，避免只测空场或刚启动的短时状态。
- 逐档增加人数：每档稳定运行约15至30分钟作为起步观察窗口；复杂玩法或资源生成明显的服应延长。每次只改变人数，其他配置保持一致。
- 标记拐点：当延迟明显恶化、CPU持续接近满载、内存不足或网络出现丢包时，记录发生问题前一档的稳定人数。短暂尖峰不宜单独判定为容量上限。
- 换规格复测：在相同软件、数据和测试步骤下比较实例。这样才能判断提升来自更多可用核心、更快的单核性能、更大内存，还是网络条件改善。
按最先触顶的资源估算
容量上限由最早成为瓶颈的资源决定，而不是把 CPU、内存和带宽的估算人数取平均。可以用同一负载下的实测比例作初算：若某档人数为 N，CPU使用率为 U，粗略的 CPU 理论人数约为 N×目标使用率÷U。这个结果只适用于负载近似线性、同一配置与玩法；遇到单线程瓶颈、地图生成或插件负载突变时，不能外推。
| 观察结果 | 优先检查 | 判断与行动 |
|---|---|---|
| CPU高，延迟随人数上升 | 单核性能、主线程负载 | 先降低高开销玩法或插件影响，再测试更快的核心；单纯增加内存通常无效。 |
| 内存接近可用上限 | 进程占用、缓存、交换活动 | 检查是否随运行时间持续增长；确认真实需求后再扩容，不能只依据启动后的占用推算。 |
| 资源尚有余量但玩家卡顿 | 网络丢包、抖动、磁盘读写和服务端延迟 | 定位是实例链路、存档读写还是游戏逻辑，避免把所有问题都归因于规格。 |
最终可承载人数应低于压测中首次不稳定的档位。作为起步策略，可让日常峰值较该拐点保留约20%至30%的资源余量；这不是通用保证，活动波动大、存档写入频繁或插件较多时应留得更多。社区服玩家峰值与实例规格的容量测算，最终应以目标玩法、持续时长和可接受延迟共同确定，而不是只看实例名称或标称核心数。
常见问题
相同峰值人数，为什么小规格也可能暂时正常？
峰值可能持续很短，且玩家所在区域、动作和插件负载不同。短时在线数不能代表持续承载能力，应观察高峰期间及之后的指标。
实例规格翻倍，容量能否也翻倍？
不能直接这样推算。若瓶颈在单核性能、磁盘或网络，增加其他资源未必提高人数上限；必须在相同负载下复测。
要以哪个指标作为扩容信号？
看最先触顶且与玩家体验相关的指标，例如持续CPU饱和、内存压力、丢包或 p95 延迟恶化，并结合日志确认原因。
结论多久复核一次？
游戏版本、地图、插件或玩法有明显变化后应重新压测；日常也可对比高峰时的资源和延迟记录，发现趋势再调整容量。
