IOPS或吞吐量？ - 确定Amazon RDS实例中的写入瓶颈

Question

我们每晚都会将数十万条记录的作业加载到Amazon RDS中运行的Mysql报告数据库中。

负载工作需要几个小时才能完成，但我很难搞清楚瓶颈在哪里。

该实例当前正在使用通用（SSD）存储。通过查看云观察指标，我觉得上周的平均值不到50 IOPS。但是，网络接收吞吐量小于0.2 MB /秒。

无论如何，从这些数据中可以看出我是否因为网络延迟而受到瓶颈（我们目前正在从远程服务器加载数据......这最终会改变）或者写入IOPS？

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

任何建议表示赞赏。

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

Answer 1

你没有耗费太多的CPU。你的记忆非常低。拥有更多内存的实例应该是一个很好的胜利。

你只做了50-150次iops。那个低，你应该在标准的SSD级存储上突破3000。但是，如果您的数据库很小，则可能会对您造成伤害（因为您每GB获得3次i-所以如果您使用的是50gb或更小的数据库，请考虑支付配置的iops）。

您也可以尝试Aurora;它说的是mysql，据说性能很好。

如果你可以分散你的写作，那么尖峰会更小。

Answer 2

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

如果远程数据库具有例如75毫秒的往返时间，则如果执行速度超过1000（毫秒/秒）/ 75（毫秒/往返）=每秒13.3次查询，则不能执行您正在使用单一连接。没有绕过物理定律。

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

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

Answer 3

一个非常快速的测试是购买预配置的IOPS，但要小心，因为在爆发期间你可能会比现在少得多。

确定瓶颈的另一个快速方法是使用了解数据库驱动程序的分析器来分析作业执行应用程序。如果您使用的是Java，JProfiler将显示您的工作特征并使用数据库。

第三种是配置数据库驱动程序以打印有关数据库工作负载的统计信息。这可能会通知您，您发出的查询数量远远超出预期。

Answer 4

我不是RDS专家，我不知道我自己的具体案例是否会让你有所帮助。无论如何，希望这给你任何一种见解。

我在一个通用SSD存储上配置了200GB的db.t1.micro（它提供了600 IOPS的基准性能）。

最繁重的工作量是当我从一个1000万行表和另一个800万行中聚集了大约250万行的数据库中的数千条记录时。我每天都这样做。这就是我的平均值（这是稳定的性能，不像你看到的峰值模式）：

• Write / ReadIOPS：+600 IOPS
• NetworkTrafficReceived / Transmit throughput：＆lt; 3,000字节/秒（我的查询相对较短）
• 数据库连接：15（工作人员聚合并行）
• 队列深度：7.5计数
• 读/写吞吐量：每秒10MB

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

同时检查来自AWS Summit 2014的10 tips to improve The Performance of your app in AWS slideshare。

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

Answer 5

就我而言，这是记录的数量。我每分钟只写了30个记录，并且写入IOPS大约是20到30左右。但这是在CPU吃掉了，这大大减少了CPU信用。因此，我将该表中的所有数据移至另一个“历史”表中。并清除该表中的所有数据。

CPU回落到正常的措施，但写入IOPS保持不变，但这很好。问题：索引，我认为因为在插入时需要索引的记录太多，所以需要更多的CPU来用这个行进行索引。即使我唯一的索引是主键。

我的故事的道德，问题并不总是你认为它在哪里，虽然我增加了写入IOPS，这不是问题的根本原因，而是在插入时用来做索引的CPU导致CPU信用下降。

Lambda上的X-RAY甚至不会增加查询时间。那是我开始直接看DB的时候。

Answer 6

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

我认为您已使用默认的AUTOCOMMIT = 1（自动提交模式）。对于每个插入，它都会对磁盘执行日志刷新，并耗尽IOPS。

因此，如果插入查询看起来像这样，最好在MySQL中批量插入数据之前使用（用于性能调整）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 

在t2.micro中使用上述方法，并在15分钟内使用PHP插入了300000。