在开发机上遇到“内存不足”“Out of Memory”、Docker容器被强杀、Chrome标签页崩溃，很多情况下并非物理内存真的耗尽，而是Windows的提交内存（Committed Memory）用到了上限。提交内存由物理内存与页面文件（pagefile.sys）共同组成，页面文件就是虚拟内存的磁盘载体。增大页面文件能抬高提交限制，从而减少OOM的发生；但若配置不当，也可能拖慢系统。这篇文章从虚拟内存原理、OOM诊断到页面文件设置和容量规划，完整梳理Windows虚拟内存的实践方法。
虚拟内存的基本逻辑
Windows基于请求分页管理每个进程的虚拟地址空间。进程申请内存时，系统先在虚拟地址空间预留区域，再按需提交，提交总量受“提交限制”约束。提交限制等于物理内存总量加所有页面文件之和。当所有进程的已提交内存接近这个限制时，任何新的分配都可能失败，并返回 STATUS_NO_MEMORY 或 ERROR_NOT_ENOUGH_MEMORY，也就是用户见到的“内存不足”或“System.OutOfMemoryException”。物理内存不足时，内存管理器会把不活跃的页写到页面文件，也就是硬缺页交换。注意，页面文件的性能远低于物理内存，NVMe SSD 的随机访问延迟在几十微秒，内存则在百纳秒量级，频繁硬缺页会带来明显卡顿。因此，虚拟内存是兜底手段，不是扩展物理内存的替代方案。
OOM出现时先做确认
不要急着改数值，先判断是否真的接近提交限制。任务管理器的“性能-内存”页里，重点看“已提交”的 X/Y 值，Y 是提交限制；当 X 持续达到 Y 的90%以上，OOM风险很高。“分页文件使用量”超过80%也说明页面文件吃紧。资源监视器（resmon）中，看“硬错误/秒”：0到10正常，10到100偏高，持续100以上则表明系统大量依赖磁盘换页。性能监视器（perfmon）可用计数器持续采集，比较关键的有 Memory\Available MBytes、Memory\Committed Bytes、Memory\Commit Limit、Memory\% Committed Bytes In Use、Paging File\% Usage 以及 Memory\Hard Faults/sec。当“% Committed Bytes In Use”持续大于85%、硬缺页持续大于100时，就基本可以确定是提交内存瓶颈。
事件查看器也会留下线索。运行 eventvwr.msc，在“Windows 日志-系统”中筛选“Resource-Exhaustion-Detector”，该事件（ID 2004）会记录内存不足时资源占用靠前的进程。“应用程序日志”里的“Application Error”则能看到程序崩溃的完整信息。
PowerShell快速查询方式如下：- # 物理内存总量(GB)
- (Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory / 1GB
- # 页面文件配置
- Get-CimInstance Win32_PageFileSetting | Format-List Name, InitialSize, MaximumSize
- # 页面文件实际使用量
- Get-CimInstance Win32_PageFileUsage | Format-List Name, AllocatedBaseSize, CurrentUsage, PeakUsage
- # 提交限制与当前提交量
- $os = Get-CimInstance Win32_OperatingSystem
- "CommitLimit(GB): " + [math]::Round($os.TotalVirtualMemorySize / 1MB, 2)
- "CommittedBytes(GB): " + [math]::Round(($os.TotalVirtualMemorySize - $os.FreeVirtualMemory) / 1MB, 2)
页面文件的配置路径
使用 Win+R 运行 sysdm.cpl，进入系统属性-高级-性能设置-高级-虚拟内存更改，这是最快捷的入口。进入“虚拟内存”窗口后，第一步要取消勾选“自动管理所有驱动器的分页文件大小”。Windows默认自动管理虽然能应对普通场景，但它在内存压力突然增大时，页面文件扩展存在延迟，最大值也不一定能满足开发、虚拟机等极端负载。取消自动管理后，可以手动指定每个分区的页面文件大小和位置。
配置时要先选中分区。页面文件必须放在NTFS分区，不支持ReFS、FAT32、U盘、SD卡与网络驱动器。优先级方面，NVMe SSD最好，SATA SSD次之，机械硬盘不推荐。如果系统盘是HDD而机器里有独立SSD，务必把页面文件迁移到SSD。之后再选择“自定义大小”，填入初始大小与最大值，单位都是MB。这里有个容易忽略的细节：填完数字必须点右侧的“设置”按钮，看到分区列表状态更新后再点“确定”，否则配置不会保存。其它不需要页面文件的分区可以逐一分区选中并设为“无分页文件”。
所有改动要重启电脑才生效。重启后可以重新打开虚拟内存窗口核对配置，也可在任务管理器底部看“已提交”的 Y 值，确认它等于“物理内存+页面文件最大值”。
容量规划参考
页面文件没有绝对统一的答案，需要结合物理内存大小和场景。常见推荐如下：4GB内存约设置6144MB初始和8192MB最大；8GB约设置12288MB初始、16384MB到24576MB最大；16GB可设16384MB初始、24576MB至32768MB最大；32GB可设16384MB到32768MB初始、32768MB至49152MB最大；64GB以上保留16384MB到32768MB即可，不必继续放大。物理内存越大，页面文件相对比例可以越小，但即使128GB内存也建议保留8至16GB，避免某些驱动或调试工具因无后备页而异常。
如果你的目标是稳定应对OOM，推荐“初始大小=最大值”。这样系统启动时页面文件就固定分配好，省去运行时动态扩展的I/O开销，也避免扩展时因磁盘空间或碎片问题失败。缺点是会固定占用磁盘空间，适合目标分区剩余空间大于页面文件最大值1.2倍的情况。若磁盘紧张，可以允许初始小于最大，但要接受极端负载下扩展不及时的OOM风险。
针对开发场景，Visual Studio、Docker Desktop、WSL2与多浏览器同时运行时，16GB内存建议设16384/32768，32GB可设16384/49152。运行大型虚拟机时，因为宿主机还要承担系统进程与I/O缓存，需要预留更大的提交空间，32GB物理内存建议设16384/49152。视频剪辑和3D渲染软件内存峰值高，16GB物理内存可设16384/49152，32GB可设32768/65536。AI场景要分清是系统内存OOM还是GPU显存OOM。显存OOM与页面文件无关，只能通过减小Batch Size、混合精度、梯度检查点等手段缓解。数据库开发时先在SQL Server等软件里限制最大服务器内存（如物理内存70%），再用页面文件兜底，避免数据库缓存把页面文件撑爆。
多磁盘策略
单SSD直接按推荐值设置即可。多块SSD时，可以只将页面文件集中在系统盘以简化管理，也可以在系统盘和另一块NVMe SSD上分别创建页面文件（如各自16384MB固定），让Windows在执行换页时并行访问多个盘，降低单盘压力。混合SSD+HDD时，页面文件必须全部落在SSD。机械硬盘寻道时间是毫秒级，页面交换会导致系统明显卡顿甚至如同死机。
常见误区
不要为了省空间完全禁用所有分区的页面文件。Windows的崩溃转储、内核模式调试和部分应用程序的提交内存都依赖页面文件，完全禁用很可能导致新的“虚拟内存不足”错误。另一个误区是把页面文件放到内存盘或可移动设备，内存盘断电数据丢失，U盘和SD卡性能不可靠，都会破坏系统稳定性。
按上述方式配置后，再遇到IDE编译、容器构建或大模型加载导致的内存紧张，系统至少不会因为提交限制不够而直接触发OOM。如果仍然出现频繁硬缺页或系统级崩溃，就要考虑增加物理内存、优化应用内存占用或把工作负载拆分到多台机器了。 |
发表于