通过禁用参数可以来调整事务工作负载synchronous_commit。该措施有惊人效果。但在操作系统崩溃期间丢失已提交事务的可能性使其成为许多应用程序无法启动的因素。因此我决定写下来。

WAL 刷新是事务数据库工作负载的瓶颈

为了确保已提交的事务不会丢失，PostgreSQL 必须确保事务的WAL已刷新到磁盘，然后才能向客户端报告成功。如果数据库工作负载主要由小数据修改组成，则这些事务产生的IOPS可能会使磁盘饱和，即使写入的数据量适中。

参数对commit_delay可以commit_siblings通过减少这些 WAL 刷新所需的 IOPS 数量来缓解瓶颈。

commit_delay和如何commit_siblings工作？

您可以通过将其设置为大于零的值来激活该功能commit_delay。每当事务在提交期间达到将 WAL 刷新到磁盘的点时，它首先检查当前有多少其他事务处于活动状态。如果至少有其他commit_siblings事务处于打开状态并且没有等待锁定，PostgreSQL 不会立即刷新 WAL，而是等待commit_delay几微秒。经过该延迟后，其他一些事务可能已达到准备刷新 WAL 的点。然后，所有这些后端都可以在单个 I/O 操作中执行其 WAL 刷新。

commit_delay调整起来并不容易，因为延迟会使事务耗时更长。另一方面，如果选择的值太低，则在延迟过去时可能没有其他事务准备就绪，并且您无法减少执行的 IOPS 数量。

commit_delay基准设置

基准测试在我的 ASUS ZenBook UX433F 笔记本上运行，该笔记本具有本地 NVME 磁盘、8 个 CPU 核心和 16GB RAM。我设置了shared_buffers = 3GB、max_wal_size = 100GB和。然后我使用比例因子 100checkpoint_timeout = 15min初始化标准数据库。我使用pg_prewarm将所有表和索引加载到共享缓冲区中。这样，就永远不会有读取 I/O，并且除了检查点之外，唯一的 I/O 将是 WAL 写入。

pgbench我使用的命令是

pgbench -b simple-update -c 10 -T 1200

限制磁盘

我的笔记本电脑内置的 NVME 非常强大，我无法用 来满足它的需求pgbench。因此，我决定使用Linux 控制组将设备限制为 1000 IOPS。在我的 Fedora 40 系统上，我必须为 systemd 切片启用 I/O 控制：

echo '+memory +pids +io' > /sys/fs/cgroup/system.slice/cgroup.subtree_control

然后，我可以为 PostgreSQL v17 服务的写入设置 NVME 上的 IOPS 限制：

echo '259:0 wiops=1000' > /sys/fs/cgroup/system.slice/postgresql-17.service/io.max

您可能会说，这让我的测试显得很虚假。但是，将数据库托管在公共云中的人会受到类似这样的限制。而且，无论如何，您永远无法将基准测试的结果直接应用于不同的系统和工作负载。

commit_delay基准测试结果

我们在 1000 μs 的设置下实现了最佳性能commit_delay。使用此设置时，pgbench每秒执行的交易数比不使用时少两倍commit_delay。值得注意的是，在最佳状态下，磁盘远未饱和，因此可能实现更好的结果。

结论

虽然commit_delay不能以同样的方式提高事务工作负载的性能synchronous_commit = off，但我们仍然能够实现显着的性能改进。如果您无法承受操作系统崩溃后丢失事务的后果，那么调优commit_delay是加快由短事务组成的工作负载的最佳方法。
#PG证书#PG考试#PostgreSQL培训#PostgreSQL考试#PostgreSQL认证