Richard Yen 将在 10 月 1 日的 PG Summit 2026 上分享用 Postgres 做硬件基准测试的经验，并提前聊了聊选题动机。
想测磁盘速度用 fio，想测 CPU 单项操作也有更合适的工具，这些组件级测试能说明单个部件的情况。但 Postgres 基准测试的目标不是复现产品页上的营销数字——比如三星 EVO Plus 990 标称读写 7,150/6,300MB/s，但正经的 Postgres 集群很难跑到这个值。
Postgres 是包含内存、并发、缓存、WAL、检查点、后台进程和多种维护机制的复杂系统，这些可能同时发生。跑十秒的基准可能只测到系统里又热又快的一小片，却漏掉了生产环境真正值得关注的部分。有经验的 DBA 或 DBRE 知道 autovacuum 会在负载运行时产生额外工作，检查点会带来 I/O 突发，高并发负载可能在存储设备忙起来之前就撞上锁竞争或连接数上限，缓存状态也会改变问题本身。
所以该问的问题不是「这块 SSD 多快」，而是「这个工作负载在这套系统上能否跑得可接受，系统还能承受多少」。定义工作负载是基准测试的第一步：是大量小并发事务的 OLTP，还是大扫描大 join 的分析型负载，或是宽 JSON 文档、可压缩值、高写入量的场景。确定负载后，在受控步骤中调参并监控不同指标，当吞吐停止增长、延迟超标或某资源饱和时，就能更清楚数据库整体的能力边界，第一个瓶颈也指明了下一步方向。
可信的基准要跑足够久以覆盖几个 autovacuum 和检查点周期，并且可重复。应记录配置、数据集、客户端位置、预热期、测量窗口和验收标准，还要测试系统过载后能否恢复。严格的硬件基准测试仍有其位置，但应单独做——fio 适合回答存储性能问题，Postgres 基准测试的目标是理解特定数据库负载能否跑在特定系统上、在哪里停止扩展、先遇到哪个约束。
演讲将深入这套流程，涉及 HammerDB、pgbench、工作负载设计，以及帮助定位真正瓶颈的证据。
🔗 原文：postgr.es/p/9uu