分类目录归档:故障

2016 年 3 月 29 日:数据存储服务响应缓慢的故障说明

2016 年 3 月 29 日晚间,LeanCloud 平台上的多个应用进行了推广活动,激增的访问量给我们的数据存储和实时通信服务带来了较大压力。从 20:50 至 22:15 有多次流量高峰出现,我们多台 Web 服务器的网络吞吐包超过虚拟机的能力极限,内外网通信中断,从而导致 HTTP 服务多次出现间歇性故障(数据存储 API 以及依赖于它的服务也都间歇性不可用)。具体情况汇报如下:

故障时间

  • 20:53 - 21:03(持续约 10 分钟)数据存储 API 服务约 50% 的请求超时。
  • 21:17 - 21:40(持续约 23 分钟)数据存储 API 服务约 50% 的请求超时。
  • 22:00 - 22:15(持续约 15 分钟)数据存储 API 服务约 12.5% 的请求超时。

故障总共持续约 48 分钟。

影响范围

本次故障只影响中国节点,美国节点的所有服务均工作正常。在故障期间凡是向 LeanCloud 平台发送过请求,并使用了数据存储服务的活跃应用都受到了影响;我们的统计服务也在短时间内无法正常接收来自应用的事件上报。

继续阅读

2016 年 3 月 24 日:中国节点文件存储故障说明

2016 年 3 月 24 日下午 2:24,LeanCloud 的文件存储及 CDN 上游服务商之一受到了恶意攻击,导致 LeanCloud 中国节点的部分应用无法正常访问文件。当日晚上 8 点服务商修复了故障,LeanCloud 的文件存储随即恢复正常。

故障时间

14:24 至 19:55(持续约 5 小时 31 分钟)

影响范围

使用中国节点、在故障期间有文件访问请求的部分应用受到了影响。中国节点上的其他服务,如结构化数据存储、云引擎、聊天、短信、推送、统计等均未受影响。美国节点一切正常。

继续阅读

2016 年 2 月 26 日:聊天服务短暂异常的故障说明

2016 年 2 月 26 日下午五点左右,我们的聊天服务出现了短暂异常,导致部分终端用户在获取指定聊天记录时,可能会得到整个应用的聊天记录。此次故障持续了十多分钟,具体情况如下。

故障时间

16:45 至 16:58(持续约 13 分钟)

影响范围

使用了聊天服务,且在服务异常期间发生了聊天记录查询请求的所有应用

继续阅读

2016 年 2 月 19 日:云服务中断半小时的故障说明

2016 月 2 月 19 下午 3 点左右,LeanCloud 所有服务突然不可用。我们的报警系统即刻捕捉到异常并发出告警,我们由此进行紧急修复,于半小时后将全部服务恢复到正常运行状态。此次故障影响范围较大,性质严重,我们将详细情况汇报如下。

故障时间

15:17 至 15:50(持续约 33 分钟)

影响范围

除了单纯的静态网站托管服务未受影响之外,其他所有服务,包括结构化数据存储、文件存储、云引擎、聊天、短信、推送、统计等功能都暂时无法使用。

继续阅读

2016 年 1 月 9 日:云引擎故障说明

昨日(周六)下午 4 时左右,有部分应用的云引擎服务出现间歇性错误「502 Application Not Responding」。我们收到报警后紧急上线调查原因,最终在下午 4 点 40 分左右修复了故障,让云引擎服务恢复正常。

本次故障从问题大面积爆发到恢复大约持续了 50 分钟,受影响的服务仅涉及云引擎,其他云端服务均运行正常。使用了云引擎服务且该时间段内云引擎有流量的应用会受到牵连。本次故障给部分用户带来了影响和损失,我们感到万分惭愧,并郑重向这些用户道歉。

故障修复之后,我们立即召集所有相关工程师进行了问题总结和技术讨论,评估可行措施来防止类似问题再次发生。以下是本次故障的详细报告。

