PostgreSQL v15 - 十亿次交易之后

作为最后一个 Postgres 版本，编号为 15，对我来说似乎是一个“周年纪念”版本，我认为运行一系列测试以尝试衡量过去 5 年的改进规模会很有趣/有用，即将 v10 和 v15 放入环中。以公平且有意义的方式完成这当然是一项非常艰巨的任务（请参阅我最后一次尝试混合结果），因为两者之间发生了很多变化，并且有太多用例而且没有足够的时间。但一如既往 - 启动“pgbench”非常容易，让它搅动一会儿然后尝试分析数字 - 是否发生了某些变化，可能是什么原因？好玩的东西！

通常我的此类测试会持续几个小时左右……但是这一次，为了表达适当的“周年纪念”敬意，并且鉴于实际上很少有长期的 Postgres perf 测试件，我想到底是什么 - 让我们做一轮 1B pgbench 交易！并首先查看它需要多长时间，之后各个 Postgres 版本的表和索引处于什么状态，以及是否存在明显的性能下降！

TLDR; - 与查询运行时方面没有太大区别

测试设置

硬件：2 个本地（在我的办公桌下）旧工作站、4 个 CPU（Intel i5 和 Xeon E3 均为 3.30GHz，无超线程）、16GB RAM、SATA SSD

操作系统：Ubuntu 20.04 服务器

Postgres ：来自官方PGDG回购的最新 v10 和 v15（10.22、15.0）

工作集大小：pgbench 规模 5000 ~ 73 GB DB 大小，即 5x RAM 的活动集

测量方法：Postgres 内置“pg_stat_statements”扩展统计聚合和自定义 SQL

并行度：这次决定进行全负载测试，客户端数量为 8（2 个 CPU），充分利用了系统（几个 % 空闲，~40% iowait on avg）

Pgbench 测试模式： --skip -some-updates例如，删除遭受锁争用的小表的更新 + pgbench_accounts （bid，abalance）上的 1 个额外索引。使用了准备好的语句模式。

测试持续时间：1B TX，即每个 pgbench 客户端 125M

Postgres 配置：Pgtune OLTP + 一些自定义更改：

# max_parallel_maintenance_workers = 2 # Not supported on v10
unix_socket_directories='/tmp' # To run under any OS user conveniently
shared_preload_libraries='pg_stat_statements'
wal_compression=on # Should be enabled on all instances basically
track_io_timing=on # To get IO call duration in pg_stat_statements
synchronous_commit=off # Don't want to test disk COMMIT throughput

完整的测试脚本可以在这里找到（https://github.com/kmoppel/pg-perf-test-v10-v15/tree/1b-tx-test-skip-some-updates-with-extra-index）

结果

因此，大约 11 天后，我的收件箱中收到了较慢机器的 ping，检查了日志中的错误……事不宜迟，这里是从 pg_stat_statements 中提取的内容和测试后执行的一些临时 SQL（从运行的平均值两个不同的服务器）。

来自 pg_stat_statements 的详细 SQL 执行统计信息

请注意，更快的 INSERT 和 SELECT 查询在微秒范围内，因此事情已经接近计时/测量错误级别，我们基本上也可以忽略这些。

PS可以在此处（https://github.com/kmoppel/pg-perf-test-v10-v15/blob/1b-tx-test-skip-some-updates-with-extra-index/pgss_results_dump.sql）找到我运行的pg_stat_statements数据的完整转储

主要经验

我希望以上数字能够说明在十亿个简单的 OLTP 事务之后您的数据库会发生什么。从学习的角度来看，我想我们只能肯定地说几件事：

• Postgres 设法在我的低端测试硬件上以相当快的速度（~10 天）咀嚼 1B TX（这实际上代表了一个普通的 Postgres 云实例，很好地查看了我当前公司的库存），因此我怀疑事务环绕（2B 计数器）仍然是一个话题对于高变动的 Postgres 实例和 DBA 应该注意。
• 低行数索引 OLTP 访问的执行时间在最近几年/版本中基本没有变化——与我在之前的测试中发现的相似。对于那些不能轻易升级的人来说，这可能是个好消息——你不必费力，Postgres 在 5 年前就已经在那个领域非常好，并且支持你！
• 硬件（磁盘）很重要——尽管测试盒的规格非常相似（故意），但一个盒子确实有一个较旧的较慢的 SSD（后来在谷歌搜索后出现），总测试运行时间是由于它长了三分之一。
• v15 在磁盘消耗方面肯定更好 - 在如此短的时间内相对较大的 46% 减少绝对是我在本次测试中最大的惊喜。因此，如果您的存储速度较慢并且工作集内存严重不足，那么一定要尽快升级。
  • 顺便说一句，磁盘减少来自最近的索引改进，例如重复数据删除和自下而上的删除，因为膨胀级别或多或少相同。
• v15 有更多的随机性（“pg_stat_statements.stddev_exec_time”）在起作用——这可能是由于更激进的后台 Autovacuum 设置，也可能是由于更复杂的索引处理算法？虽然有点奇怪，因为一般的缓存命中率得到了提高——但这实际上也与我之前测试的一般发现相匹配，所以一定有什么东西在那里。
• 还有一个关键的谜团——如果不存储其中一些并运行“pg_waldump”，v15 相当大的 WAL“消耗”有点难以解释，但很可能是由于更激进的 autovacuum / freeze 默认配置为“wal_level” ”在默认情况下是两者的“副本”。我希望🤔

最后，像往常一样，某种免责声明 - 请记住，考虑到典型应用程序的生命周期，~10 天仍然是一个非常短的时间范围，这是一个非常简单的 OLTP 测试，只有 3 个语句 - 在现实世界中在某些情况下，会有许多其他查询、一些“恼人的”Cronjobs 或备份作业会弄乱您的缓存等，因此一如既往 - 对于关键的增长倾向的应用程序，应该运行针对特定模式和使用模式调整的负载测试。

此外，如果您打算运行自己的pgbench，但跳过了上面的测试设置部分——请注意，除了标准的 pgbench模式之外，我还向pgbench_accounts表添加了一个索引，以启用假设的快速“分支 Y 的前 X 个帐户”查询（试图向他们出售加密投资产品），因为默认的唯一索引对于 OLTP 来说是一个非常不切实际的用例，可以满足太多的热更新。

下次运行的注意事项 - 更多监控

希望我能更好地跟踪 TPS（每秒事务数），看看它是如何或是否随时间变化的——目前只需要对大约 1.3K 的平均值感到满意。还有一些关于“relfrozenxid”年龄运动和背景写作（pg_stat_bgwriter）统计的东西。

原文标题：Postgres v15 - a billion transactions later

原文作者：kmoppel

原文链接：https://kmoppel.github.io/2022-11-09-postgres-v15-a-billion-transactions-later/