Postgres 13 实例关闭缓慢排查及复现、WAL积累需求

1. 除日志外，如何排查关闭耗时过长的原因？ #

• 检查进程状态：执行ps aux | grep postgres，观察是否有处于**D状态（不可中断睡眠）**的进程，这类进程通常在等待IO或系统资源，是停滞的常见原因。
• 监控系统资源：用top、iostat、vmstat实时跟踪CPU、磁盘IO、内存使用率，确认关闭期间是否存在磁盘IO饱和、内存不足等资源瓶颈。
• 核查锁与事务：若关闭初期仍能连接实例，执行以下SQL查看异常：
  • SELECT * FROM pg_locks WHERE NOT granted;：排查未授予的锁请求
  • SELECT * FROM pg_stat_activity WHERE state != 'idle';：查看未完成的活跃事务、长查询
• 分析共享内存：用ipcs -m查看PostgreSQL共享内存段状态，确认是否有未正常释放的内存段或异常占用。
• 跟踪系统调用：对停滞的PostgreSQL进程执行strace -p <进程ID>（核心服务器需谨慎操作，避免影响业务），查看进程卡在哪个系统调用（如文件IO、网络操作）。
• 检查归档状态：启用归档的情况下，执行SELECT * FROM pg_stat_archiver;查看归档是否有堆积、失败记录，关闭流程可能会等待归档完成。

2. 有哪些复现该问题的建议？ #

• 还原真实业务负载：不要仅用pgbench简单场景，模拟生产环境的核心操作，比如大量长事务、并发批量写入、分区表维护、大表索引操作、物化视图刷新等，同时模拟客户端持续发起连接的场景。
• 模拟归档异常：在测试环境故意中断归档进程，或配置归档命令为阻塞脚本（如让脚本等待人工输入），触发关闭后观察是否出现停滞。
• 制造资源瓶颈：用dd持续写磁盘制造IO瓶颈，或用stress工具模拟CPU高负载，再执行关闭操作，验证是否因资源不足导致缓慢。
• 提升并发连接数：模拟数百个并发连接，部分连接保持长事务未提交，再触发关闭，测试高连接下的关闭逻辑。
• 模拟WAL堆积：先积累大量未归档的WAL文件，再执行关闭，排查是否因等待WAL处理导致停滞。

3. 如何在测试服务器积累大量WAL文件？ #

• 调整WAL段大小：重新初始化测试集群时指定--wal-segment-size=64MB（默认16MB），单个WAL文件更大，积累速度更快。
• 关闭归档功能：临时设置archive_mode = off，WAL文件不会被归档，会持续保留在pg_wal目录。
• 禁用自动Checkpoint：设置checkpoint_timeout = 0（测试后需改回），或调大checkpoint_timeout至最大值（1天），同时将max_wal_size设为较大值（如100GB），避免Checkpoint频繁触发清理WAL。
• 高并发写入压测：用pgbench生成大负载，比如先执行pgbench -i -s 100初始化100倍规模的测试库，再运行pgbench -c 50 -j 4 -T 3600 -P 60 -n -M prepared执行1小时的高并发写入测试。
• 大表批量操作：创建大表（如100GB），执行全表更新、批量插入等操作，这类操作会生成大量WAL日志。
• 关闭WAL压缩：临时设置wal_compression = off，避免WAL文件被压缩，增加磁盘占用量。

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