Windows虚拟内存设置指南：从页面文件原理到OOM排查与配置实战

1. 先搞懂一件事：虚拟内存不是"内存不够时的替补"，而是系统内存架构的基石

很多人第一次接触到 Windows 虚拟内存配置，是因为电脑弹出了"内存不足"或者某个程序直接没了，然后去百度搜"内存不足怎么解决"，看到一堆教程说"把虚拟内存调大一点"。但如果你只是照着把虚拟内存从 2GB 改成 8GB，十有八九问题还在——因为你不清楚这个"虚拟内存"到底在内存子系统里扮演什么角色，也不知道 OOM 到底是操作系统报的，还是某个程序自己报的。

先说结论：虚拟内存不是一块"额外内存条"，也不是内存不够时临时拿来用的"慢速缓存"。它是一整套内存管理机制中负责"地址空间抽象"的那个环节。理解了这一点，后面所有配置决策都会变得很简单：什么时候该调大页面文件，什么时候该加物理内存，什么时候该去杀进程，都一目了然。

1.1 物理内存、虚拟地址空间与页面文件，三者到底什么关系

现代操作系统里，每个进程看到的不是真实的物理内存条，而是一段从 0 开始的、连续的"虚拟地址空间"。32 位进程最多能访问约 4GB 地址空间，64 位进程理论上大到几乎用不完。进程里所有代码、堆、栈、动态库，都映射到这段虚拟地址空间的某些区域。CPU 在访问内存时，通过 MMU（内存管理单元）把虚拟地址翻译成物理地址，真正落到内存条上。

这里有一个关键点：这个翻译过程不是一一对应的。一个进程可能在虚拟地址空间里"预订"了 20GB 的地址区域，但它实际只触碰了其中 10MB。操作系统只给真正"用起来"的页分配物理内存帧，这个机制叫按需分页（Demand Paging）。所以你会看到任务管理器里一个进程显示"提交大小"好几 GB，但"工作集"（实际占用物理内存）只有几百 MB。

页面文件（pagefile.sys）则是一个兜底仓库。物理内存是有限的、大家共享的，当所有进程正在使用的页面加起来超过了物理内存容量，操作系统就必须把一部分暂时用不到的页换到磁盘上，好把物理内存让给正在被高频访问的页面。这个"换出去"的落点，就是页面文件。

所以虚拟内存机制实际上包含三层：每个进程独立的虚拟地址空间、物理内存这个共享资源、以及页面文件这个磁盘后备存储。三者协同工作，让程序可以"假装"自己拥有远超物理内存大小的可用空间，同时保证数据不会因为物理内存被占满而丢失。

1.2 OOM 到底是谁报出来的：Windows 的"内存不足"与进程 OOM 是两码事

我一直觉得，把"系统提示内存不足"和"程序提示 OutOfMemory"混为一谈，是绝大多数排错方向错误的开端。这两类报错虽然都叫 OOM 相关，但成因和解决路径完全不同。

第一类：Windows 系统右下角弹提示"你的系统内存不足"，或者弹窗说"内存不足，请关闭某些程序"。这种是系统级的提交内存（Commit Charge）达到上限了。提交内存可以简单理解为"所有进程向操作系统预订的虚拟内存总量"，它和物理内存是否真的用完没有必然关系。当一个程序申请内存时，它先向操作系统预订一段虚拟地址空间，如果预订总量接近物理内存 + 页面文件的总和，系统就无法再给任何程序分配新的空间，于是报内存不足。

第二类：某个软件自己崩溃，报 OOM。比如 Java 进程抛出java.lang.OutOfMemoryError，或者游戏引擎报"Out of video memory"。这种通常是进程自身的限制，比如 JVM 堆大小设置不当、32 位进程地址空间耗尽、显卡显存不足，跟 Windows 页面文件大小没有直接关系。调整虚拟内存可能缓解，但不是根治手段，甚至完全不相关。

所以实战中你首先得问一句：**这个 OOM 是谁报的？**系统托盘弹的，进系统配置；某个程序报的，先进程序日志。很多人一看到"OOM"就直接去调页面文件，结果折腾半天发现是 Java 堆设小了，这是最经典的无效操作。

1.3 别被"我有 32G 内存"骗了：提交内存才是卡脖子的指标

我见过不少用户，物理内存已经加到 32GB、64GB，仍然会遇到系统级内存不足。他们很不解：内存这么大了，怎么可能不够？问题恰恰出在"提交内存"这个指标上。

