Windows页面文件的真实作用—

pagefile.sys 到底在做什么

程序申请内存时,Windows 会给出一个“提交”承诺,而每个承诺背后的担保就是 RAM 加页面文件——两者共同决定提交上限。物理 RAM 存放热点数据;内存吃紧时,内存管理器会把最少使用的页面写入 pagefile.sys,让 RAM 继续服务要紧的部分。这个文件的很大一部分职责就是“作为担保而存在”:这就是为什么一台“RAM 大把空闲”的电脑,恰恰在禁用页面文件的那一刻开始疯狂报内存不足。

崩溃分析同样离不开它:蓝屏之后,内存转储会在下次启动时写进这个文件。休眠用的是另一个文件——hiberfil.sys——与页面调度毫无关系。而从 Windows 10 开始,内存压缩会在任何数据落盘之前先把冷页面压进 RAM,这减少了页面调度流量,却并没有让这个文件变得可有可无。

容量:经得起检验的规则

对 95% 的电脑来说,正确答案就是默认值:让系统自行管理。如果你确实有测算过的理由要手动设置,下面这些才是经得起现实检验的规则。唯一重要的输入是你自己的提交内存峰值,而任务管理器免费就能告诉你。

没有测算依据就保持系统托管——Windows 会根据真实使用量和崩溃转储需求来决定文件大小
动手填数字之前,先在任务管理器 > 性能 > 内存 > 已提交里观察几天高负载使用;你的提交峰值才是唯一诚实的输入
要手动设置,就把最小值和最大值设成同一个数,文件就不会反复增长、收缩和碎片化
即使把大头挪到别处,C: 盘上也要保留一个小页面文件,否则崩溃转储会直接失效
第二块物理盘是个好去处;同一块机械硬盘上的另一个分区只会让页面调度更慢,而不是更快
老掉牙的 1.5×RAM 规则是上世纪 90 年代的传说——64 GB 内存的办公机不需要 96 GB 的页面文件

不肯消亡的迷思

“禁用它,Windows 就只能乖乖用 RAM 了”——错。RAM 的使用从来不受页面文件限制;去掉它之后,那些申请的提交量超过 RAM 单独所能担保的程序,会干脆启动失败,或在运行中途崩溃。你还会失去崩溃转储,下次蓝屏就什么都无从分析。

“别放在 SSD 上,不然盘会坏”同样过时:页面文件的写入量比起浏览器缓存不过是零头——具体数字我们在页面文件对 SSD 磨损的文章里详细拆过。最后一个僵尸是 ClearPageFileAtShutdown,也就是老掉牙的“关机时清空页面文件”优化:它把每次关机拖长好几分钟,去保护全盘加密早已覆盖的数据。