我们有每晚的加载作业，这些作业会将数十万条记录写入到在Amazon RDS中运行的Mysql报告数据库中。
加载工作需要花费几个小时才能完成，但是我很难弄清瓶颈在哪里。
该实例当前正在与通用(SSD)存储一起运行。通过查看cloudwatch指标，看来我上周的平均IOPS不到50。但是，网络接收吞吐量小于0.2 MB/秒。
无论如何，是否可以通过此数据判断出我是否受到网络延迟(我们当前正在从远程服务器加载数据...最终会改变它)或写入IOPS的瓶颈？
如果IOPS是瓶颈，我可以轻松升级到Provisioned IOPS。但是，如果网络延迟成为问题，我将需要重新设计加载作业，以从EC2实例而不是远程服务器加载原始数据，这将需要一些时间来实现。
任何建议表示赞赏。
UPDATE :
有关我的实例的更多信息。我正在使用m3.xlarge实例。它提供了500GB的大小。加载作业是使用pentaho的ETL工具完成的。它们从多个(远程)源数据库中提取并使用多个线程插入RDS实例。
最佳答案
您不会消耗太多的CPU。您的内存力很低。具有更多内存的实例应该是一个不错的选择。
您只做50-150 iops。太低了，您应该在标准SSD级别的存储中爆发3000。但是，如果您的数据库很小，则可能会伤害您(因为每GB获得3 iops，因此，如果您使用的是50gb或更小的数据库，请考虑为预配置的iops付费)。
您也可以尝试Aurora。它说的是mysql，据称具有出色的性能。
如果您可以分散写操作，则尖峰将较小。