Postgres 并不慢，而是你的存储慢

在 POSETTE 2026 上，Sai Srirampur 发表了“Postgres 并不慢。你的存储才是。”探讨存储如何大规模影响 PostgreSQL 性能的演讲。这篇文章回顾了基准测试、结果揭示的内容以及在生产中在本地 NVMe 上运行 PostgreSQL 所建议的架构。您可以在下面链接的视频中观看完整的演讲。演讲首先介绍了大规模运行 Postgres 的团队可能会认识到的几个症状：摄取速度变慢、P95 读取延迟变得不可预测、autovacuum 落后、检查点与实际工作负载争夺资源，或者逻辑复制累积滞后。这些问题并不总是有相同的原因，但它们可能有一个容易被忽视的共同点：存储性能。为了了解原因，Sai 运行了一个基准测试，比较了基准 gp3 EBS 和本地 NVMe 上相同的 33 亿行 PostgreSQL 工作负载。我们将逐步介绍设置以及 Sai 在分析结果时发现的内容，然后介绍在本地 NVMe 上运行 Postgres 所建议的生产模式。一旦 PostgreSQL 工作负载达到数百 GB 或 TB 并且以真正的并发性和吞吐量运行，通常会出现五个常见问题。缓慢摄入。第一个是大量更新和UPSERT 的摄取管道。随着数据量的增长，曾经在几秒钟内完成的作业可能会延长到几分钟。读取延迟不一致。下一个出现在大多数查询保持快速但少数查询速度显着变慢的工作负载中。 P95 延迟从毫秒变为秒，仪表板超时，并且不均匀的减速使得原因更难隔离。 VACUUM 落后了。第三个问题是，随着 UPDATE 和 UPSERT 吞吐量的增长，autovacuum 会落后，表膨胀从 GB 级累积到 TB 级。检查站较慢。检查点还可能需要更长的时间，并与 I/O 和 CPU 的客户端工作负载竞争，从而将以前不可见的操作变成反复出现的延迟峰值。逻辑复制滞后。当 PostgreSQL 数据流式传输到 Kafka 或 ClickHouse 等系统时，会出现最后一个症状。 WAL 解码可能很慢，并且不断增长的复制槽会使问题变得更加复杂。随着工作集的增长超出了 PostgreSQL 和操作系统页面缓存可用的内存，更多的数据读取需要物理 I/O。在较慢的存储上，较高的成本和这些读取的排队可能会增加平均延迟和尾延迟。客户端查询和后台维护也使用相同的存储预算。堆和索引写入、WAL 同步、检查点、VACUUM 和逻辑解码溢出会争夺带宽、IOPS 和队列容量。一旦存储达到这些限制之一，操作就会开始相互延迟。这就是为什么缓慢的存储可能成为几个明显不相关的 PostgreSQL 问题的根本原因。本地 NVMe 的优点并不是它消除了 I/O，而是它可以大幅降低成本。该比较将网络附加存储上的毫秒级操作与本地 NVMe 上可能在数十微秒内完成的操作进行了对比。缓存未命中、WAL 刷新和维护 I/O 仍然会发生，但它们对整个系统的影响不会那么大。为了更好地理解为什么会出现这种情况，Sai 设置了一个简单的实验来比较在 EBS 和本地 NVMe 上运行的 PostgreSQL 上的类似工作负载。为了将存储隔离为变量，基准测试使用了八个相同的 PostgreSQL 集群：四个使用实例存储 NVMe，四个使用以 3,000 IOPS 配置的基线 gp3 EBS。每个集群都在具有 16 个 vCPU、64 GiB RAM 和 16 GiB 共享缓冲区的 m6id.4xlarge 实例上运行。我们为每种存储类型使用多个实例，以规范基准运行之间的变化。该设置使用了包含 33 亿行的 482 GiB pgbench_accounts 堆。然后，每个集群使用 64 个客户端和 16 个工作线程运行相同的高度并发随机更新工作负载五分钟： 1 \ set acid random( 1 , 3300000000 ) 2 UPDATE pgbench_accounts SET abalance = abalance + 1 WHERE aid = :aid;复制命令 简而言之，两组之间的唯一区别是存储类别。该基准测试为 NVMe 集群生成的 TPS 中值为 16,030 TPS，而 EBS 为 1,734 TPS，在本次测试中相差 9.24 倍。中位事务延迟从 36.9 毫秒降至 4.0 毫秒。对于不同的操作，NVMe 在 366 秒内完成了超过 10 GB 膨胀的 VACUUM，而 EBS 则为 964 秒，并在 139 秒而不是 238 秒内耗尽了 10 GB 逻辑复制积压。有一个条件很重要：这些结果适用于该工作负载和这些存储配置。 EBS 端使用以 3,000 IOPS 配置的基线 gp3，不同的 EBS 设置很可能会产生不同的结果。通过查看 37 毫秒的 EBS 事务延迟的去向，吞吐量差距变得更容易理解。在此基准测试中，EBS 上的页面读取时间约为 19 毫秒，而 NVMe 上的页面读取时间为 0.3 毫秒。 WAL fsync 在 com