PostgreSQL 15检查点评估及频繁触发的性能优化咨询

1. 检查点频率的判断 #

是的，你的计算结果说明平均每约0.08分钟（即4.8秒）触发一次检查点，这确实过于频繁——远高于你设置的5分钟定时检查点间隔。这种情况几乎可以肯定是**请求式检查点（checkpoints_req）**在频繁触发，而非定时检查点（checkpoints_timed）。

你可以通过以下SQL确认两种检查点的占比：

SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter;

如果checkpoints_req的数值远大于checkpoints_timed，就验证了这一点。

2. 频繁检查点的核心原因 #

你的服务器有32G内存，但仍使用PG默认参数，这是问题的关键：

• shared_buffers过小：默认128M对于32G内存的服务器来说完全不够。PG依赖shared_buffers缓存数据，缓存不足时会频繁刷写脏页到磁盘，进而触发请求式检查点。
• max_wal_size默认值偏低：默认1GB的WAL日志上限，若业务写量较大，很快就会达到这个阈值，强制触发检查点来回收WAL空间。

3. 性能优化步骤 #

（1）调整shared_buffers（核心优化） #

PG推荐将shared_buffers设置为服务器内存的1/4~1/3，对于32G内存的服务器，建议设置为8GB：
修改postgresql.conf：

shared_buffers = 8GB

修改后需要重启PostgreSQL生效。

（2）调大max_wal_size #

根据业务写量调整，建议设置为16GB（可根据实际情况增减）：

ALTER SYSTEM SET max_wal_size = '16GB';
SELECT pg_reload_conf();

该修改无需重启，执行后立即生效。

（3）优化检查点平滑度 #

保持或调整checkpoint_completion_target为0.9，让检查点在更长时间内完成，避免IO突增：

ALTER SYSTEM SET checkpoint_completion_target = 0.9;
SELECT pg_reload_conf();

（4）验证优化效果 #

调整参数后，等待一段时间（比如1小时），重新运行你原来的查询，或者用以下SQL监控检查点频率：

SELECT
  checkpoints_timed,
  checkpoints_req,
  round(EXTRACT(EPOCH FROM (now() - pg_postmaster_start_time())) / (checkpoints_timed + checkpoints_req) / 60, 2) AS avg_minutes_between_checkpoints
FROM pg_stat_bgwriter;

理想情况下，平均间隔会接近你设置的5分钟定时间隔，请求式检查点的数量会大幅减少。

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