随机时间跨度后AWS RDS MySQL性能下降

Question

问题概述 我们的AWS RDS实例在大约7-14天后开始减速,这是一个相当大的因素(特定查询集的加载时间约为400%).RDS监测没有显示出资源短缺的迹象.(有关详细问题说明,请参阅下面的问题更新)

---

问题更新

因此,经过一个多月的调查和AWS的一些开发人员支持,我并不完全接近解决方案.

以下是我检查列表的几个步骤,或多或少没有任何进一步的问题提示:

• 索引/碎片(所有表都有正确的索引/键并且没有碎片)
• MySQL统计信息更新(手动更新统计信息源)
• 线程并发(将innodb_thread_concurrency更改为各种不同的参数)
• 查询缓存命中率不会显示问题
• 使用索引/键来查看是否有任何SELECT实际上很慢
• SLOW QUERY LOG(不返回任何结果,因为见下面的段落,它是一些准备好的SELECT)
• RDS和EC2在一个VPC内

为了解释,使用过的PlayFramework(2.3.8)有BoneCP,我们使用eBeans来选择我们的数据.所以基本上我正在运行一个嵌套对象和所有这些子对象,这为所讨论的API调用产生了几百个准备好的SELECT.对于使用过的硬件,这基本上也应该没问题,这些操作都不会广泛使用CPU和RAM.

我还包括NewRelic以获得有关此问题的更多见解,并进行了一些JVM概要分析.显然,大部分时间都是由NETTY/eBeans消耗的？

有人能理解这个吗？

---

原始问题:问题大纲

我们的AWS RDS实例在大约7-14天后开始放慢一个相当大的因素(特定查询集的加载时间约为400%).RDS监测没有显示出资源短缺的迹象.

基础设施

我们为AWS EC2实例上的移动应用程序运行PlayFramework后端,连接到AWS RDS MySQL实例,一个PROD环境,一个DEV环境.通常PROD EC2实例指向PROD RDS实例,而DEV EC2指向DEV RDS(来自队长的嗨明显!); 但有时我们也会让DEV EC2指向PROD DB进行某些测试.正在使用的PlayFramework正在与BoneCP合作.

详细问题描述

在一个非常重要的同步过程中,我们的应用程序每个用户每天多次进行一次API调用.我在这个SO问题中讨论了功能的背景,感谢评论,我可以将问题归结为某种类型的MySQL问题.

简而言之,API调用正在加载一组数据,最大约为1MB的json数据,目前大约需要18s才能加载.当事情运行得非常好时,这需要大约4秒才能加载.

很奇怪,上次"解决"问题的是将RDS实例升级到另一个实例类型(从db.m3.large到db.m4.large,这只是一个非常小的步骤).现在,大约2-3周后,RDS实例再次像以前一样缓慢运行.重新启动RDS实例显示无效.同样重新启动EC2实例也没有效果.

我还检查了受影响的mySQL表的索引是否设置正确,情况就是这样.API调用本身不是急于加载任何BLOB字段或类似的,我仔细检查了这一点.在大多数情况下,RDS实例的CPU使用率低于1%,当我用100个同时API调用对其进行压力测试时,它达到了约5%,因此这不是瓶颈.内存也很好,所以我猜RDS实例没有开始交换,这可能会减慢整个过程.

提供确凿的证据,DEV环境上的(较小的)公共API调用目前需要2.30秒负载,在PROD环境中需要4.86秒.这很有趣,因为DEV环境在EC2和RDS中都有一个小得多的实例类型.所以基本上乌龟在这里赢得比赛.(如果您对此API调用感兴趣,我很乐意通过PN与您分享,但我真的不想发布API调用的链接,即使它们基本上是公开的.)

结论

最后,感觉(我有点说'感觉')就像数据库在使用x天后/在一定量的API调用之后被阻塞了.不确定这是否是特定于RDS的问题,一旦我"通过更改实例类型"重置数据库实例,事情就会快速而平稳地运行.但是,每两周从快照重新创建我的数据库实例不是一种选择,特别是如果我不明白为什么会发生这种情况.

您有什么想法可以采取哪些进一步措施来调查此事吗？

Answer 1

（太长了，无法发表评论）我知道你已经检查了很多东西，但我想用不同的眼光来看待它们......

请提供

SHOW VARIABLES;  (probably need post.it or something, due to size)
SHOW GLOBAL STATUS;
how much RAM?  Sounds like 7.5G
The query.  -- Unclear what query/queries you are using
SHOW CREATE TABLE  for the table(s) in the query -- indexes, datatypes, etc

（上面的一些内容可能有助于解决“随着时间的推移而堵塞”的问题。）

同时，这里有一些猜测/问题/等等......

• 共享硬件的其他一些客户正忙。
• 可能是网络问题？
• 缩小long_query_time到 1，这样您就可以捕获缓慢的查询。
• 您的实例何时完成备份？
• 4 秒到 18 秒加载一兆字节——其中 SQL 语句的百分比是多少？
• 您是否“批量”插入？是单笔交易吗？是否同时进行冗长的查询？
• 您对 AWS 默认设置进行了哪些 MySQL 可调参数更改（如果有）？
• 7.5GB 分区上有 6GB buffer_pool？这听起来很危险。你能看看有没有交换？
• 有PARTITIONing涉及吗？（当然，他们CREATE会回答这个问题。）