尽管数据库连接数较少，但 AWS RDS 显示写入操作数/秒大幅增长？

Question

我有一个运行 MYSQL 5.5 的多可用区 AWS RDS 实例

我注意到我的写操作/秒增长相当快，尽管数据库连接很少（有时为零） - 请参阅过去 12 个月和过去 2 周的平均写操作/秒图表，以及过去 2 周的平均数据库连接：

我知道总体上写操作/秒的水平很低，但我预计在接下来的几个月里会有更多的容量（比如 100 倍），并希望确保我能解决任何问题。

我试图了解导致这些写入操作的原因。我尝试连接到 RDS 实例并执行：

show full process list

这表明：

+--------+----------+---------------------------------------------------+-------+---------+------+-------+------------------+
| Id     | User     | Host                                              | db    | Command | Time | State | Info             |
+--------+----------+---------------------------------------------------+-------+---------+------+-------+------------------+
|      7 | rdsadmin | localhost:51067                                   | mysql | Sleep   |    9 |       | NULL             |
| 705938 | rdsuser  | ip-xx-xx-xx-xx.eu-west-1.compute.internal:xxxx | NULL  | Query   |    0 | NULL  | show processlist |
+--------+----------+---------------------------------------------------+-------+---------+------+-------+------------------+

即没有活动线程。

欣赏任何关于正在发生的事情的想法。

更新 感谢罗兰的回应，我做了一些进一步的挖掘。特别是，我向 RDS 实例添加了常规日志记录和慢速查询日志记录，并看到我每分钟都在运行的一个 cron 作业正在执行不必要的查询，这使得该实例做了很多不需要的工作。

我通过在 RDS 管理控制台中创建一个新的参数组并设置来打开日志记录：

general_log = 1
slow_query_log = 1
long_query_time = 1

请注意，我还使用了

CALL mysql.rds_rotate_slow_log;

和

CALL mysql.rds_rotate_general_log;

旋转日志文件 - 因为它们很快就会变得非常大。

Answer 1

如果这些进程是 MySQL 实例中唯一的数据库连接，那么您只能查看两个写入 I/O 源

包含 MySQL 的虚拟机

由于您使用的是 Amazon MySQL RDS，因此您只能访问其配置的 VM 内的 MySQL 实例。出于内部目的，可能会从 MySQL 进行大量读取。请注意，进程 ID 7 是rdsadmin。他们可以在磁盘上汇总 MySQL 使用情况的统计信息，以向他们提供的 RDS API 报告以呈现统计信息。

我相信您可以通过将我们的数据移动到 Amazon EC2 实例上的 MySQL 来消除这个问题。当然，您必须对自己的统计数据负责。

InnoDB架构

InnoDB 有许多需要写入的移动部件。

• 缓冲池
  • InnoDB 表中已修改（脏）的数据和索引页必须系统地写入系统表空间（又名 ibdata1）内的双写缓冲区
  • 插入缓冲区，即对二级索引的更改，必须系统地写入系统表空间内的插入缓冲区
• 日志缓冲区：当已满时，日志缓冲区内的更改必须写入重做日志（也称为 ib_logfile0、ib_logfile1）。在高写入系统中，应将innodb_log_buffer_size增加到256M 以减少对重做日志的写入。
• 回滚段/撤消空间：系统表空间内有 1023 个回滚段。每次执行 INSERT、UPDATE 和 DELETE 时，一个事务将使用单个回滚段来保存该事务将要更改的数据的先前状态。有内部线程专门用于清理UNDO空间。因此，大量的大写入（甚至小写入）将需要来自执行 UNDO 空间清理的内部线程的磁盘 I/O。

我之前写过这个

• Jul 21, 2012：InnoDB - ibdata1 文件和 ib_logfile0 上的高磁盘写入 I/O
• May 17, 2012:为什么所有事务都停止两小时后mysql还在写数据