在 Windows 中，每个进程创建时会预订一块虚拟内存，这部分不算在使用中，但会占用系统级"提交额度"。只要某个进程预订了，哪怕它一个字节都没碰，系统也要确保将来需要时能拿出物理内存帧或者页面文件空间来兑现。系统能承担的最大提交量 = 物理内存大小 + 所有页面文件大小之和。这个值在任务管理器"性能"标签页的"内存"里，显示为"提交限制"。

举个例子：你机器有 16GB 物理内存，页面文件系统托管当前是 8GB，提交限制就是 24GB。如果某个时间段你开了大量浏览器标签、一个虚拟机软件、加上几个 Electron 开发的桌面应用，所有进程的提交量可能瞬间冲到 22GB 左右，离上限只剩 2GB。这时你哪怕物理内存还有空闲，只要再有程序申请较大内存块，系统就可能弹"内存不足"。

这个机制解释了为什么禁用页面文件是极度危险的操作。禁用了页面文件，提交限制 = 物理内存大小，物理内存再大也少了一个缓冲。64GB 内存的机器，只要某个应用极端情况下提交了 65GB 虚拟内存，系统照样报错。所以后面所有配置方案，我都会围绕"提交内存"这个核心来展开，而不是只盯着"物理内存还有多少剩余"。

2. 动手设置前，先查清楚这些关键数据：你的系统到底虚不虚

了解完原理，接下来别急着去改设置。我见过太多人一上来就把页面文件设成"初始 4096，最大 8192"，设完重启，该 OOM 还是 OOM，因为他根本不知道自己系统的内存压力点在哪里。正确的第一步，是先花五分钟把当前系统状态摸清楚。

2.1 一条命令加两个面板，5 分钟摸清内存与页面文件现状

先看页面文件目前的配置和实际使用情况。最简单的入口：按Win + R输入sysdm.cpl，回车后在"高级"选项卡下点"性能"区域的"设置"，再切到"高级"选项卡，底部就是"虚拟内存"区域，点"更改"能看到每个盘符的分页文件大小。

但这只是配置界面，它展示的是"分配大小"，不是"实际使用量"。更准确的信息要用命令行来看。在 PowerShell 里执行：

Get-CimInstance Win32_PageFileUsage | Select-Object Name, AllocatedBaseSize, CurrentUsage, PeakUsage

输出结果里几个字段解释一下：

• Name：页面文件所在路径。
• AllocatedBaseSize：当前分配的页面文件大小，单位是 MB。
• CurrentUsage：当前实际占用的 MB 数。
• PeakUsage：开机以来达到过的峰值占用 MB 数。

如果PeakUsage经常等于或非常接近AllocatedBaseSize，说明页面文件可能不够大，系统在持续扩容或者接近扩容边缘。如果CurrentUsage长期只有几百 MB，说明你的内存在实际运行中并不吃紧，那就不要把页面文件调得太大，没必要白白占用磁盘。

再执行一条命令，看系统级内存状态：

Get-CimInstance Win32_OperatingSystem | Select-Object TotalVisibleMemorySize, FreePhysicalMemory, SizeStoredInPagingFiles

TotalVisibleMemorySize是物理内存总量，FreePhysicalMemory是当前空闲物理内存，SizeStoredInPagingFiles是所有页面文件总和，单位都是 KB。把物理内存总量加上页面文件总和，你就得到了当前提交限制的理论值，和任务管理器里看到的提交限制一致。

2.2 资源监视器里的"提交"和"硬错误"，才是定位关键

任务管理器能看到总体的提交量，但看不到"是谁在提交"。这时候打开资源监视器：Win + R输入resmon，切到"内存"选项卡，默认按"工作集（物理内存）"排序，这个排序方式会误导你。应该点一下"提交(KB)"的列头，按提交大小重新排序。

按提交排序之后，你会很清楚地看到哪些进程是"虚拟内存大户"。很多程序的物理内存占用并不高，比如只有 200MB，但提交量高达几个 GB，这类进程才是把提交限制顶上去的元凶。

另外特别注意"硬错误/秒"这个指标。资源监视器底部"硬错误"一栏，代表程序需要访问的数据不在物理内存中，必须从磁盘页面文件读取。注意一点，"硬错误"不等于"错误"，它是正常的内存管理行为。但如果硬错误数量持续居高不下，比如一直有几万个还在涨，说明物理内存在高压力下被频繁换页，系统已经开始依赖磁盘来维持运行了。这时候你会感觉电脑明显变卡，因为即使是 NVMe SSD，访问速度也比内存慢几个数量级。

