游戏卡顿白皮书 › L9 服务器游戏进程
Tick 超出预算 Tick overrun
原因 ID sp-tick-overrun · 主责 研发团队·服务器开发 · 配合 运维团队·系统运维
在含图示和实验的完整版中打开此卡片 →
一个 tick 内要做的事超出预算时，服务器的 tick 周期会被拉长，整个区域都会变慢或一卡一卡。
起因 一个 tick（例如 50 ms）要处理的工作超出预算 → 结果 本该每秒计算 20 次的游戏状态只算了 8 次 → 画面表现 整个区域慢动作（视服务器设计也可能是一卡一卡），技能反应慢
- 症状
- 慢动作, 操作延迟, 一卡一卡
- 因素
- 停顿
- 谁会遇到
- 特定地点/分线, 全服
- 何时出现
- 人多的时候, 晚高峰
- 负责方
- 主责 研发团队·服务器开发 · 配合 运维团队·系统运维
- 研发团队要做的事
- 削减昂贵的计算；把 tick 拆到多个线程；分散人数（分线）；把 tick 处理时间记为指标。
- 运维团队要做的事
- 把 tick 耗时和各核心 CPU 使用率加入监控和告警；考虑单核性能（主频）高的 CPU 或实例。
- 数值参考
- 20 tick 服务器的预算为 50 ms，30 tick 为 33 ms，60 tick 为 16.7 ms。为了应对人突然涌入，平时只用预算的一半左右、留出余量比较安全。
- 监控图上
- 随人数/负载上升 · 服务器 tick 耗时、各场景/分线人数、游戏线程 CPU
- 查看位置
- 把服务器记录的 tick 处理时间（p99）、tick 超时次数与各场景/分线人数放在同一张图上看。没有 tick 指标时，用 pidstat -t 1 看单个游戏线程的 CPU 使用率
- 确认依据
- 人数集中的时刻 tick 耗时超出预算（20 tick 为 50 ms），期间游戏线程的 CPU 使用率一直贴近 100%
- 排除依据
- tick 超时而游戏线程 CPU 却很低，是等待类原因（GC 停顿、锁、同步调用）。bcc runqlat 显示的运行队列延迟长，说明线程分不到 CPU，属于 CPU 不足或线程过多
- 确认手段
- 需要游戏服务器/客户端的日志和指标
- 深入了解
- tick 延迟时的表现因服务器设计而异。每个 tick 把游戏状态推进固定时长（例如 50 ms）的服务器，游戏时间本身会变慢，表现为慢动作。按实际流逝的时间一次性推进的服务器能保住游戏进度的速度，但数据包变稀、每次移动幅度变大，看起来是一卡一卡、瞬移。无论哪种，操作的反应都会变慢。一个游戏线程负责整台服务器时，整台服务器都会变慢；按区域分线程时，只有那个区域变慢。也有像 EVE Online 这样的游戏，在大规模战斗中故意把游戏时间放慢最多 10 倍（Time Dilation），让计算跟上。
- 真实案例
- CCP Games 2014: EVE Online HED-GP 大规模舰队战中的服务器过载
出处
- VALORANT's 128-Tick Servers Riot Games
128 tick 服务器必须在 7.8125 ms 内完成一帧；按子系统测量服务器帧耗时，分配预算加以管理 - HED-GP Technical Retrospective: What a HED-ache CCP Games
EVE Online 在过载时用 Time Dilation 放慢游戏时间，下限为 10%（慢 10 倍）；平时节点 CPU 保持在 80% 以下 - Handling variation in time Unity
固定间隔的模拟滞后时，会集中补跑追赶的步数，超出上限的时间直接丢弃，游戏时间因此比实际流得慢 - pidstat(1) — Linux manual page sysstat
-t 同时显示进程下各线程的统计（CPU 使用率等） - Demonstrations of runqlat, the Linux eBPF/bcc version IO Visor
以直方图显示调度器运行队列延迟（任务等到分得 CPU 的时间）
相关原因
同一层：L9 服务器游戏进程
其他层中同样导致“慢动作”的原因
查看含图示和实验的原卡片