RDS性能下降 - 复盘 - Honeycomb

RDS性能下降 - 复盘 - Honeycomb

原文： https://www.honeycomb.io/blog...
译：祝坤荣

概要

注：除非特别说明，全部时间都是UTC。

5月3号周四， 从00:39:08 UTC（周三 17:39 PDT）咱们经历了一次Honeycomb服务的大约24分钟的完全停机。大部分服务恢复时间是2018-05-03 01:02:49，全部面向客户的服务恢复是在01:07:00。

影响

• 在停机期间，客户不能登陆或查看Honeycomb服务的图表。
• 停机期间发送给Honeycomb API的事件被大量拒绝；大约86%的API不能服务，并且大约81%的应该已经提交的事件在停机期间没有被记录。(百分比的差距是因为一个单独的API能够处理不一样的事件而且停机没有平均影响到全部数据集)
• 因为Honeycomb API没有报告成功，一些仍存储在客户服务上的事件在Honeycomb API恢复正常后又被从新提交。
• 停机期间大约有15%的事件成功保存

咱们对此次停机影响的每个客户都十分抱歉。咱们对于数据的管理十分认真，并经过对系统的多项改进措施来确保将来这类的停机事件不会形成数据丢失，并确保咱们在相似的失败中能够更快的恢复。

发生了什么？

过后看，故障链只有4点连通：

1. 咱们产品使用的RDS MySQL数据库实例经历了一次忽然的和大规模的性能减低； P95(query_time)从11毫秒变成>1000毫秒，同时写操做吞吐在20秒内从 780/秒降到 5/秒。
2. RDS没有识别到故障，因此 Mutil-AZ feature没有激活故障转移。
3. 因为增长的query_time致使的延迟， Go的MySQL客户端链接池被等待慢查询结果的链接填满了而且做为补偿又打开了更多的链接。
4. MySQL服务器的max_connections设置达到了上限，致使定时任务和新启动的后台进程不能链接到数据库并致使“Error 1040：Too many connections”的日志信息。

恢复部分很快：

1. RDS数据库的延迟和吞吐忽然出现改善；在20秒内P95(query_time)写从>600ms 掉到 <200ms， 同时总吞吐从<500OPS 变成>2500OPS。
2. 排队的事件快速完成，数据库在70秒内的OPS大于3000， 并在回到正常状态时变成： 300-500OPS，<10ms 写。

咱们如何获得答案的故事是一个如何使用Honeycomb来debug生产系统的有趣的例子。

根因分析

在以后次日早上咱们的复盘会议上，两个理论摆在桌上：

1. 大量的链接数致使停机，并引发了数据库运行缓慢，或
2. 数据库因为一些缘由运行缓慢，致使大量的链接数。

咱们担忧一些bug隐藏在咱们的应用里(或咱们使用的其中一个Go库)致使咱们的应用在不能链接数据库时关机，这样在一样状况再发生时又会致使同样的停机故障。
每一个人都赞成这很像是下层数据库的问题（存储，CPU或链接）是根因，但咱们也赞成若是咱们以抱怨网络的方式忽略一个潜在应用级的bug会更有危险。

做为开发者的责任：这可能不是数据库，而多是你的代码问题。

为了下降风险，咱们决定在受控环境来重现Error 1040场景并观察系统表现。在咱们的实验集群上重现链接池溢出清楚的代表了链接满确实会影响应用并致使定时任务失败，它不会致使失控的CPU或延迟升高。

咱们如今有两个数据集：生产的停机和实验用的。因为咱们使用Honeycomb来观察Honeycomb，因此在这个例子对比A和B很容易

实验生产停机

左边，实验集群从12:30到13:23（除了一些失败的定时任务很难看出证据）运行，而在右边，生产的停机很清楚地显示着。实验有个空结果：咱们没有发现 Error 1040致使了停机。看起来像是系统的一些底层问题致使的。

有了这个信息，咱们须要在生产数据上挖掘的更深刻了。因为Honeycomb数据集是高保真的（咱们不作任何聚合或预先的计算），能够将数据调整到每秒级别并调整数据来抽取模式。这里是从rdslogs里记录的性能数据。

有15秒没有活动，而后有一批query_time值达到了15秒的完成动做，看起来很明显。在结束时的性能异常也有一个有意思的热力图模式：

归纳下，数据展现了高于23分钟的低吞吐，高延迟行为，并持续了少于30秒切换区域，以前是正常的高吞吐，低延迟，尖峰应用驱动的行为，接着是大量的追赶事件，最后切换到正常的高吞吐模式。

因为这不是一个全面的根因分析，但对于咱们明确问题在数据库系统而不是咱们的应用代码已经够了；咱们的应用看起来运行正常。咱们以后再SQL的normalized_query字符串上验证了咱们的代码在恢复过程当中工做符合预期。

获得这些信息后咱们从新调查了咱们的RDS配置并确认

• Multi-AZ是打开的。
• 实例监视面板没有显示任何健康事件。
• AWS文档指出Multi-AZ不会考虑性能做为健康检查的内容

经验

• 受管理的数据库很好，除非他们没托管。
• 咱们会优先考虑在“game day”运行咱们的实验RDS作故障转移来从新验证在硬件故障时咱们对于咱们系统运行的理解。虽然咱们不认为RDS会有不少硬件故障，但当咱们须要处理RDS AZ故障转移时咱们须要一个准备好的手册来执行。
• 咱们在改进咱们的管道来保证在基础设施不能链接到数据库时接受的用户事件咱们能够缓存它们而不是失败。硬件问题发生，这就是生活；丢失数据不须要发生。

时间线 (2018-05-03 UTC)

00:39 – outage starts

00:40 – first alert

00:42 – engineers start investigation

00:50 – escalation, multiple investigators looking at several potential avenues

00:55 – status.honeycomb.io updated to keep our customers informed

00:58 – first engineering interventions to attempt to heal system, minimal impact

01:03 – outage resolution starts

01:04:23 – resolution completes, system stabilized

01:15 – engineers conclude that outage is resolved, update status.honeycomb.io

---

本文来自微信公众号「麦芽面包，id「darkjune_think」转载请注明。交流Email: zhukunrong@yeah.net