这种情况就说明：虚拟内存确实在起作用，但物理内存已经不够用了。增加页面文件只能让系统"不报错"，不能让它"变快"，真正该做的是关进程或加物理内存。同理，如果你发现硬错误很少，但系统还是报内存不足，那就是提交量接近上限的问题，调大页面文件就有意义。

2.3 不要被三个表面现象误导

第一，任务管理器里显示页面文件"已用 100%"，不代表出问题。Windows 会尽量使用空闲物理内存做缓存，页面文件的使用量波动很正常。页面文件可以动态增长，所以"当前占用接近当前分配大小"也不是故障信号。

第二，"我的 C 盘显示空间不足"和"页面文件需要空间"是两个问题。页面文件默认在 C 盘，但如果你把 C 盘塞满到只剩几百 MB，Windows 在扩容页面文件时会失败，甚至可能导致系统运行异常。这个情况下要先清理磁盘，而不是去改虚拟内存。

第三，有些人喜欢在"性能选项"里把虚拟内存改成"无分页文件"，理由是"我有这么多内存，不需要磁盘来拖慢速度"。这个操作我建议绝对不要做。前面已经解释过，提交限制会缩水到只剩物理内存，很多默认会预订大量虚拟内存的应用（浏览器、开发工具、Adobe 系列）会直接崩溃或行为异常。而且 Windows 在发生蓝屏时需要用页面文件写内核内存转储，没有页面文件，蓝屏诊断信息都留不下来。

3. 配置方案怎么选：16G、32G、64G 分别怎么设

现在进入正题：到底该把虚拟内存设成多大。这个问题网上答案千奇百怪，有说设成物理内存 1.5 倍的，有说 2 倍的，还有说"初始化大小 4096，最大值 8192"一刀切的。这些说法不能说全错，但基本都不讲前提，离开你的实际内存大小和使用场景谈参数，全是耍流氓。

3.1 不同容量下的推荐参数表

先给一张按物理内存容量划分的参考表。前提是：普通台式机/笔记本，Windows 10 或 Windows 11，系统装在 SSD 上，日常覆盖办公、网页、影音、轻度到中度开发、游戏等常见场景。

注意，我推荐的首选方案几乎都是"系统托管"。这个后面专门说。上面"自定义"列只适用于特殊需求，比如你有多块硬盘想指定页面文件落盘位置，或者公司安全策略要求固定大小。

为什么大内存机器反而不需要很大的页面文件？因为内存够大，实际换页需求极少。但保留一个小页面文件，可以确保提交限制高于物理内存，给系统留出余量。很多专业软件（比如数据库、渲染器）在启动时会检查可提交内存，太小可能直接拒绝启动。

3.2 为什么我更推荐"系统托管"而不是"自定义大小"

在多数 Windows 10/11 版本中，系统默认开启"自动管理所有驱动器的分页文件大小"。这个选项开启时，Windows 会综合物理内存大小、历史使用峰值、磁盘剩余空间等因素，动态调整页面文件大小。

很多老教程不喜欢系统托管，理由是"页面文件会忽大忽小，导致碎片化"。这个说法在机械硬盘时代有一定道理，当时动态扩容会在大文件旁边产生碎片，影响读取速度。但现在系统盘基本都是 SSD，页面文件的随机读写性能远好于机械硬盘，碎片化对性能的影响可以忽略。而且 Windows 对页面文件的碎片管理也做了大量改进，没必要再手动固定成一个大文件来"防碎片"。

自定义大小最怕遇到什么问题？我遇到的实际案例是：初始大小设了 1024MB，最大值设了 8192MB，结果某个程序提交内存突然暴涨，页面文件从 1GB 一路扩容到 7GB。扩容期间系统响应明显变慢，因为页面文件在洞洞板一样的磁盘空间里找连续区域写数据。如果初始大小直接设成 8GB，就不会有这个问题，但又浪费了磁盘空间。系统托管则会在后台用更聪明的策略处理，不需要用户操心。

还有一点：系统托管下，Windows 会把页面文件放在系统盘上，系统发生蓝屏时能正常创建崩溃转储文件。如果你手动把页面文件搬到其他盘，同时又在系统盘设了"无分页文件"，蓝屏时将无法生成完整的 minidump，排错会非常被动。

