Mysql IOPS还是吞吐量Amazon RDS实例中写入瓶颈的确定

我们每天晚上都要加载作业，将数十万条记录写入运行在AmazonRDS中的Mysql报告数据库

加载作业需要几个小时才能完成，但我很难找出瓶颈在哪里

该实例当前正在使用通用（SSD）存储运行。通过查看cloudwatch指标，我上周的平均IOPS似乎低于50。但是，网络接收吞吐量小于0.2 MB/秒

如果网络延迟（我们目前正在从远程服务器加载数据…这最终会改变）或写入IOPS限制了我的工作，那么是否可以从这些数据中判断我的工作

如果IOPS是瓶颈，我可以轻松升级到配置的IOPS。但是，如果网络延迟是个问题，我需要重新设计加载作业，从EC2实例而不是远程服务器加载原始数据，这需要一些时间来实现

任何建议都将不胜感激

更新： 关于我的实例的更多信息。我正在使用一个m3.xlarge实例。它的容量为500GB。加载作业是使用pentaho的ETL工具完成的。它们从多个（远程）源数据库中提取，并使用多个线程插入RDS实例

---

您没有占用太多CPU。你的记忆力很差。拥有更多内存的实例应该是一个很好的胜利

您的iops仅为50-150。这很低，在标准SSD级存储上，一次突发应该可以获得3000。但是，如果你的数据库很小，它可能会伤害你（因为你每GB获得3个IOPS），所以如果你在一个50GB或更小的数据库上，考虑支付所提供的IOP）。 你也可以试试极光；它讲mysql，据说有很好的性能

---

如果您可以分散写入，峰值将更小。

远程访问数据库最可能的罪魁祸首实际上是往返延迟。这种影响很容易被忽视或低估

例如，如果远程数据库具有75毫秒的往返时间，则如果使用单个连接，则不可能每秒执行超过1000（毫秒/秒）/75（毫秒/往返）=13.3个查询。物理定律是绕不开的

峰值表明加载过程中效率低下，它会聚集一段时间，然后加载一段时间，然后聚集一段时间，然后加载一段时间

---

单独但相关，如果您没有在客户端启用MySQL客户端/服务器压缩协议。。。了解如何启用它。（服务器始终支持压缩，但客户端必须在初始连接握手期间请求压缩），这不会解决核心问题，但应在一定程度上改善这种情况，因为物理传输的数据越少，传输过程中浪费的时间就越少。

我不是RDS专家，我不知道我自己的具体情况是否能给你一些启示。不管怎样，希望这能给你一些启示

我有一个配置了200GB的db.t1.micro（这将提供600 IOPS的基线性能），它位于通用SSD存储上

最繁重的工作是从一个1000万行表和另一个800万行表中的大约250万行池中汇总数千条记录。我每天都这样做。这是我的平均值（这是稳定的性能，与你的不同，我看到的是尖峰模式）：

• 写入/读取IOPS:+600 IOPS
• 网络流量接收/传输吞吐量：<3000字节/秒（我的查询相对较短）
• 数据库连接：15（并行聚合工作人员）
• 队列深度：7.5次
• 读/写吞吐量：每秒10MB

整个聚合任务大约需要3个小时

同时查看AWS Summit 2014的幻灯片

---

我不知道还能说什么，因为我不是专家！祝你好运

一个非常快速的测试是购买配置的IOPS，但要小心，因为在突发事件期间，您可能会得到比当前更少的IOPS

确定瓶颈的另一种快速方法是使用了解数据库驱动程序的探查器来评测作业执行应用程序。如果您使用的是Java，JProfiler将显示您的工作的特征以及它对数据库的使用

---

第三种方法是配置数据库驱动程序以打印有关数据库工作负载的统计信息。这可能会告诉您，您发出的查询比您预期的要多得多。

在我的例子中，是记录的数量。我每分钟只写30条记录，写IOPS大约是20到30。但这是在消耗CPU，这大大降低了CPU的信用。因此，我将该表中的所有数据移动到另一个“历史”表中。并清除了表中的所有数据

CPU下降到正常测量值，但写入IOPS保持不变，不过这很好。问题是：索引，我想是因为插入时需要索引的记录太多了，用这么多的行进行索引需要更多的CPU。尽管我唯一的索引是主键

从我的故事中可以看出，问题并不总是出在你认为的地方，尽管我提高了写入IOPS，但这并不是问题的根本原因，而是插入时用于执行索引的CPU导致CPU信用下降

---

即使是Lambda上的X射线也无法捕捉到增加的查询时间。这就是我开始直接看数据库的时候

队列深度图显示>2，这清楚地表明IOPS配置不足。（如果队列深度<2，则IOPS设置过度）

我想您已经使用了默认的自动提交=1（自动提交模式）。它为每次插入执行磁盘日志刷新，并耗尽IOPS

因此，最好在批量插入d之前使用（用于性能调优）AUTOCOMMIT=0

 set AUTOCOMMIT = 0;
 START TRANSACTION;
 -- first 10000 recs 
    INSERT INTO SomeTable (column1, column2) VALUES (vala1,valb1),(vala2,valb2) ... (val10000,val10000);
 COMMIT;
 --- next 10000 recs
 START TRANSACTION;
    INSERT INTO SomeTable (column1, column2) VALUES (vala10001,valb10001),(vala10001,valb10001) ... (val20000,val20000);
 COMMIT;
  --- next 10000 recs
 .
 .
 .
set AUTOCOMMIT = 1