MySQL RDS 实例占用内存和交换

Question

我在 db.m2.4xlarge 类的 RDS 实例上遇到内存问题。

以下是RDS实例的规格

实例类：db.m2.4xlarge（68.4 GB RAM）

引擎：mysql (5.5.37)

IOPS：8000

存储空间：805GB（128GB 数据）

多可用区：是

自动备份：已启用（5 天）

mysql 实例在不更改 InnoDB 缓冲区值的情况下进行了调整。

总缓冲区：23.9G 全局 + 每个线程 3.0M（1000 个最大线程）

最大可能内存使用量：26.8G（已安装 RAM 的 42%）

InnoDB 表中的数据：98G

之前，我们曾经有更高的缓冲区值，这是更优化的，但是重新启动的频率使我们将其减少回 RDS 设置的默认缓冲区大小。

我们的应用程序从 4 个 ColdFusion 服务器和 4 个 asp.net 服务器工作，它们都与相关的 MySQL RDS 实例通信。我们正在为应用程序使用连接池。所有的 DML 语句都是使用存储过程完成的，并且它们被非常频繁地执行。

我的问题是 RDS 实例如果单独存在，会慢慢消耗内存并开始交换。当它交换时，我们的应用程序开始一一失败。因此，我们只有重新启动实例的唯一选择。目前，每当内存低于 5 GB 时，我们都会重新启动服务器。

我们采用的另一种方法是重新启动冷融合服务器，重新启动 IIS，然后发出“刷新表”查询。但这有时会产生结果，但有时没有变化。理论上，我相信即使没有刷新表查询，内存也应该被释放，这不会发生。同样，释放的内存通常在 1-7 GB 的范围内。

MySQL 的交互式超时设置为 300 秒，ColdFusion 连接生存期为 300 秒，asp.net 中设置的超时为 270 秒。

我无法追踪正在使用内存的内容并将其保留给自己。理想情况下，内存应该在 MySQL 需要时被释放。但它并没有发生。

我需要一些关于如何追踪内存占用的指导，以便 RDS 实例继续运行而无需重新启动。

我们已经有 MONyog 监控 RDS。另外，在 RDS 中启用了全局状态历史记录 (GoSH)，这对我来说并没有真正有用。

我已经看到这里提到的类似问题@我什么时候应该考虑根据内存使用情况升级我们的 RDS MySQL 实例？ 作为数据库调优的一部分，我们已经完成了那里推荐的所有操作。

下面是图表

该图表描绘了过去 3 周

该图以重新启动开始，这发生在内存降至 0 并开始交换之后。之后有 2 次重新启动。

当前一周

2014 年 8 月 19 日发生了 2 次内存释放。释放 6GB 的一次是通过重新启动服务和刷新表来完成的，如下所述。

这就是过去24小时的样子。

编辑

根据需要添加更多详细信息。

进程列表如下

mysql> 显示进程列表；

