努力调试Amazon RDS MySQL实例上的高CPU使用率

21

我们正在运行m1.xlarge MySQL RDS服务器，并且在CPU使用率较高方面存在一些问题。几周前，我们遇到了一些问题，大型实例上的CPU利用率达到了100％。当我们将大小升级到xlarge时，可以稳定一段时间，但CPU使用率逐渐上升。

在过去一周左右的时间里，CPU利用率一直处于90年代的最高水平，昨天一直稳定地达到100％左右，这使我们的生产基地停顿了下来。重新引导数据库服务器后，几个小时内CPU使用率又恢复到相同的水平。

我已经在mysql服务器上运行了show processlist，并一直通过MySQL admin进行监视。似乎也没有特别长时间运行的查询或大量查询。有两个进程长时间处于睡眠状态……这些是在我们的主应用程序外部运行的与数据库通信的隔离工作程序守护程序。我在下面的过程列表输出中复制了服务器名称，以对其进行描述：

+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| 13 | rdsadmin | localhost:43513 | mysql | Sleep | 14 | | NULL |
| 15 | proddbuser | app-server-1.eu-west-1.compute.internal:36460 | proddb | Sleep | 46 | | NULL |
| 451 | proddbuser | app-server-1.eu-west-1.compute.internal:55512 | proddb | Sleep | 29 | | NULL |
| 912 | proddbuser | app-server-1.eu-west-1.compute.internal:45171 | proddb | Sleep | 13 | | NULL |
| 941 | proddbuser | app-server-1.eu-west-1.compute.internal:47353 | proddb | Sleep | 53 | | NULL |
| 951 | proddbuser | app-server-1.eu-west-1.compute.internal:48014 | proddb | Sleep | 37 | | NULL |
| 1009 | proddbuser | app-server-1.eu-west-1.compute.internal:51787 | proddb | Sleep | 36 | | NULL |
| 1041 | proddbuser | app-server-1.eu-west-1.compute.internal:53777 | proddb | Sleep | 14 | | NULL |
| 1572 | proddbuser | app-server-1.eu-west-1.compute.internal:42989 | proddb | Sleep | 3 | | NULL |
| 1592 | proddbuser | app-server-1.eu-west-1.compute.internal:43279 | proddb | Sleep | 162 | | NULL |
| 2909 | proddbuser | app-server-1.eu-west-1.compute.internal:37768 | proddb | Sleep | 35 | | NULL |
| 3028 | proddbuser | app-server-1.eu-west-1.compute.internal:42568 | proddb | Sleep | 5 | | NULL |
| 3119 | proddbuser | app-server-1.eu-west-1.compute.internal:46913 | proddb | Sleep | 76 | | NULL |
| 3189 | proddbuser | app-server-1.eu-west-1.compute.internal:51466 | proddb | Sleep | 5 | | NULL |
| 3216 | proddbuser | app-server-2.eu-west-1.compute.internal:44097 | proddb | Sleep | 14552 | | NULL |
| 3218 | proddbuser | app-server-2.eu-west-1.compute.internal:44099 | proddb | Sleep | 14552 | | NULL |
| 3219 | proddbuser | app-server-2.eu-west-1.compute.internal:44107 | proddb | Sleep | 44 | | NULL |
| 3220 | proddbuser | app-server-2.eu-west-1.compute.internal:44113 | proddb | Sleep | 26 | | NULL |
| 3223 | proddbuser | app-server-2.eu-west-1.compute.internal:44184 | proddb | Sleep | 50 | | NULL |
| 3224 | proddbuser | app-server-2.eu-west-1.compute.internal:44187 | proddb | Sleep | 1 | | NULL |
| 3226 | proddbuser | app-server-2.eu-west-1.compute.internal:44208 | proddb | Sleep | 33 | | NULL |
| 3229 | proddbuser | app-server-2.eu-west-1.compute.internal:44250 | proddb | Sleep | 14 | | NULL |
| 3232 | proddbuser | app-server-2.eu-west-1.compute.internal:44279 | proddb | Sleep | 26 | | NULL |
| 3233 | proddbuser | app-server-2.eu-west-1.compute.internal:44297 | proddb | Sleep | 31 | | NULL |
| 3237 | proddbuser | app-server-2.eu-west-1.compute.internal:44334 | proddb | Sleep | 27 | | NULL |
| 3239 | proddbuser | app-server-2.eu-west-1.compute.internal:44338 | proddb | Sleep | 11 | | NULL |
| 3241 | proddbuser | app-server-2.eu-west-1.compute.internal:44356 | proddb | Sleep | 26 | | NULL |
| 3260 | proddbuser | app-server-2.eu-west-1.compute.internal:44619 | proddb | Sleep | 8 | | NULL |
| 3337 | proddbuser | utility-server-1.eu-west-1.compute.internal:45193 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 309416 LIMIT 1 |
| 3419 | proddbuser | utility-server-1.eu-west-1.compute.internal:46136 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 284530 LIMIT 1 |
| 3463 | proddbuser | app-server-1.eu-west-1.compute.internal:59619 | proddb | Sleep | 9406 | | NULL |
| 3504 | proddbuser | utility-server-1.eu-west-1.compute.internal:47063 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 260571 LIMIT 1 |
| 3577 | proddbuser | app-server-1.eu-west-1.compute.internal:34394 | proddb | Sleep | 6734 | | NULL |
| 3585 | proddbuser | utility-server-1.eu-west-1.compute.internal:47990 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 231273 LIMIT 1 |
| 3664 | proddbuser | utility-server-1.eu-west-1.compute.internal:48909 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 201525 LIMIT 1 |
| 3716 | proddbuser | app-server-2.eu-west-1.compute.internal:56301 | proddb | Sleep | 27 | | NULL |
| 3748 | proddbuser | utility-server-1.eu-west-1.compute.internal:49850 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 167839 LIMIT 1 |
| 3771 | proddbuser | my-pc:30101 | NULL | Query | 0 | NULL | show processlist |
| 3831 | proddbuser | utility-server-1.eu-west-1.compute.internal:50785 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 123228 LIMIT 1 |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+

