我们是否需要为RDS实例提供IOPS，即根据监控使用60 IOPS？

Question

我们有PostgreSQL实例每秒提供数十个r/w查询。

• 实例类型: db.m3.2xlarge
• 实例提供的IOPS (SSD)：1000
• 实例存储大小:100 is，数据库大小约为5-10 is。

它为100多个同时进行读写查询的客户端提供服务。然而，当我们看云监视时，它显示IOPS在20-60之间。

并且阅读iOPS是在0左右！

​

​

这样做不对，因为100多个连接和客户机一直在执行读/写查询？Postgres配置是标准的，我们没有关闭fsync。

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

为此db实例支付1000 IOPS的额外费用为300美元。你能买到的最低IOPS是1000。

我想知道我们能不能不用IOPS？

• 或者AWS监控不正确？
• 或者如果我们有非IOPS服务器的话，我们现在拥有的20个IOPS会降低服务器的性能？
• 或者5GB的数据库，它主要适合缓存和IOPS不是一个因素？

Answer 1

@CraigRinger是正确的。如果您的数据集足够小，可以完全安装在内存中，那么您将不需要配置IOPS，因为insert/update通信量和日志是唯一使用的IOPS。

但是，如果有人发现了这个主题，下面是CloudWatch在您用完GP2学分后的样子。正如您可以看到的，读和写IOPS图表并没有告诉我们太多，但是读/写延迟图显示了大量的尖峰。

对于上下文，这是一个用于分析的PostgreSQL读取副本的2周。从100 mo的GP2 (300BaseIOPS，$11.50/mo)到100 mo的io1 (1000IOPS，$112.50/mo)发生了2/3的转变(不再有延迟高峰)。更便宜的选择应该是增加GP2存储的数量。提供的IOPS价格过高，但是在这种情况下，在繁重的工作负载期间，可预测的行为是有意义的。

​

Answer 2

您的DB几乎完全缓存在RAM中。(您可以使用pg_buffercache扩展来确认这一点)。这些IOPS数字完全是意料之中的。我希望这台服务器在没有配置IOPS的情况下是正常的。

如果您重新启动实例，那么它在构建缓存时会慢一段时间，但是5GB并不适用。另外，配置iops实际上使情况更糟，因为除了设置最低I/O速率外，管道也设置了最大值。这是一个目标利率不是最低的。

相比之下，常规卷的读取速率可能比piops卷高得多，因此当您重新启动缓存时，它们的性能会更好。

顺便说一下：

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

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

这实际上比重新启动后的情况更糟糕，因为它也将二进制文件和库从内存中删除。系统一开始会非常频繁地运行，因为它会将频繁访问的二进制文件和库读入RAM中。然后，您将开始看到缓存恢复行为，就像重启之后一样。

而且，配置了太多的连接。安装pgbouncer，将其放在数据库前面，并减少max_connections。你会得到更好的表现。