+--------+------------------+------------------------ ------------------------------+------------+------ ---+-------+----------------------------+-------- ----------+ | 身份证 | 用户 | 主持人
| 数据库 | 命令 | 时间 | 状态 | 信息
| +--------+------------------+------------------------ ------------------------------+------------+------ ---+-------+----------------------------+-------- ----------+ | 1 | event_scheduler | 本地主机
| 空 | 守护进程 | 30 | 等待下次激活 | 空
| | 第332话 用户 | ip3:32355 | 空 | 睡觉 | 1 | | 空
| | 第836话 管理员 | 本地主机：40463
| mysql | 睡觉 | 6 | | 空
| | 345919 | 用户 | server2:49173 | 空 | 睡觉 | 0 | | 空 | | 354132 | 用户 | server2:49641 | 空 | 睡觉 | 82 | | 空 | | 386366 | 用户 | ip1.us-west-2.compute.internal:64097 | 数据库 | 睡觉 | 1 | | 空 | | 389625 | 用户 | ip2.us-west-2.compute.internal:59819 | 数据库 | 睡觉 | 0 | | 空 | | 390109 | 用户
| ip1.us-west-2.compute.internal:64879 | 数据库 | 睡觉 | 1 |
| 空 | | 391366 | 用户 | ip2.us-west-2.compute.internal:60319 | 数据库 | 睡觉 | 1 |
| 空 | | 392045 | 用户 | ip3:39593
| 空 | 睡觉 | 20193 | | 空
| | 393625 | 用户 | ip3:26708 | 数据库 | 睡觉 | 3902 | | 空 | | 393626 | 用户 | ip3:37544 | 空
| 睡觉 | 5677 | | 空 | | 393933 | 用户 | ip2.us-west-2.compute.internal:60912 | 数据库 | 睡觉 | 0 | | 空 | | 394462 | 用户 | ip1.us-west-2.compute.internal:49971 | 数据库 | 睡觉 |
3 | | 空 | | 394802 | 用户
| ip7:1142 | 数据库 | 睡觉 | 88 |
| 空 | | 395410 | 用户 | ip2.us-west-2.compute.internal:64725 | 数据库 | 睡觉 | 4 |
| 空 | | 396217 | 用户 | ip2.us-west-2.compute.internal:64891 | 数据库 | 睡觉 | 12 |
| 空 | | 396581 | 用户 | ip7:1423
| 数据库 | 睡觉 | 22 | | 空
| | 396731 | 用户 | ip7:1429 | 数据库 | 睡觉 | 21 | | 空 | | 396954 | 用户 | ip1.us-west-2.compute.internal:50472 | 数据库 | 睡觉 | 7 | | 空 | | 398509 | 用户 | ip1.us-west-2.compute.internal:50595 | 数据库 | 睡觉 |
179 | | 空 | | 399337 | 用户 | ip3.us-west-2.compute.internal:49539 | 数据库 | 睡觉 | 第219话
| 空 | | 399338 | 用户 | ip3.us-west-2.compute.internal:49540 | 数据库 | 睡觉 | 第219话
| 空 | | 399360 | 用户 | ip4.us-west-2.compute.internal:62560 | 数据库 | 睡觉 | 0 |
| 空 | | 399363 | 用户 | ip4.us-west-2.compute.internal:62568 | 数据库 | 睡觉 | 0 |
| 空 | | 399580 | 用户 | ip5.us-west-2.compute.internal:50055 | 数据库 | 睡觉 | 1 |
| 空 | | 399581 | 用户 | ip6.us-west-2.compute.internal:58023 | 数据库 | 睡觉 | 1 |
| 空 | | 399607 | 用户 | ip6.us-west-2.compute.internal:58034 | 数据库 | 睡觉 | 1 |
| 空 | | 399608 | 用户 | ip6.us-west-2.compute.internal:58036 | 数据库 | 睡觉 | 1 |
| 空 | | 399609 | 用户 | ip6.us-west-2.compute.internal:58037 | 数据库 | 睡觉 | 1 |
| 空 | | 399669 | 用户 | ip4.us-west-2.compute.internal:62615 | 数据库 | 睡觉 | 0 |
| 空 | | 399682 | 用户 | ip3:9507
| 空 | 查询 | 0 | 空 | 节目制作人 | | 399696 | 用户 | 服务器1：53241 | 数据库 | 睡觉 | 1 | | 空
| | 399704 | 用户 | 服务器1：53242 | 数据库 | 睡觉
| 0 | | 空 | | 399705 | 用户 | ip4.us-west-2.compute.internal:62618 | 数据库 | 睡觉 |
0 | | 空 | | 399706 | 用户
| ip4.us-west-2.compute.internal:62619 | 数据库 | 睡觉 | 0 |
| 空 | | 399707 | 用户 | ip4.us-west-2.compute.internal:62620 | 数据库 | 睡觉 | 0 |
| 空 | +--------+------------------+------------------------ ------------------------------+------------+------ ---+-------+----------------------------+-------- ----------+

显示引擎 INNODB 状态

我无法正确格式化数据，所以我把它放在 pastebin http://pastebin.com/JETQ6KG3

谢谢你。

早上再次重新启动服务器以释放内存。

Answer 1

MySQL 直到版本 5.7 （目前正在开发中）才对内存进行检测，因此这确实使您的问题有点像猜谜游戏。

我可以从 InnoDB 状态内部看到，它似乎不是 InnoDB 消耗内存（假设您在问题发生时收集了此信息）：

Total memory allocated 26217103360; in additional pool allocated 0
Dictionary memory allocated 1212141
Buffer pool size   1563519

总内存：24.41 GiB（InnoDB 需要比内部结构的缓冲池多 5-10%）缓冲池内存：~23.85 GiB

我不得不猜测内存是在 MySQL 层（而不是 InnoDB）消耗的，两个常见原因是内部临时表和非常大的排序/连接缓冲区。