3.3 SSD 场景下的页面文件设置：寿命与性能如何平衡

关于 SSD 和虚拟内存，最常见的担心是：页面文件频繁读写，会损耗 SSD 寿命。这个担心理论上成立，但实际影响远比想象中小。现代 SSD 的寿命用 TBW（总写入字节数）来衡量，普通的 512GB SSD 通常有 300TBW 以上寿命。页面文件每秒读写量即使峰值很高，日常均值也就几十 MB，一天下来很难超过几百 GB。按这个速度，页面文件的写入摊到整块 SSD 上，对寿命的影响微乎其微，远不如下载大文件、视频剪辑、数据库写入来得明显。

所以我不建议为了"保护 SSD"而禁用页面文件或者把它迁到机械硬盘。把页面文件放在机械硬盘上，内存压力一大，系统会在慢速磁盘上疯狂换页，整机卡到怀疑人生，这种体验损失远大于省下的那点 SSD 寿命。

如果你有两块 SSD，可以考虑把页面文件放到第二块上。这个操作的意义不是保护系统盘，而是让页面文件的读写与系统盘上的其他 I/O 分离。比如你在编译大型项目或运行数据库时，系统盘本来就有大量读写，页面文件又参与进来，容易出现 I/O 排队。放到第二块 NVMe SSD 上能分摊一些压力，但提升幅度有限，不必强求。如果你只有一块 SSD，乖乖放 C 盘就行，别折腾。

4. Windows 11/10 虚拟内存配置实操：从入口到验证

配置虚拟内存本身不难，但有个细节很反直觉：你点了"确定"不代表设置生效，改过之后必须重启，而且设置界面里的"设置"按钮特别容易被忽略。

4.1 完整设置步骤，注意每一步的坑

第一步，打开虚拟内存配置窗口。最快的方式是Win + R输入sysdm.cpl，在"高级"选项卡下点"性能"的"设置"，再切到"高级"选项卡，点击"虚拟内存"区域的"更改"按钮。

第二步，取消勾选最上方的"自动管理所有驱动器的分页文件大小"。不取消这一步，下面所有选项都是灰色的，改了也没用。

第三步，选择你要放置页面文件的盘符。默认是 C 盘。如果你只是想调整大小，选中 C:，再选"自定义大小"，填入初始大小和最大值，然后点一下右侧的"设置"按钮。这一步非常关键，很多人填完数字直接点"确定"，回头再看发现根本没改，就是因为漏掉了"设置"按钮。对话框下方当前显示的还是旧值。

第四步，如果你在某个盘上已经设置了页面文件，但现在不想要了，选中该盘符，选"无分页文件"，点"设置"。Windows 会建议你在其他盘保留至少一个页面文件，否则蓝屏时没法写转储，除非你确实了解后果，否则建议在系统盘保留一个小页面文件。

第五步，一路点"确定"，系统会提示"需要重新启动计算机才能生效"，重启后配置生效。

4.2 自定义大小之后怎么验证真的生效了

重启完成后，先别急着开一堆软件，先验证一下设置是否写入。最简单的验证方式：再次打开虚拟内存设置界面，看对应盘符下显示的"当前分配"是否和你的设置一致。但有时候系统托管的旧配置没清理干净，界面显示的值可能有缓存，所以更推荐用命令验证。

Get-CimInstance Win32_PageFileUsage | Select-Object Name, AllocatedBaseSize

这个命令的输出会直接告诉你每个页面文件的实际分配大小。如果你设置了 C 盘 4096MB，这里应该显示 4096。

同时看一眼提交限制是否变化。打开任务管理器的"性能"标签，切到"内存"，右下角有"已提交"的"更改/限制"两项。提交限制应该约等于物理内存 + 你设置的所有页面文件大小之和。如果你把页面文件从系统托管改成了固定 8GB，提交限制会相应变化，这个变化可以帮你确认 Windows 确实按新配置在运行。

4.3 配置中常见的几个"你以为成功了其实没有"的坑

