PostgreSQL执行FULL VACUUM时出现内存不足错误，请求排查解决

问题根源分析 #

从报错信息看，内存不足发生在并行worker的"Caller tuples"内存上下文，结合你的配置细节：

• 系统空闲内存23GB，但shared_buffers占了16GB，留给其他进程的剩余内存空间紧张
• maintenance_work_mem=2400MB是每个维护进程（含并行worker）的内存上限，并行VACUUM FULL启动多个worker时，内存占用会叠加，超出系统剩余承载能力
• 大表的元组缓存（"Caller tuples"）在并行处理场景下，内存消耗会远超单进程模式的预期

具体解决方案 #

1. 临时禁用并行VACUUM #

关闭当前会话的并行清理功能，避免多worker内存叠加：

SET max_parallel_maintenance_workers = 0;
VACUUM FULL VERBOSE ANALYZE client.patient118;

执行完成后可根据系统核心数恢复原配置（例如SET max_parallel_maintenance_workers = 4;）。

2. 针对性调整维护内存参数 #

不要全局设置过大的maintenance_work_mem，而是针对当前会话临时调优，同时配合禁用并行：

SET maintenance_work_mem = '8GB'; -- 按系统剩余空闲内存调整，建议预留3-5GB给系统进程
SET max_parallel_maintenance_workers = 0;
VACUUM FULL VERBOSE ANALYZE client.patient118;

注意：会话级maintenance_work_mem不要超过系统剩余空闲内存的70%，避免挤占其他业务进程资源。

3. 优化共享缓冲区配置（可选） #

当前shared_buffers=16GB占系统内存比例过高（常规建议为系统内存的25%-40%），可临时调整释放内存：

ALTER SYSTEM SET shared_buffers = '6GB';
SELECT pg_reload_conf();

完成维护后可再恢复原shared_buffers配置。

4. 替代方案：分阶段处理（若非必须FULL VACUUM） #

如果不需要立即重写整个表，可先执行普通VACUUM清理死元组，再单独执行ANALYZE更新统计信息：

VACUUM VERBOSE client.patient118;
ANALYZE VERBOSE client.patient118;

普通VACUUM内存消耗低，不会重写表，适合紧急缓解空间膨胀问题。

后续预防措施 #

• 定期监控大表膨胀率，提前清理，避免等到必须执行FULL VACUUM才处理
• 全局maintenance_work_mem设置不超过系统内存的10%，针对大表维护再临时调大
• 根据系统核心数合理设置max_parallel_maintenance_workers（建议不超过核心数的1/4）

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