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

Question

问题概述
我们的AWS RDS实例在大约7-14天后开始变慢，这是一个很大的因素(一组特定查询的加载时间约为400％)。 RDS监视显示没有资源短缺的迹象。 (有关问题的详细说明，请参阅下面的问题更新)

问题更新

因此，经过一个多月的调查和AWS的一些开发人员支持，我离解决方案还差得很远。

这是我从列表中检查的几个步骤，或多或少没有问题的任何进一步提示:

索引/碎片(所有表都具有正确的索引/键并且没有碎片)

MySQL统计信息更新(手动更新统计信息source)

线程并发(将innodb_thread_concurrency更改为各种不同的参数)

查询缓存命中率未显示问题

EXPLAIN，以查看是否有任何SELECT速度实际上慢或是否不使用索引/键

慢查询日志(不返回任何结果，因为请参阅下面的段落，其中包含许多已准备好的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 RDS MySQL实例，一个PROD环境，一个DEV环境的AWS EC2实例上为移动应用程序运行PlayFramework后端。通常，PROD EC2实例指向PROD RDS实例，而DEV EC2指向DEV RDS(嗨，显然是船长!)；但是有时出于某些测试目的，我们也让DEV EC2指向PROD DB。正在使用的PlayFramework正在与BoneCP一起使用。

详细问题描述

在一个非常重要的同步过程中，我们的应用每天要对每个用户进行多次API调用。我讨论了 this SO question中功能的背景，在此感谢注释，我可以将问题归结为某种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环境上的(较小)公共(public)API调用当前需要2.30s的负载，而在PROD环境上需要4.86s的负载。这很有趣，因为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，这样您就可以捕获慢速查询。

您的实例何时进行备份？

4s-18s加载一兆字节-SQL语句占百分之几？

您“批量”插入吗？它是单笔交易吗？是否同时进行冗长的查询？

您是否从AWS默认设置更改了MySQL可调参数(如果有)？

7.5t分区上的

6GB buffer_pool？这听起来很危险。您可以查看是否有任何交换吗？

是否涉及到PARTITIONing？ (当然CREATE会回答这个问题。)