高峰时玩家说“卡”，不一定代表服务器整体过载：可能只有特定区域、地图或操作受影响，也可能是玩家到服务器之间的链路不稳。排查玩家高峰期卡顿，先确认影响范围和发生时间，再对照同一时段的服务端指标与变更记录；不要一上来就重启或扩容，以免线索消失。
先把问题描述清楚
问清楚卡顿何时开始、持续多久、哪些玩法受影响，以及是否伴随掉线、延迟升高或画面帧率下降。区分“画面不流畅”和“操作响应迟缓”：前者可能在玩家设备端，后者更需要检查网络往返时间和游戏服务端处理情况。
把反馈按区域、服区、地图或功能归类，并记录发生时间。若只有一个区域异常，优先核查该区域的实例及依赖；若多个区域同时出现，再检查共用网络、数据库、登录或匹配服务。玩家高峰期卡顿的排查范围由此可以先缩小一层。
按顺序检查基础指标
- 对齐时间线。用监控平台查看卡顿前后至少数分钟的变化，核对发布、配置调整、定时任务和流量变化。监控采样可先看一分钟粒度，再按需缩短；同时记录玩家反馈时间，避免把不同时段的数据混在一起。
- 看实例资源与服务端处理。在 Linux 主机上可用 top 或 pidstat 查看进程 CPU，用 free 检查内存，用 iostat 观察磁盘等待。不要只盯总 CPU：单个核心持续繁忙、内存交换增加或磁盘等待升高，都可能影响游戏逻辑。若有服务端 tick 指标，比较高峰前后的处理耗时与积压情况。
- 检查网络质量。查看网卡收发、连接数、丢包和重传趋势，并对照不同区域反馈。带宽未跑满也可能发生丢包或链路抖动；反过来，玩家端网络异常也会造成延迟体验。应结合服务端观测和多地探测判断，不能仅凭一次测速下结论。
- 检查数据库与外部依赖。查看连接池是否耗尽、请求等待是否变长，以及慢查询日志是否在卡顿时段增加。再核对登录、匹配、存档等共用服务的错误率和响应时间。慢查询需要结合具体查询和索引分析，不宜直接在高峰期随意改表或清理数据。
- 查近期变更并验证。对照发布版本、配置和定时任务记录，优先检查卡顿开始前发生的变化。选取低风险、可回退的单项调整，观察指标与玩家反馈是否同步改善；每次只改一个变量，便于判断因果。
用证据缩小范围，而不是猜瓶颈
看分位数，也看错误率
平均延迟容易掩盖少数玩家的坏体验。若平台提供 P95延迟，可同时看中位数、P95和超时比例，并按区域或服务拆分。具体阈值要依据游戏类型、既有基线和服务目标确定，不存在适用于所有游戏的统一标准。
避免把相关变化当成原因
例如 CPU 与延迟同时上升，只说明两者时间上重合；还要确认是哪一个进程或线程繁忙，并检查请求量、队列和依赖响应是否一起变化。若指标未覆盖关键环节，先补充日志和监控，再安排可控复现或压测，不要直接在生产高峰制造额外负载。
交接时留下可复用记录
整理一份简短排查单：影响区域与功能、起止时间、异常指标、近期变更、已做操作及回退方式。确认告警联系人、日志位置和发布回滚流程也很重要。这样下一次玩家高峰期卡顿时，团队能从已验证的线索开始，而不是重复试错。
常见问题
玩家说卡，但监控看起来正常怎么办？
先核对玩家所在区域、具体玩法和反馈时间，检查监控粒度是否过粗，并补看错误日志、请求分位数及网络质量。
高峰时能直接重启服务吗？
除非故障处置流程明确要求，否则先保存日志和指标快照。重启可能短暂缓解问题，也会丢失重要现场线索。
什么时候考虑扩容？
当持续监测和复现显示资源或实例容量确实受限，且扩容后依赖服务能承接时，再按变更流程评估；先确认瓶颈，避免扩错环节。
玩家端和服务端问题怎么区分？
对照多个玩家、区域和服务端指标：若反馈集中在单一玩家设备或接入网络，优先查客户端与链路；若同一区域多人同步异常且服务端指标变化，应深入检查对应实例和依赖。
总之，玩家高峰期卡顿应从范围、时间线和基础指标逐层排查，用可验证的证据决定下一步，而不是凭单一指标下结论。