在大服务器上对现代Postgres和MySQL进行写入密集型sysbench测试

# 写密集型 sysbench 测试：大型服务器上的现代 Postgres 和 MySQL 来源：http://smalldatum.blogspot.com/2026/06/write-heavy-sysbench-tests-large-server.html 本文展示了使用 sysbench 的写密集型测试在大型服务器上对现代 Postgres 和 MySQL 的测试结果。我认为 Postgres 在 16、17、18 和 19 beta1 的某些版本中出现了性能回退，但我远不能确定，这篇博客只是我探索过程中又一步。 **tl;dr** - Postgres 在吞吐量波动方面受很大影响，而 MySQL+InnoDB 则没有 - 在 10 个测试中，InnoDB 在 6 个测试中平均吞吐量明显更好，在 1 个测试中相近，而 Postgres 在 3 个测试中表现更好 - 对于我提供了 vmstat 和 iostat 结果的测试，Postgres 每次操作写入的 IO 更多。在某些情况下，InnoDB 使用更多 CPU，在其他情况下则不是。 **构建、配置与硬件** 我编译了： - Postgres 源码版本 15.17、16.13、17.9 和 18.3 - MySQL 源码版本 8.4.7 我使用了 Hetzner 的一台 48 核服务器： - ax162s，搭载 AMD EPYC 9454P 48 核处理器，禁用 SMT - 2 块 Intel D7-P5520 NVMe 存储设备组成 RAID 1（每块 3.8T），使用 ext4 文件系统 - 128GB RAM - Ubuntu 24.04 Postgres 的配置文件： - 配置文件名为 conf.diff.cx10a\_c32r128 (x10a\_c32r128)，可在以下位置找到： versions15 (https://github.com/mdcallag/mytools/blob/master/bench/conf/arc/oct24/c32r128/pg157_o2nofp/conf.diff.cx10a_c32r128)、 16 (https://github.com/mdcallag/mytools/blob/master/bench/conf/arc/oct24/c32r128/pg163_o2nofp/conf.diff.cx10a_c32r128)、 17 (https://github.com/mdcallag/mytools/blob/master/bench/conf/arc/oct24/c32r128/pg17beta1_o2nofp/conf.diff.cx10a_c32r128) - 对于 Postgres 18，我使用了 conf.diff.cx10b\_c32r128 (https://github.com/mdcallag/mytools/blob/master/bench/conf/arc/oct24/c32r128/pg18beta3_o2nofp/conf.diff.cx10b_c32r128) (x10b\_c32r128)，该配置尽可能接近 Postgres 17 的配置，并使用 io\_method=sync **基准测试** 我使用了 sysbench，具体用法在此说明 (http://smalldatum.blogspot.com/2017/02/using-modern-sysbench-to-compare.html)。通常我运行该博客文章中列出的 42 个微基准测试中的 32 个，表的大小足够小以能被 DBMS 缓存。大多数测试只测试一种类型的 SQL 语句。 这些测试可以称为微基准测试。它们非常合成化。但微基准测试也便于理解哪些类型的 SQL 语句性能好或差。性能测试受益于多样化的负载——包括更合成和更真实的。 但这里我做了不同处理： - 我只运行写密集型测试（以节省时间） - 表的大小大于内存，无法被缓存 - 每个测试（微基准测试）运行 2 小时，而通常我每个运行 15 分钟 - 每个测试后执行一次 vacuum 目的是寻找由于新 CPU 开销和与 MVCC GC（Postgres 的 vacuum，InnoDB 的 purge）相关的互斥争用所导致的性能回退。 **结果** 下面我提供了相对 QPS 的图表。相对 QPS 定义为： > （某个版本的 QPS）/ （Postgres 15.17 的 QPS） 当相对 QPS > 1 时，表示 *某个版本* 比 *基准版本* 更快。当 < 1 时，可能存在性能回退。当相对 QPS 为 1.2 时，表示 *某个版本* 比 *基准版本* 快约 20%。 每个测试的 vmstat 和 iostat 结果有助于解释为什么某个测试更快或更慢，因为它显示了每次请求使用的硬件资源量，包括每次操作的 CPU 开销 (cpu/o) 和上下文切换次数 (cs/o)，后者通常可以作为互斥争用的代理指标。 **结果：写测试** 下表显示了 Postgres 16 到 19 以及 InnoDB 相对于 Postgres 15.17 吞吐量的相对 QPS。第 1 到 4 列是 Postgres 的结果，黄色高亮数字表示 Postgres 中出现性能回退的测试。第 5 列（MySQL 使用 InnoDB）中，黄色和红色数字表示 InnoDB 吞吐量低于 Postgres 的测试。绿色数字表示 InnoDB 吞吐量远高于 Postgres 的测试。 注意：当相对 QPS (rQPS) 为 0.90 时，表示吞吐量下降了约 10%。 总结： - Postgres 的吞吐量在 15.17 版本之后下降。我还不确定这是否是性能回退。 - InnoDB 在 10 个测试中的 6 个测试中吞吐量明显优于 Postgres，在 1 个测试中相近，在 3 个测试中明显更差。 后续部分提供了 update-index、update-zipf 和 insert 测试的更多细节。 相对于：Postgres 15.17 列-1 : Postgres 16.13 列-2 : Postgres 17.9 列-3 : Postgres 18.3 列-4 : Postgres 19 beta1 列-5 : MySQL 8.4.7 列-1 列-2 列-3 列-4 列-5 0.94 0.97 0.98 1.02 1.88 update-inlist 0.94 0.90 0.88 0.92 1.43 update-index 0.91 0.86 0.87 0.92 1.19 update-nonindex 0.96 0.99 0.98 0.98 0.71 update-one 0.92 0.83 0.81 0.85 0.93 update-zipf 0.95 0.93 0.84 0.81 1.71 write-only 0.94 0.94 0.90 0.92 1.14 read-write\_range=10 0.95 0.96 0.95 0.95 1.93 read-write\_range=100 0.89 0.82 0.80 0.84 1.01 delete 1.05 1.05 1.01 1.10 0.53 insert **结果：update-index** 总结： - Postgres 波动过大 - InnoDB 的平均吞吐量比 Postgres 大约高出 1.55 倍 - 每次操作，Postgres 写入存储的写入 IO（写入 KB）比 InnoDB 大约多 1.20 倍 - 每次操作，InnoDB 使用更多 CPU 并产生更多上下文切换。虽然 autovacuum 已启用并且可能在测试期间运行，但我的测量排除了每个测试结束时手动执行的 vacuum。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4AIH6vKcDIjgnw-Y-8WvPaxGwZO3rBf_kDeSjiQBgtEH8XWXhDWd7Ft2gGXPwc_BXVxgXhSTn6AWmFjtJLB83l4Igbd6TUPAH9-8jf2IZ0gPGR0ixMoZdTqR4a9DJnQjrmltwkxKqDc9RWvtTCLO4N-TmU1BTSZhbh5P1GHESDSi6oN1OvV91UnPJdoxk/s600/update-index_%20Postgres%2019b1%20and%20MySQL%208.4.7.png) 按操作率归一化的 iostat、vmstat r/s rMB/s w/s wMB/s r/o rKB/o wKB/o o/s dbms 35503.0 373.7 58795.7 1345.1 1.375 14.824 53.351 25817 PG 19b1 33140.6 517.8 53449.6 1735.3 0.827 13.226 44.326 40090 MySQL 8.4.7 cs/s cpu/s cs/o cpu/o dbms 176167 14.4 6.824 0.000557 PG 19b1 661395 41.9 16.498 0.001046 MySQL 8.4.7 **结果：update-zipf** 总结： - Postgres 波动过大 - InnoDB 的平均吞吐量比 Postgres 大约高出 1.09 倍 - 每次操作，Postgres 写入存储的写入 IO（写入 KB）比 InnoDB 大约多 1.30 倍 - 每次操作，InnoDB 使用更多 CPU 并产生更多上下文切换。虽然 autovacuum 已启用并且可能在测试期间运行，但我的测量排除了每个测试结束时手动执行的 vacuum。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBpMvt9NeKpNXTBkF99Qdgjhy5cA4QFu__1yTl5KMkGpLKxlPUJ-WnNJAHDQI72w1-ySz3b-tmL6j2P5G-ogs0WNl9ZA0hezzA9CyxRSpigd87RoU1rgiCgpm1xjUEpNitGyq6eXGPUrECd2P7nWoQH_l504xfdelFU2bKb3yXJ18WpRLogreQXJCGxc6e/s600/update-zipf_%20Postgres%2019b1%20and%20MySQL%208.4.7.png) 按操作率归一化的 iostat、vmstat r/s rMB/s w/s wMB/s r/o rKB/o wKB/o o/s dbms 55595.5 620.7 64264.4 1352.3 0.622 7.110 15.490 89396 PG 19b1 27405.9 428.2 37465.1 1133.6 0.282 4.508 11.933 97270 MySQL 8.4.7 cs/s cpu/s cs/o cpu/o dbms 424392 27.2 4.747 0.000304 PG 19b1 1213054 44.5 12.471 0.000458 MySQL 8.4.7 **结果：insert** 总结： - Postgres 波动过大 - Postgres 的平均吞吐量比 InnoDB 大约高出 2.06 倍 - 每次操作，Postgres 写入存储的写入 IO（写入 KB）比 InnoDB 大约多 1.67 倍 - 每次操作，Postgres 使用更多 CPU 并产生更多上下文切换。这与上面 update-index 和 update-zipf 的情况相反。 [](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWbY3tiGRuHceEWnN5sIEPuufQGA49wSYP1MmCAb1lGL79Jh0uvRyv2bGaQZo2uDTkWTfLVIONEObrQajeUZ1qxJPYZ6EnjMI9Nkb5XV3x6w_rrgNoqA9qtVDNsW09QcM89pht9VVBklAWeQPmfRt6zZuYU_YoXzo7VOINjy9gh5-b0GjN4WrW5AjaV3W-/s600/insert_%20Postgres%2019b1%20and%20MySQL%208.4.7.png) 按操作率归一化的 iostat、vmstat r/s rMB/s w/s wMB/s r/o rKB/o wKB/o o/s dbms 1615.5 56.0 15321.7 1170.9 0.007 0.242 5.059 237009 PG 19b1 3.6 0.1 8275.4 340.7 0.000 0.000 3.029 115155 MySQL 8.4.7 cs/s cpu/s cs/o cpu/o dbms 1214563 46.0 10.547 0.000399 PG 19b1 800827 50.5 3.379 0.000213 MySQL 8.4.7