PostgreSQL备库流复制模式内存占用过高求助

核心误区澄清：共享内存统计问题 #

首先要明确：top输出中的RES（常驻内存）包含共享内存段，PostgreSQL的所有后台进程都会映射shared_buffers这个共享内存区域，因此多个进程的RES数值会重复统计这部分内存，并非每个进程独立占用4.1G内存。

验证方法：

• 执行pmap -x 6106查看进程内存明细，其中anon部分是私有内存，shared部分是共享内存（包含shared_buffers）。
• 用ipcs -m查看系统共享内存段，确认shared_buffers对应的内存段大小是否为4GB，这部分是所有PostgreSQL进程共享的。

从你的top输出看：

• 6106（checkpointer）的RES和SHR均为4.1G，说明私有内存几乎为0；
• 6104（background writer）的SHR4.0G，RES4.1G，私有内存仅约100M，属于正常范围；
• 6105（startup）的内存占用明显低于前两者，符合恢复进程的常规表现。

针对性排查步骤 #

1. 确认备库流复制恢复状态 #

Startup进程是备库的WAL恢复进程，若备库长时间处于追主状态（比如主库有大量未归档WAL、网络延迟高），可能会临时占用更多内存用于WAL解析或缓存：

• 查看备库恢复日志（pg_log目录下的日志文件），检查是否有WAL恢复相关的警告或错误；
• 检查主库wal_keep_size或max_wal_size设置，若备库无法及时获取WAL，可能导致startup进程缓存更多WAL数据；
• 执行SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();查看备库追主延迟，若延迟过大，需排查主备网络、WAL归档机制。

2. 检查PostgreSQL内存参数配置 #

虽然shared_buffers设置为4GB（占总内存25%，符合最佳实践），但需确认其他内存参数是否合理：

• wal_buffers：默认是shared_buffers的1/32（约128MB），若备库恢复时WAL写入频繁，该参数不足可能导致内存波动；
• maintenance_work_mem：备库在恢复时若涉及索引重建等维护操作，会使用该参数指定的内存，若设置过大可能占用较多内存；
• 备库是否允许只读查询？若有业务查询，需检查work_mem设置，多个并发查询会累加占用该内存。

3. 排查进程私有内存异常 #

若某个进程的RES - SHR（私有内存）持续增长，需怀疑内存泄漏：

• 定期执行pmap -x <pid>跟踪私有内存变化；
• 查看PostgreSQL官方版本发布说明，确认当前版本是否存在已知的后台进程内存泄漏bug，若有则升级到最新稳定小版本；
• 检查备库是否加载了第三方扩展，部分扩展可能在恢复过程中引发内存问题。

4. 系统层面内存排查 #

• 执行free -h查看系统总内存占用，确认是否有其他进程（如操作系统服务、监控工具）占用大量内存；
• 检查oom-killer日志（/var/log/messages或dmesg），确认是否发生过内存不足导致的进程被杀事件。

总结 #

从当前top输出看，三个后台进程的高内存占用主要是共享内存的重复统计，属于正常现象。若系统总内存确实紧张，可按上述步骤排查备库恢复状态、参数配置及潜在的内存泄漏问题。

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