【PGCCC】commit_delay 对性能的提升：PostgreSQL 基准测试

通过禁用参数可以来调整事务工作负载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。我设置了sh