队列深度突然增加，读/写IOPS

Question

3个月前，我们的数据库运行了16 GB的ram，4 vcpu和60 GB的磁盘（m4.xlarge aws rds计算机），并且一直运行良好，直到一瞬间到另一时为止，它开始增加队列深度以及读写延迟。在那种情况下，我们重新启动并将数据库升级到32 GB的ram，8 vcpu（m4.2xlarge实例），问题消失了。

当然，这在时间上是不可持续的，但我们找不到确切的原因。我们确实知道我们的流量以及数据库操作正在增加，但是肯定不会增加大小。

问题是，在3个月后，今天又出现了问题：32 GB 8 vcpu，再次，作为紧急按钮，我们升级到了64 gb 16 vcpu。为了确保安全，我们还将磁盘大小复制到120 GB。事件发生时流量并没有突然增加，而且，我可以确保流量不会比3个月前增加两倍。不过，在这3个月中，我们分析了慢查询日志并通过添加一些索引改进了一些查询。

我们现在拥有（相关表）此表和索引

我们不是数据库专家，但是对于我们的数据库来说，这似乎并不算太​​繁忙（我们正在Rails电子商务应用程序上运行ruby）。我们认识到“可用内存”始终超过20 GB，磁盘始终超过15 GB。但是，如果ram是免费的，我们也不知道为什么有100MB的交换空间。

以下是aws最近6小时的监视图，中间是事件，然后是18:15左右的比例。

Answer 1

希望此举能在将来节省一些人的麻烦。过去，这使我们头疼不已！

在AWS RDS存储（通用）上，会根据磁盘空间为您提供特定数量的读取/写入IOPS。该数量（在撰写本文时）为每GB存储3 IOPS。对于60GB的磁盘空间，您将获得180个IOP，并具有一些额外的突发容量。

从图表中，您在一个持续的时间内超过了总IOPS，这导致您的突发信用用尽，并且延迟+队列深度显着增加。您可以通过AWS Cloudwatch中的RDS DB指标“突发余额”来衡量突发信用。如果它变为0，则您将经历一段糟糕的时光。

您无需增加RDS实例大小即可解决此问题，只需增加磁盘空间即可。根据使用情况，您可能需要2000 IOPS，大约670 GB磁盘。即使您不需要那么多的存储，也只需要为其提供正确的IOPS。另一个解决方案是购买专为高吞吐量工作负载而构建的“ Provisioned IOPS Storage”。

请参阅以下有关I / O信用和突发性能的部分： https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html