继续阅读

2015 年 12 月 25 日:数据存储服务系统故障说明

12 月 25 日凌晨 5 点 30 分至上午 8 点整,数据存储服务器的某一分片突然发生故障,导致所属的 1468 个应用无法向云端写入数据。我们在 5 点半收到报警后着手开始处理故障,最终在 8 点修复了这一问题,故障时间共持续 2 小时 30 分钟。

故障期间,受到影响的应用无法向云端保存和更新数据,但仍可以进行查询,并可使用不依赖于数据存储服务的其他功能。其它应用和服务均不受影响。

继续阅读

2015 年 8 月 7 日:实时通信服务宕机故障报告

8 月 7 日上午 8 点 30 分左右,聊天服务出现不稳定状态,8 点 59 分我们内部监控系统显示服务不可用并报警,工程师随之上线处理。之后陆续收到用户反馈,说终端用户无法连接上 LeanCloud 聊天服务器。经我们检查确认是由于某台服务器出现了网络故障而导致连锁反应,我们工程师在定位故障后即刻进行了服务重启和扩容,最终在 11 点 50 分让服务彻底恢复正常。

这是一次非常重大的事故。为了将问题说清楚,我们先来介绍一下 LeanCloud 聊天服务的架构。

Screen Shot 2015-08-07 at 6.21.24 PM

继续阅读

2015 年 8 月 6 日:存储服务访问过慢的故障报告

8 月 6 日上午 10 点 55 分开始,LeanCloud 数据存储、网站等服务都突然变慢,之后持续 15 分钟整个存储服务都基本不可用;从 11 点 10 分开始存储服务逐步恢复,至 11 点 23 分才彻底正常。

出现这一事故的原因,与我们的智能索引优化有关。大家可能知道,我们使用 Mongodb 来存储结构化数据。为了方便开发者的使用,我们会根据应用查询性能数据来自动为数据表进行索引优化。因为近期有部分客户数据增长迅猛,我们的智能索引优化系统监控到部分查询耗时较长,便给出了索引优化建议。上午 10 点 55 分,智能索引系统开始自动为这些用户的部分数据表创建索引。但是由于此次操作实际执行时间过长,导致索引创建失败,并引发了 Mongodb 中大量操作的堆积,令整个 shard 处于崩溃状态。很快存储集群的故障就波及到了前端的 API Server。

继续阅读

2015 年 7 月 22 日:实时通信和推送服务故障说明

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 年 7 月 8 日—云引擎「在线编辑函数」功能暂时不可用的故障说明(已更新)

从昨天(7 月 8 日)晚间开始,我们发现云引擎「在线定义函数」的编辑功能出现故障,用户无法在线实时修改自定义函数。受影响的功能仅限于「在线定义函数」这一项,云引擎的其他功能(如部署、运行等)以及 LeanCloud 的其他服务(如数据存储、聊天、推送等)均不受影响。

从故障发现之时起,我们的工程师一直在查找和定位原因,惭愧地是到 7 月 9 日下午 2 点左右还没有完全解决。因此我们做了代码回滚,从 2 点 47 分开始「在线定义函数」功能又可以正常使用了。等我们找出引起该问题的具体原因,会给大家做进一步的更新。

谢谢大家对 LeanCloud 的理解与支持!

2015 年 7 月 13 日 更新:

我们的工程师最终在 7 月 10 日晚上 6 点找出了问题根源:

0.5.5 版 JavaScript SDK 中,我们为了兼容 Promise+ 模式,将 save 保存操作变为异步调用,导致它在多 appId/appKey 切换的场景下会产生超时错误。而云引擎正是这种使用方式,所以出现了自定义函数不能保存的情况;但对于账户下只有一个应用的用户而言,因为不涉及切换 appId/appKey,所以并不会受到影响。我们通过回滚云引擎代码暂时解决了这一问题,以后会再择机将其整体升级到最新版。