PostgreSQL基准测试中如何最小化IO并提升CPU利用率？

一、UNLOGGED表并非完全无WAL写入 #

UNLOGGED表仅跳过业务数据修改的WAL记录，以下场景仍会生成WAL：

• 事务元数据记录：所有事务的启动、提交/回滚状态必须写入WAL，用于维护集群的事务一致性（即使UNLOGGED表崩溃后会被截断，事务生命周期的管理仍依赖基础WAL）。
• 系统表修改：TPCC的写入操作会间接更新系统目录（如pg_class、pg_statistic），这些属于普通日志表，所有变更都会生成WAL。此外，事务ID分配、事务状态文件（pg_xact目录）的更新也会产生磁盘IO，这是inotifywait观测到大量文件修改的核心原因。
• WAL切换操作：WAL文件默认大小为16MB，写满后会自动创建新文件，即使fsync=off，文件创建与元数据更新仍会触发磁盘操作。

二、磁盘IO的其他隐性来源 #

除WAL外，这些操作也会导致磁盘活动：

• 事务状态文件（pg_xact）：高并发下，每个事务的提交/回滚状态会频繁写入pg_xact下的文件，这是持续IO的重要来源。
• 统计文件更新：即使关闭track_activities，pg_stat_database等基础统计仍会定期刷新到磁盘，高负载下这类写入会被放大。
• WAL缓冲区刷写：若wal_buffers设置过小，当缓冲区满时会触发异步刷写，产生零星IO。

三、CPU利用率受限的核心原因 #

CPU利用率上不去是因为PostgreSQL进程在等待磁盘IO完成时进入睡眠状态，高并发场景下，少量IO等待会导致大量进程阻塞，进而拉低整体CPU使用率。

四、优化与排查步骤 #

1. 定位WAL内容：用pg_waldump分析生成的WAL文件，明确写入来源：

   pg_waldump ${PGDATA}/pg_wal/000000010000000000000001
   

   通过输出中的记录类型（如XLOG、Heap2、Catalog）可区分是事务元数据、系统表修改还是其他操作。

2. 消除事务状态文件IO：将pg_xact挂载到RAM磁盘（tmpfs），该目录内容在集群重启后会自动重建，适合放在内存中：

   mount -t tmpfs tmpfs ${PGDATA}/pg_xact
   

3. 彻底关闭统计收集：在postgresql.conf中添加以下配置，消除所有统计相关的磁盘写入：

   track_activities = off
   track_counts = off
   track_io_timing = off
   track_functions = none
   

4. 优化WAL缓冲区：最大化WAL缓冲区，减少刷写次数：

   wal_buffers = 16MB
   

5. 避免触发自动检查点：设置足够大的max_wal_size，防止因WAL量累积触发检查点（即使checkpoint_timeout=1d，默认max_wal_size=1GB仍可能触发）：

   max_wal_size = 10GB
   

6. 排查系统表写入：查询系统表的写入频次，确认是否有异常修改：

   SELECT relname, n_tup_ins, n_tup_upd, n_tup_del 
   FROM pg_stat_all_tables 
   WHERE relnamespace = 'pg_catalog'::regnamespace;
   

内容的提问来源于stack exchange，提问作者eagle4231