我还应该说，相对于正常的高峰时段，此期间的网站流量非常低，约为高峰时段负载的10％。

我们还提供了新的文物监控，向我们显示了最耗时的应用程序数据库调用是什么。它向我们显示，一个特定的调用占了我们应用程序在db中花费的时间的99％，这是一个简单的按ID查找查询，如下所示：

SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`id` = 123 LIMIT 1

（与上述进程列表中运行的查询不太一样）

在过去一周左右的时间里，此操作变慢了，时间请求之间的标准偏差增加，并且以秒为单位测量的最大时间量也增加了。我认为这只是CPU使用率问题的结果，而不是原因。

该表大约有80,000行，因此并不庞大。可以预期，数据库中大多数应用程序时间都花在查找此表中的记录上，该应用程序的主要功能就是基于此。我已经几次从我的应用服务器向生产数据库运行了类似的查询，而CPU使用率保持在100％左右，并且它在1或2毫秒内响应。

基于上述所有内容，我们不确定如何进行调试。只是想知道是否有人有什么想法可能是根本原因以及如何进行调查？由于它是Amazon RDS实例，因此对运行我们的数据库服务器的基础服务器的访问受到限制。

mysql 
— 威尔·托马斯
source
刚刚重新启动RDS解决了我的问题
— shareef，2016年

Answers:

14

设法解决这个问题，这些是我遵循的步骤：

首先，我通过在论坛上发帖与Amazon RDS团队联系，他们确认这是占用所有CPU的mysqld进程-这消除了物理服务器上运行的其他配置错误

其次，我跟踪了正在运行的查询的来源： 

SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 231273 LIMIT 1

我最初忽略了这个原因，因为当我监视show processlist输出时，这些查询似乎都不需要花费很长时间。在用尽其他方法之后，我认为可能值得跟进...。我很高兴自己做到了。

如您在show processlist输出中所看到的，这些查询来自实用服务器，该服务器运行一些战术实用程序作业，这些作业存在于我们的主要应用程序代码之外。这就是为什么它们没有在我们的新文物监视中显示为缓慢或引起问题的原因，因为新的文物代理仅安装在我们的主应用程序服务器上。

松散地遵循本指南：

http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/

我能够将这些查询跟踪到我们的实用程序服务器框中的特定正在运行的进程。这是一些红宝石代码，它效率低下地遍历了大约70,000条记录，检查了一些字段值，并使用这些值来确定是否需要在“ mytable”中创建新记录。经过分析，我可以确定，不再需要该过程，因此可以取消。

事情变得更糟的是，由于cron作业的配置方式以及每个作业花费了多长时间，一次似乎有6个实例同时运行同一进程。我杀死了这些进程，令人难以置信的是，我们的CPU使用率从大约100％下降到了大约5％！

— 威尔·托马斯
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.