• 填了参数但没点"设置"按钮，点"确定"直接关闭。这个问题出现的频率高得离谱，我给人远程排查时，十次有七次是这个原因。
• 选择了"无分页文件"后，C 盘依然显示有 pagefile.sys 文件。这个文件可能属于旧的崩溃转储配置，也可能是休眠文件（hiberfil.sys）让你看混了。确认页面文件状态以Win32_PageFileUsage命令为准，别用文件资源管理器猜。
• 设置了自定义大小，但系统盘空间不够。页面文件在初始化时要一次性占用"初始大小"对应的磁盘空间，比如你设置 8192MB，剩余空间低于 8GB 就会失败。建议至少保留初始大小 2 倍以上的空闲空间。
• 某些"优化工具"会把虚拟内存自动改成固定值，同时禁用自动管理。如果你以前用过系统清理、优化类软件，第一次设置前最好先检查一下当前配置，不要默认现在是系统默认状态。

5. OOM 实战排查：谁在吃掉你的内存

配置调整完之后，如果系统还是报内存不足，或者程序还是 OOM，那就不能继续停留在"调虚拟内存"这个层面了。这时候要像排查故障一样，一步步定位内存到底被谁吃掉了。

5.1 系统提示"内存不足"，先从提交峰值找突破口

如果你的系统是"偶尔弹内存不足，重启就好"，那大概率是某个瞬间提交内存冲到了上限。这时候普通任务管理器已经不够用了，因为等你打开任务管理器，峰值可能已经回落。可以用性能监视器记录一段时间的提交量变化。

Win + R输入perfmon，打开性能监视器，添加计数器时选择Memory对象下的Committed Bytes和Commit Limit两个计数器。Committed Bytes 是当前提交数，Commit Limit 是提交上限。把这两个值叠加在一张图上观察，如果在崩溃发生前 Committed Bytes 逼近 Commit Limit，说明就是系统级提交瓶颈。这时调大页面文件最大值是有效的。

如果 Committed Bytes 一直离 Commit Limit 很远，但系统还是提示内存不足，问题就不在虚拟内存了。要么是某个进程内部报错被误读成系统提示，要么是驱动层申请连续物理内存失败，这类情况就要去看事件查看器里的应用程序日志和系统日志。

5.2 高频 OOM 场景逐个击破

我在实际维护机器时发现，下面几个场景的 OOM 出现频率最高，而且每个的解决思路差异很大。

浏览器多开。Chrome/Edge 每个标签页都是独立进程，每个进程都会预留不少虚拟内存。开几十个标签页，提交内存轻松冲到 10GB 以上。加上部分网站后台脚本一直跑，JavaScript 堆不断膨胀，看视频时还要额外申请显存缓冲。这种情况下加大页面文件可以避免系统报错，但浏览器本身可能因为单进程内存过大而卡顿。更有效的做法是换掉那些自动休眠标签页的浏览器插件，或者定期清理标签页。

WSL2 和 Docker Desktop。这两个是开发者的"内存黑洞"。WSL2 默认会使用物理内存的 50% 或更多，即便里面只跑了一个很小的服务。Docker Desktop 基于 WSL2，默认配置同样激进。如果你 32GB 内存，跑着 Docker 桌面版、VS Code、Node 服务，再开两三个浏览器窗口，提交内存很容易压到极限。这时要在用户目录下创建.wslconfig文件，限制 WSL2 的内存和交换空间：

[wsl2] memory=8GB swap=4GB

保存后执行wsl --shutdown让配置生效。改完之后 WSL2 只会使用最多 8GB 物理内存，剩余的留给宿主机。这个配置是解决"Docker 一开，系统就内存不足"最直接有效的手段。

Java 进程，特别是 Elasticsearch、Kafka。这类进程的 OOM 大多和 JVM 堆配置有关。Elasticsearch 的堆大小在config/jvm.options里，默认-Xms1g -Xmx1g，数据上来之后很容易堆内存溢出。Kafka 的 OOM 很多时候是堆外内存和页缓存设置不合理。解决办法不是说加大 Windows 页面文件，而是审视 JVM 的和系统内存的分配比例。我给 Elasticsearch 调优时总的原则是：给 ES 的堆不要超过物理内存的一半，同时确保系统剩余内存足够运行操作系统和其他基础服务。如果机器内存本身不够，就加大页面文件也只是推迟崩溃时间，治标不治本。

游戏和图形应用。有些游戏在加载新地图时会出现瞬时提交内存飙升，如果你页面文件最大值设小了，游戏就会直接闪退。这时候把页面文件最大值放宽到物理内存的 1.5 到 2 倍比较稳妥。但这只能解决"系统提交上限"层面的问题，如果游戏本身有显存泄漏，还是要更新驱动或者等游戏补丁。

5.3 内存泄漏与驱动占用：RAMMap 和池内存的定位思路

