我们是否需要根据监控使用60 IOPS的RDS实例的预配置IOPS？

Question

我们有PostgreSQL实例每秒服务数十个r/w查询.

• 实例类型:db.m3.2xlarge
• 实例预配置IOPS(SSD):1000
• 实例存储大小:100GB,数据库大小约为5-10GB.

它为具有读写查询的100个并发客户端提供服务.然而,当我们查看Cloudwatch Monitoring时,它显示的IOPS范围为20-60.

并且读取iOPS大约为0!

对于100个连接和客户端始终执行读/写查询,这是不对的？Postgres配置是标准配置,我们没有关闭fsync.

缓存是否如此有效以至于IOPS不是数据库大小为5GB的因素？或AWS监控控制台错误？

为此数据库实例支付1000 IOPS额外花费300美元.您可以购买的最低IOPS是1000.

我想知道我们能不做IOPS吗？

• 或AWS监控不正确？
• 或者,如果我们有非IOPS服务器,我们现在拥有的20 IOPS将会破坏服务器性能？
• 或者使用5GB数据库,它主要适用于缓存和IOPS不是一个因素？

Answer 1

@CraigRinger是对的.如果您的数据集足够小以完全适合内存,则不需要预配置IOPS,因为插入/更新流量和日志是唯一消耗的IOPS.

但是如果有人发现了这个话题,那么当你耗尽GP2学分时,这就是CloudWatch的样子.正如您所看到的那样,读取和写入IOPS图表并没有告诉我们太多,但读/写延迟图表显示出大量的峰值.

对于上下文,这些是用于分析的PostgreSQL读取副本的2周.从100GB GP2(300 Base IOPS,$ 11.50/mo)到100GB io1(1000 IOPS,$ 112.50/mo)的转换大约在这些图表的2/3路径(没有更多的延迟峰值).更便宜的选择就是增加GP2存储量.预配置的IOPS价格过高,但在这种情况下繁重的工作负载期间可预测的行为是有道理的.

Answer 2

您的数据库几乎完全缓存在 RAM 中。（您可以使用pg_buffercache扩展确认这一点）。这些 IOPS 数字完全在意料之中。我希望这个服务器在没有预配置 IOPS 的情况下也能正常工作。

如果您重新启动实例，它会在一段时间内缓慢地构建缓存备份，但 5GB 并不多。此外，配置 iops 实际上会使情况变得更糟，因为除了设置最小 I/O 速率外，piops 还设置了最大值。这是一个目标率而不是最低值。

相比之下，普通卷可以爆到很多高读取速率比piops卷，所以他们会当你暖重启后的缓存备份有更好的表现。

顺便提一句：

重新启动数据库不会减慢它的速度，因为它只需要将数据从操作系统的磁盘缓存读回共享缓冲区。只有当你重新启动整个机器时，你才会看到一段时间的减速。如果你想在不重启的情况下模拟这个，你可以使用 Linux 的drop_caches特性：

  echo 1 | sudo tee -a /proc/sys/vm/drop_caches

这实际上比重启后的情况更糟糕，因为它也会从内存中驱逐二进制文件和库。系统一开始会很忙，因为它会将经常访问的二进制文件和库读回 RAM。然后您将开始看到缓存恢复行为，就像重新启动后一样。

此外，您配置了太多连接。安装pgbouncer，放在数据库前面，减少你的max_connections。你会得到更好的表现。