6

我们有 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 不是一个因素？
4

2 回答 2

10

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

但万一有人发现了这个话题，当您用完 GP2 积分时，CloudWatch 会是这样的。如您所见，读取和写入 IOPS 图表并没有告诉我们太多信息，但读取/写入延迟图表显示出巨大的峰值。

就上下文而言，这些是用于分析的 PostgreSQL 只读副本的 2 周。从 100GB GP2（300 基本 IOPS，11.50 美元/月）到 100GB io1（1000 IOPS，112.50 美元/月）的切换发生在这些图表的 2/3 左右（不再出现延迟峰值）。更便宜的选择是增加 GP2 存储的数量。预置 IOPS 的价格高得离谱，但在这种情况下，在繁重工作负载期间的可预测行为是有意义的。

RDS Cloudwatch 图表：读/写操作 RDS Cloudwatch 图表：队列深度、副本滞后、R/W 延迟

于 2016-03-01T18:54:26.253 回答
5

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

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

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

顺便提一句：

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

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

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

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

于 2014-12-19T09:17:58.273 回答