缩减虚拟内存致PostgreSQL 9.6不可用的原因及解决方案咨询

1. 故障根本原因 #

• Windows Server 2008的页面文件（虚拟内存）是系统和进程的内存兜底机制，当物理内存耗尽时，系统会将内存数据交换到这里。PostgreSQL在夜间会自动触发autovacuum、统计信息收集、批量数据处理或备份等任务，这些场景会临时占用大量内存资源。
• 你的服务器物理内存为12GB，手动将虚拟内存缩减至4GB后，系统总可用内存（物理+虚拟）仅16GB，远低于之前自动模式下的40GB（12+28）。夜间高负载时，物理内存先被占满，虚拟内存又不足以支撑额外的进程创建和内存交换操作，直接引发连锁问题：
  • 统计信息收集进程因内存不足无法正常响应，出现using stale statistics instead of current ones报错；
  • 系统无法分配足够内存创建autovacuum工作进程，触发CreateProcess调用失败；
  • 系统层面内存耗尽，最终导致数据库服务不可用。
• 重启服务器只是临时释放了内存，但次日夜间维护任务再次触发，内存需求超过总容量上限，问题必然重复出现。调增至32GB虚拟内存后，总可用内存达到44GB，满足了峰值负载的内存需求，故障自然消失。

2. 安全缩减虚拟内存的操作方案 #

要安全缩减虚拟内存，核心是确保物理+虚拟内存的总容量能覆盖数据库和系统的峰值内存需求，具体步骤如下：

第一步：摸清真实内存需求 #

• 用Windows性能监视器（PerfMon）或任务管理器，连续监控3-7天的夜间时段，记录以下数据：
  • PostgreSQL主进程+所有子进程（autovacuum、查询进程等）的内存占用峰值；
  • 系统其他服务的内存占用情况；
  • 页面文件的实际使用峰值。
• 同时开启PostgreSQL的详细日志，记录夜间维护任务的内存消耗情况，确定系统所需的最小总内存阈值。

第二步：优化PostgreSQL内存参数，减少不必要的内存占用 #

• 调整shared_buffers：Windows环境下建议不超过物理内存的50%，12GB物理内存的话，设置为4-6GB即可，避免占用过多物理内存给系统留足余量；
• 限制work_mem和maintenance_work_mem：work_mem是单个排序/哈希操作的内存，别设太高（比如64MB），避免并发场景下内存暴涨；maintenance_work_mem给维护任务使用，建议设为1GB以内，同时单独配置autovacuum_work_mem限制autovacuum的内存占用；
• 调低max_connections：关闭不必要的并发连接，减少整体内存消耗。

第三步：逐步缩减虚拟内存，边调边验证 #

• 不要一次性大幅缩减，比如从32GB先降到20GB，观察1-2天的夜间负载情况，确认没有内存不足报错、数据库服务运行正常；
• 若状态稳定，再逐步下调（每次降2-4GB），直到找到刚好能覆盖峰值需求的最小值（建议至少保留物理内存的1.5倍，即18GB以上，除非你明确验证峰值需求更低）；
• 每次调整后重启服务器，确保设置生效，持续监控1-2周确认无问题。

第四步：优化任务调度，降低内存峰值 #

• 把autovacuum、备份、统计信息收集等夜间任务错开执行，避免同时运行导致内存占用叠加；
• 清理数据库中的无效数据、死元组，减少autovacuum的工作量和内存消耗；
• 关闭服务器上无用的服务，释放物理内存空间。

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