7 月 22 日周三 20 点 10 分，我们的实时通信服务 CPU 消耗升高，消息处理延时增加，也影响到与它关联的消息推送服务，慢慢导致最终推送队列出现了任务堆积，部分消息无法在第一时间推送出去。一小时后（21 点 15 分）也有用户给我们反馈，在终端用户那里能感受到，聊天过程中会有明显的间歇性卡顿。我们工程师一直在密切关注服务状态，紧急追查原因，最终在 2 小时之后彻底解决这一问题。

导致这次故障的原因，与当天凌晨 7 点我们为实时通信服务的 java 进程调整了 GC 相关参数有关。经过持续的 JVM 监控分析，我们发现线上实时通信服务的 GC 配置比较简单，还有优化空间，所以决定将原来的吞吐量优先收集器改为 CMS 收集器，以使业务运行更流畅。到了晚上随着实时通信服务压力增大，我们发现该调整并未达到预期效果，FGC 更加频繁，且 GC 过后老代内存比例依然较高，这反而拖累了用户线程的处理能力；影响还波及到消息推送服务，使消息推送的速度急剧下降。

GC 参数调整之后，我们工程师一直在关注服务状态，晚上 8 点后突发的实时通信压力让新参数的弊端一下子暴露出来，但是因为当时正好是部分客户的业务高峰，我们担心重启服务会带来大面积的中断和重连，这与间歇性卡顿下的可用相比，可能会造成更大的损失，所以我们只能密切关注服务端状态变化，择机行事。等晚上 10 点左右压力回落之后，我们立刻重启了实时通信服务，回滚了 java 进程的 GC 参数，同时将推送服务的处理容限临时提高至 200% 来加速处理队列中已积压的任务。

因为只调整了实时通信服务的 java 进程 GC 参数，所以数据存储、云代码、统计分析、网站等其他服务均未受到任何影响。

以下为具体时间点和状态：

• 2015-07-22 20:10 至同日 22:08（故障阶段）持续 1 小时 58 分钟
  实时通信服务不稳定，性能下降；推送服务任务堆积，没有第一时间推送出去。
• 2015-07-22 22:08 至同日 22:26（恢复阶段）持续 18 分钟
  实时通信服务全部重启完毕并恢复正常，积压的推送开始快速消费，实时通信服务恢复正常。

在此我们向受到此次故障影响的用户表示道歉！我们会用更严谨的工作和更稳定的产品来回报用户对我们的信任与支持。

如果您对此故障有任何疑问，请及时与我们联系。

实时通信和推送服务故障报告

时间

• 2015-07-22 20:10 到 2015-07-22 22:08，故障阶段，持续时间 1 小时 58 分钟
• 2015-07-22 22:08 到 2015-07-22 22:26，恢复阶段，持续时间 18 分钟

影响

• 故障阶段：推送服务任务堆积，没有第一时间推送出去。 实时通信服务不稳定，性能下降。
• 恢复阶段：处理积压推送任务，仍然没有第一时间推送出去。实时通信服务恢复正常。
• 其他服务未受影响。

解决办法

• 实时通信服务关于 GC 的调整回滚。
• 推送服务临时扩容到 200% 处理队列积压。

后续措施

• 线上服务改动、升级前，强制先上 stage 环境进行线上同等规模的压力测试。
• 增加灰度发布机制，先用小流量观察，稳定之后再切入更多流量。
• 继续优化实时通信服务 GC 参数配置，经过测试确认有效之后再次上线。

故障时间线

• 20:10 实时通信服务压力增大，消息发送开始卡顿，推送队列开始堆积
• 21:20 尝试重启推送服务，没有奏效
• 21:30 实时通信服务进行紧急 fix。
• 21:40 开始部署 fix 后的实时通信服务。
• 22:08 实时通信服务全部重启完毕并恢复正常。积压的推送开始快速消费。
• 22:08 推送服务临时扩容到 200% 处理积压任务。
• 22:26 积压的推送任务消费完毕，推送服务恢复正常，故障结束。