RDS多可用性瓶颈写入性能

Question

我们在sa-east-1区域使用RDS MySQL 5.6实例（db.m3.2xlarge），在写入密集型操作期间，我们看到（在CloudWatch上）我们的写入吞吐量和网络传输吞吐量都限制在60MB / s 。

我们怀疑多可用区可能会对此行为负责，并将其关闭以用于测试目的。 我们做了相同的操作，现在注意到Write Througput不再受限制，网络传输吞吐量实际上为零。 这强化了这种网络流量在多可用区设置上的主实例和故障转移实例之间的想法。

以下是Cloudwatch图表，显示没有多可用区的操作，并且在启用了多可用区的同一个操作之后：

我们尝试将实例升级到具有最高网络性能的实例，并且还配置了IOP，但没有任何变化，当多可用区开启时，我们的写入总是限制在60MB / s。

我们的理解是，多可用区使用同步数据复制，但我们无法找到有关此复制发生的链路的带宽限制的任何信息。 有谁知道它以及如何避免这种限制？ 或者我们应该忍受它吗？

Answer 1

我不认为您看到复制服务本身的限制，但看起来您的复制带宽与您的实例上的EBS卷共享相同的传输，因此它限制了您的实例本身可用的以太网带宽（记住EBS是网络附加存储）。

m3.2xlarge上的网络连接为1000 Mbit / s，相当于125 MiB / s。

将该数字除以2，您可以获得~60 MB / s的速度来写入本地实例的EBS卷，另一个~60 MB / s则可以写入同步副本。

不幸的是，多边复制复制的实现细节并不是AWS公开解释的足够详细的内容，最终确实说这确实是解释，但这些数字可疑地接近于正确预测的数据。

m3系列和m4系列实例具有相似的规格，但（显然）也存在一些基本的设计差异，因此可以了解m4.2xlarge的相同行为是否正确。

Answer 2

我遇到了同样的问题，在激活Multi AZ后，Write Latency显着增加：

（实例类型为m4.4xlarge）

原因看起来是同步同步过程，每个写入操作都必须等到两个DB都对修改做出积极响应。

看起来没有解决方案，这是一个预期的行为：

由于发生同步数据复制，与单可用区部署相比，使用多可用区部署的数据库实例可能会增加写入和提交延迟

- 来自AWS文档

这是一个有趣的Redis线程：

• https://www.reddit.com/r/aws/comments/61ewvp/rds_multiaz_slow_insert/

我看到的唯一建议是搬到Aurora ：/

Answer 3

好吧，我从来没有从任何地方得到任何实际的解释，但经过大量的测试，似乎m3.2x.large实际上是“窃听”。 我在博客中写了详细的解释。