我们在 db.t2.large 实例上使用 RDS。一个自动扩展的 EC2 组在白天将数据写入数据库。在高峰时间，我们有大约 50.000 个 HTTP 请求，每个请求读取/写入 MySQL 数据。
这每天都在变化，但对于今天的示例，在一小时内：
我们从 PHP 实例中看到“连接错误 (2002) 连接超时”，大约每分钟 187 次。
- RDS CPU 不会提高到 50% 以上
- DB Connections 不会超过 30（最大值设置为 5000）。
- 免费存储空间约为 300G（磁盘容量很大以提供高 IOPS）
- 在高峰时间之后，写入 IOPS 达到 1500 突发，但由于突发限制已过期而降至 900。
- 读取 IOPS 每 10 分钟达到 300 次，中间达到 150 次左右。
- 磁盘写入吞吐量平均在 20 到 25 MB/秒之间
- 磁盘读取吞吐量在 0.75 到 1.5 MB/秒之间
- CPU Credit Balance 大约为 500，因此我们不需要 CPU 突增。
当谈到网络时，我看到了我们正在达到的潜在限制：
- 网络接收吞吐量达到 1.41 MB/秒，并在一小时内保持在 1.5 MB/秒左右。
- 在此期间，网络传输 5 a 5.2 MB/秒，每 10 分钟下降到 4 MB/秒，这与我们正在处理数据的 cronjobs 一致（主要是读取）
我尝试将 EC2 放置在不同或相同的 AZ 中，但这没有效果
在此期间，我可以通过 SSH 隧道（EC2 -> RDS）从本地工作站正常连接。从 EC2 到 RDS 也是如此。
PHP 脚本设置为在尝试连接 5 秒后超时，以确保快速响应。对于某些脚本，我现在将此限制增加到 15 秒。
但是我们对 RDS 的限制是什么？在我们开始迁移或更改实例类型之前，我们想知道这个问题的根源。我还刚刚启用了增强监控以获取有关此问题的更多详细信息。
如果需要更多信息，我很乐意在需要的地方详细说明。
谢谢！
更新 25/01/2016
根据 datasage 的建议，我们将 RDS 磁盘大小增加到 500 GB，这为我们提供了 1500 IOPS 和 3600 突发，它使用了大约 1200 IOPS（所以现在甚至没有突发）并且仍然发生超时。
如前所述，连接超时设置为 5 秒和 15 秒，显示没有区别。
更新 26/01/2016
我们高峰时段的 RDS 屏幕截图：
2016 年 1 月 28 日更新
我已将设置更改sync_bin_log为 0，因为最初我认为我们达到了 EBS 吞吐量限制（GP-SSD 160 Mbit/s），这使我们的磁盘吞吐量显着下降并且 IOPS 也更低，但我们仍然看到连接超时发生。
当我们绘制错误发生的时间时，我们看到每分钟大约 :40 秒时超时开始发生在大约 25 秒内，然后在大约 35 秒内再次没有错误并再次开始。这是在我们传入流量的高峰时段。