服务器端懒加载 Lazy loading on the server

原因 ID dk-lazy-load · 主责 研发团队·服务器开发 · 配合运维团队·系统运维

服务器第一次收到副本、地图数据请求时才从磁盘读取，那个 tick 期间所有人都会卡住。

起因有人第一次进入某个副本或区域 → 结果服务器在游戏线程里从磁盘读数据 → 画面表现 这台服务器上的所有人短暂卡住

症状: 卡住
因素: 停顿
谁会遇到: 特定地点/分线, 全服
何时出现: 移动中/切换地图时
负责方: 主责 研发团队·服务器开发 · 配合运维团队·系统运维
研发团队要做的事: 服务器启动时预加载，异步加载。
运维团队要做的事: 刚从快照创建的服务器，在投入服务前预热磁盘（把所有块读一遍），或使用快速快照恢复功能。
监控图上: 偶发随机尖峰 · 服务器 tick 耗时、磁盘读取
查看位置: 把停顿时刻与游戏服务器日志中副本、区域的首次进入记录对照，看当时游戏服务器的磁盘读取（pidstat -d 的 kB_rd/s），并用 perf trace --duration 找耗时长的 read、open 调用。新拉起的云服务器，把 EBS 的 VolumeAvgReadLatency 与运行已久的服务器对比
确认依据: 只在首次进入时停顿，第二次进入同一地方不再停顿。停顿期间游戏线程在等文件读取
排除依据: 已加载的区域同样停顿，是 tick 超出预算、GC 等其他原因
确认手段: 需要游戏服务器/客户端的日志和指标
深入了解: 在云上刚用快照（磁盘副本）创建的服务器，每个第一次读取的块都要从远端存储拉取，比平时慢得多。如果只有弹性伸缩新拉起的服务器首次进入特别慢，就该怀疑这个原因。

出处

Initialize Amazon EBS volumes AWS
由快照创建的卷，在从 S3 拉取块期间延迟增加、性能下降；用 dd、fio 读一遍所有块，预先初始化
Amazon EBS fast snapshot restore AWS
快速快照恢复在创建时就提供已初始化的卷，消除首次访问延迟
pidstat(1) — Linux manual page sysstat
-d：各进程的 kB_rd/s（每秒磁盘读取量）
perf-trace(1) — Linux manual page perf
--duration 只显示耗时超过指定 ms 的系统调用
Amazon CloudWatch metrics for Amazon EBS AWS
VolumeAvgReadLatency：1 分钟平均读取延迟（Nitro 实例）