答案：PostgreSQL内存溢出多因配置不当或SQL问题，合理设置shared_buffers、work_mem等参数，避免高并发下内存超限；通过pg_stat_activity和temp_files检查长查询与临时文件，排除未提交事务；结合top、pg_top监控进程内存与SQL消耗，确认是否真泄漏，升级版本并排查扩展问题。
PostgreSQL 出现内存溢出或疑似内存泄漏，通常不是数据库本身存在严重 Bug，而是配置不当、查询设计不合理或外部连接使用不当导致的资源过度消耗。要避免和排查这类问题，需从配置优化、SQL 审查和系统监控三方面入手。
合理配置内存相关参数
PostgreSQL 提供多个内存控制参数，正确设置能有效防止内存过度使用：
- shared_buffers：用于缓存数据页，建议设置为物理内存的 25%~30%，但不要超过 8GB~32GB（视硬件而定），过大会影响操作系统缓存效率。
- work_mem：每个排序或哈希操作可用的内存。若并发高且 SQL 频繁排序，设得过高会导致总内存超标。建议在 4MB~64MB 之间，复杂分析可临时调大，但需监控。
- maintenance_work_mem：用于 VACUUM、CREATE INDEX 等维护操作，可设高些（如 1GB），但不应长期占用。
- max_connections：连接数越多，内存开销越大（每个连接至少占用几百 KB 到几 MB）。应结合连接池（如 PgBouncer）限制实际后端进程数量。
- temp_buffers：会话级临时表使用的内存，一般无需调大。
这些参数总和不应超过物理内存的 70%，留出空间给操作系统和其他进程。
排查异常 SQL 和长事务
内存“泄漏”现象常由某些 SQL 或事务长期占用资源引起：
- 检查是否有长时间运行的查询：
SELECT pid, query, now() - query_start AS duration FROM pg_stat_activity WHERE state = 'active' AND now() - query_start > interval '5 minutes'; - 查看是否使用了大量临时文件（说明 work_mem 不足，频繁落盘）：
检查日志中temporary file: path "...", size ...记录，或通过pg_stat_database查看temp_files增长情况。 - 避免大结果集的全表扫描或未加 LIMIT 的查询，尤其是应用层一次性拉取全部数据。
- 监控是否有未提交的事务（idle in transaction），它们会阻止 vacuum 清理死元组，间接导致膨胀和内存压力。
监控内存使用与系统状态
仅靠 PostgreSQL 内部视图不够，还需结合系统工具观察真实内存占用：
- 使用 top 或 htop 查看 postmaster 及子进程的 RSS（常驻内存）是否持续增长。
- 使用 pg_top 或 pg_stat_statements 扩展识别高内存消耗的 SQL。
- 启用 log_temp_files 和 log_statement（谨慎开启）帮助定位问题语句。
- 定期检查 pg_locks、pg_stat_replication 等视图，排除复制或锁等待导致的堆积。
确认是否为真正的内存泄漏
PostgreSQL 极少出现真正的内存泄漏，但如果发现以下情况需深入排查：
- 数据库重启后内存正常，运行几天后 RSS 持续上升且不释放。
- 即使没有活跃查询，内存仍不断增长。
- 使用的是较旧版本（如 9.6 以前），建议升级到稳定新版（如 14+），修复已知问题。
- 检查是否使用了不稳定的扩展（如某些 C 编写的插件），它们可能未正确释放内存。
可通过 Valgrind 或 AddressSanitizer 在测试环境运行简单负载进行内存分析，但生产环境慎用。
基本上就这些。多数“内存溢出”问题源于配置不合理或 SQL 不当，而不是 PostgreSQL 自身泄漏。优化参数、控制连接、审查查询，配合监控，就能有效避免和定位问题。
