文章目录每日一句正能量1. 背景与问题2. 环境与数据3. 复现过程4. 方案实施5. 结果对比6. 风险与复盘每日一句正能量“你路过我我路过你各自修行各自向前。”哪怕心灵相遇人生的轨迹依然独立。我们彼此照亮然后各自奔赴前程。1. 背景与问题在高并发交易系统中数据库偶发出现TPS下降、事务响应时间突增以及磁盘写入峰值异常。业务SQL执行耗时稳定但每隔几分钟出现一次明显抖动。结合 PostgreSQL 日志与pg_stat_bgwriter分析发现Checkpoint触发频率过高导致大量脏页集中刷盘引发磁盘IO拥塞最终影响事务提交。Checkpoint本身属于数据库正常机制但配置不合理会形成写放大和IO尖峰因此需要结合业务写入特征进行参数调优。2. 环境与数据PostgreSQL 16Linux 5.x32核CPU / 128GB内存NVMe SSDpgbench模拟交易写入典型SQLUPDATEaccountSETbalancebalance-100WHEREid$1;优化前参数checkpoint_timeout 5min max_wal_size 4GB checkpoint_completion_target 0.5执行计划Update on account Index Scan using pk_account Buffers: shared hit15 dirtied4 Execution Time: 0.55 msSQL执行效率正常瓶颈并非执行计划。监控数据优化前指标数值Checkpoint次数/小时12TPS28500P99延迟42ms磁盘写峰值690MB/sCheckpoint耗时92s3. 复现过程pgbench 128并发持续写入。使用pg_stat_bgwriter查看Checkpoint统计。使用iostat -x 1观察磁盘写入。Grafana监控TPS、延迟及IO。发现每次Checkpoint开始时磁盘利用率接近100%TPS瞬时下降约20%。4. 方案实施调整配置checkpoint_timeout 15min max_wal_size 16GB checkpoint_completion_target 0.9 wal_compression on结合以下监控持续验证pg_stat_bgwriterpg_stat_waliostatvmstat优化后执行计划保持一致Update on account Index Scan using pk_account Buffers: shared hit15 dirtied4 Execution Time: 0.53 ms5. 结果对比指标优化前优化后Checkpoint次数/小时124TPS2850033800P99延迟42ms24ms磁盘写峰值690MB/s410MB/sCheckpoint耗时92s54s调整后Checkpoint写入更加均匀磁盘写入曲线趋于平滑事务提交延迟显著下降系统高峰期间未再出现明显抖动。6. 风险与复盘风险max_wal_size过大将增加故障恢复时间。checkpoint_timeout过长会积累更多脏页需要保证存储性能充足。不建议仅追求减少Checkpoint次数应综合恢复时间目标RTO评估。复盘建议优先排除SQL和索引问题再分析Checkpoint。联合分析pg_stat_bgwriter、pg_stat_wal、IO监控数据。每次调参均通过压测验证TPS、P95/P99延迟和磁盘写入曲线。建议建立Checkpoint监控告警避免参数变更后长期未发现异常。本文结合执行计划、监控数据、参数前后对比以及压测结果展示了交易系统中Checkpoint过频导致抖动的定位与优化思路可作为生产环境性能调优参考。转载自https://blog.csdn.net/u014727709/article/details/164031586欢迎 点赞✍评论⭐收藏欢迎指正
