在 MySQL (RDS) 服务器上寻找高写入 IOPS 背后的原因

Question

我遇到了 AWS RDS 实例（运行 MySQL 5.6）的性能问题。

这是一个名为 Tigase 的 XMPP 服务器的后端数据库。根据 Tigase Inc. 的说法，这种类型的数据库实例应该能够处理至少比目前多一个数量级的流量。db 是瓶颈是非常罕见的。通常 Tigase 服务器在 db 之前成为瓶颈。

在 AWS 管理控制台中查看我们的监控数据时，我们发现主要是 CPU 和写入 IOPS 是问题所在。读取 IOPS 可以忽略不计。

因为我还没有写过 Tigase，所以我很难知道高负载背后的原因。因此，我的问题是：我应该如何找到导致此问题的根本原因的查询和/或配置设置？你推荐我使用哪些工具？我有相当丰富的 DBA 经验，但我是 MySQL 的新手。

以下是 MySQL Workbench 性能仪表板的屏幕截图。

谢谢！

Answer 1

显示的 RDS 统计数据过于全面和广泛​​，无法回答“谁应该为增加的负载负责？”的问题。

有几种方法可以分析您的查询，但是当您将 RDS 与 MySQL 5.6 一起使用时，我建议您使用PERFORMANCE_SCHEMA它轻松完成，因为您不需要外部软件（其中一些与 RDS 不完全兼容）。这里有一个介绍查询分析的视频，其中包含 IOPS 和通过查询模式、用户和表监控临时表创建等示例。有关更具体的指南（特别是指标配置），您可以查看官方手册和sys schema 文档。

为了快速检查，您还可以查看您的时间间隔SHOW GLOBAL STATUS like 'com\_%';和SHOW GLOBAL STATUS like 'Hand%';时间间隔，以查看每单位时间的 SQL 查询数量或每单位时间的引擎行操作数量是否有所增加（第一个是根据显示的图表似乎没有异常）。

您的目标是首先检测有问题的查询，以便您可以相应地修改 SQL、您的数据结构、MySQL 配置和/或任何外围设备（例如您的 RDS 实例是否仍然足够好）。写入 IOPS 的增加通常可能意味着额外的 SQL 负载（显然），但也意味着许多其他事情，例如：由于查询优化器计划或数据基数/大小的更改，正在执行的临时表过多或更差的查询计划. 在采取任何行动之前首先确定根本原因至关重要。