有一种 OOM 最让人头疼：内存占用慢慢爬升，几天后系统越来越卡，最后弹窗报错，重启后一切恢复正常。这是典型的内存泄漏。Windows 下优先用微软官方的 RAMMap 工具定位，它可以按页类型、按进程把物理内存的每一页都列出来。

打开 RAMMap 后看Process标签页，按 Private 列排序。Private 列表示进程独占的物理内存，如果某个进程的 Private 值持续增长不回落，基本可以锁定就是它在泄漏。常见的泄漏源包括：第三方杀毒软件、部分厂商的显卡驱动托盘程序、某些网卡驱动、笔记本电源管理服务。修复方式是更新驱动、更换软件。手动清空待机列表（Standby List）只能临时让"可用内存"数字变好看，解决不了泄漏根源，因为待机列表本来就会被系统自动回收。

驱动层面的内存占用还有一个隐蔽来源：非分页池（Nonpaged Pool）。如果你注意到系统内存里 Paged Pool 和 Nonpaged Pool 数值异常高，且没有对应的高占用进程，那很可能是某个内核态驱动泄漏。可以用poolmon工具配合主题标识来定位具体驱动，但这个操作难度较高，普通用户建议直接通过 Windows 事件查看器找到最近更新或报错的驱动，然后回滚或更新。

5.4 我已经按推荐设置了还是报错，按这个顺序排查

如果你严格按照推荐设置调整了页面文件，还报内存错误，别急着重装系统，按下面这个顺序走一遍。

第一步，看"提交限制"和"已提交"的关系。如果已提交已经顶到限制，说明当前的页面文件最大值仍然不够。先临时把最大值再调大一倍，看能否缓解。如果已提交不高但物理内存长期 100%，那说明是物理内存不够而不是虚拟内存不够，加页面文件没有意义。

第二步，看 C 盘剩余空间。页面文件扩容失败经常被误读为"内存不足"，因为系统没有直观提示"页面文件无法扩容"。C 盘剩余空间至少保持 10GB 以上。

第三步，查事件查看器。在"Windows 日志 -> 系统"里找最近红色错误级别的日志，关键词包括"内存""资源不足""提交"等。同时在"应用程序"日志里找对应程序报错记录。这一步能帮助区分系统级 OOM 和程序级 OOM，很多问题到这里就清晰了。

第四步，检查是否同时运行了多个内存大户。比如你开了虚拟机，又开着 Docker，还有几十个浏览器标签，那无论虚拟内存设多大都很难完全避免卡顿。虚拟内存不是无限量的，物理内存的瓶颈只能靠压缩并发或者加内存条来治。

6. 收尾经验：我踩过的坑和最终养成的配置习惯

关于 Windows 虚拟内存配置，我自己的态度经历了一个变化过程。刚接触电脑时，觉得虚拟内存是个好东西，越大越快，于是直接设成 16GB 固定值。后来觉得系统托管才是王道，干脆全部交给 Windows。中间还犯过一次傻，为了追求"极致性能"把所有页面文件都禁用了，结果 PS 和浏览器轮流崩溃，折腾一晚上才反应过来。

现在我的配置习惯很简单，也推荐你参考：系统盘保持系统托管，不做特殊设置；如果机器内存小于等于 16GB，我会在空间充裕的第二块 SSD 上再设一个最小 2048MB、最大 4096MB 的页面文件，作为系统盘压力过大时的兜底。如果只有一块 SSD，那什么都不动，默认就能跑得很好。

我还养成一个习惯，每次给机器做性能排查时，顺手记录一下PeakUsage这个数值。页面文件的峰值使用量是个特别有用的指标：它间接告诉你系统在历史运行中是否出现过物理内存压力。如果峰值长期接近分配上限，说明你的使用模式对内存需求很大，这种情况下我优先考虑加物理内存条，而不是无限调大页面文件——因为磁盘再快也快不过内存，页面文件只能解决"能不能跑"的问题，解决不了"跑得快不快"的问题。

最后分享一个小技巧：调完虚拟内存后，不要马上开大型软件，重启后先让它空载跑十几分钟，让 Windows 完成页面文件的预分配和系统服务预热。然后再打开平时常用的软件，观察任务管理器里提交内存的变化。如果提交值稳定在限制的一半以下，这次配置就是成功的。如果还是经常逼近上限，说明该精简化启动项、关掉多余服务，或者认真考虑升级物理内存了。