游戏卡顿白皮书 › 只有部分人遇到的问题
特定角色数据过于庞大 One character with oversized data (inventory, mail, buffs)
原因 ID pt-heavy-char · 主责 研发团队·服务器开发 · 配合 运维团队·数据库运维
在含图示和实验的完整版中打开此卡片 →
物品、邮件堆了几千个，或者好友列表、黑名单、buff 特别多的角色，登录、存盘、向周围广播的数据量是别人的好几倍。与线路无关，只有用这个角色时才慢。
起因 长期培养的角色或活动奖励在背包、邮箱里堆了几千个 → 结果 每次登录、切换区域、存盘都要读写对应数量的 DB 数据，要发给周围的装备、buff 信息也很大 → 画面表现 只有这个角色进入时加载很久，打开背包、邮件时顿一下。如果服务器在游戏线程里等待存盘完成，周围的人也会跟着出现短暂停顿
- 症状
- 连不上/无限加载, 操作延迟, 卡住
- 因素
- 停顿
- 谁会遇到
- 只有我, 仅特定功能
- 何时出现
- 刚登录/维护结束后, 做特定操作时, 移动中/切换地图时
- 负责方
- 主责 研发团队·服务器开发 · 配合 运维团队·数据库运维
- 研发团队要做的事
- 设置背包、邮件的保存上限并自动清理旧邮件，只分批加载需要的部分，存盘只写变化的部分，并放在游戏线程之外执行。
- 运维团队要做的事
- 在慢查询日志中找出同一角色反复出现的慢查询并转给研发团队，提供物品、邮件行数最多的角色排行。
- 数值参考
- 如果一个物品是 DB 里的一行，有 5,000 个物品的角色每次登录都要读 5,000 行，是普通角色的几十倍。
- 监控图上
- 仅部分偏高 · 各角色的登录、存盘耗时，各角色的 DB 查询行数
- 查看位置
- 在 DB 慢查询日志（MySQL slow query log、PostgreSQL log_min_duration_statement）中找出同一角色 ID 反复出现的慢查询、慢存盘，并列出物品、邮件表中按角色统计的行数排行
- 确认依据
- 慢查询集中在少数几个角色 ID 上，这些角色的物品、邮件行数是平均值的几十倍，换别的电脑、线路登录也同样慢
- 排除依据
- 同一账号的其他角色或其他玩家也一起慢，是 DB 设备或锁方面的问题。该角色在别的电脑上正常，是玩家环境问题
- 确认手段
- 运维工具即可确认（无需游戏代码）
- 深入了解
- 用同一个角色在别的电脑、别的线路上登录同样慢，同一账号的其他角色却正常，就要怀疑角色数据。这正是反馈中一定要写角色名的原因。
出处
- Extraneous Fetching antipattern Microsoft Azure
取回超出需要的数据，会加重 I/O 负担、拖慢响应 - PostgreSQL Documentation: Error Reporting and Logging PostgreSQL
log_min_duration_statement：记录耗时超过一定时间的 SQL，用于追踪慢查询 - The Slow Query Log MySQL
记录超过 long_query_time 的查询的慢查询日志
相关原因
同一层：只有部分人遇到的问题
其他层中同样导致“连不上/无限加载”的原因
查看含图示和实验的原卡片