VmmemWSL 内存占用高，先查任务再回收

VmmemWSL 在任务管理器中代表 WSL 虚拟机环境使用的资源。其内存可能包括活跃的 Linux 工作负载和缓存。如果 Docker、AI 模型服务器或开发工具在那里运行，关闭 Windows 编辑器不一定能停止那项工作。

首先确定内存属于正在运行的任务，还是任务结束后仍保留的缓存。删除 WSL 虚拟磁盘不是内存修复方法，可能破坏 Linux 环境及其数据。

查找 WSL 内的工作负载

从 PowerShell 检查已安装的环境：

wsl --version
wsl --list --verbose
wsl --list --running

在相关 Linux 发行版内，使用这些只读视图：

free -h
ps -eo pid,comm,rss --sort=-rss

Linux 的读数与任务管理器的 VM 总量范围不完全相同。用它们定位进程并区分可用内存与文件缓存，而不是强求每个数字完全吻合。对于 Docker 中运行的任务，检查 Docker Desktop 的运行容器，并通过其正常控制停止预期任务。

AI 服务器可能在回答后仍保持模型加载。如果不再需要该工作负载，通过模型服务的正常方式停止它。不要仅仅因为进程名称不熟悉就随意终止它。

阅读 Linux 内存样本，不把每一份缓存都当作泄漏

在 free -h 的输出中，既要注意 available，也要注意 used 和 buff/cache。Linux 会把原本空闲的内存用于文件数据，其中一部分在应用程序需要时可以回收。因此，仅凭一个较小的 free 值，不足以断定 Linux 内存已经耗尽。

进程列表以 KiB 报告 RSS，而 free -h 使用人类可读单位。共享页和 VM 开销也意味着，把各进程行相加不一定等于任务管理器中的 VmmemWSL 数值。用最大的几行确定占用者，再检查相应的工作负载，不要强行让总数一致。

如果涉及 Docker，以下只读命令可列出正在运行的容器并采集一次资源样本，参见 Docker stats 参考：

docker ps
docker stats --no-stream

在与被调查的 Docker 后端相连的环境中运行这些命令。不同的 Docker 上下文可能指向远程机器，因此操作前先确认目标。容器显示的内存数值与整个 WSL VM 总量范围不同。

对比三种状态：AI 任务启动前、运行中，以及应用程序正常卸载模型或停止任务之后。如果大进程仍然存活，缓存回收不能代替判断该进程是否应继续运行。如果进程缩小但缓存仍在，回收行为就成了更相关的问题。

检查当前回收设置

Microsoft 的 WSL 配置参考 将全局 WSL 2 设置放在 %USERPROFILE%\.wslconfig 中。它不同于发行版内的 /etc/wsl.conf。

当前参考在 [experimental] 下列出 autoMemoryReclaim，其默认值为 dropCache，另一种支持的模式为 gradual。因此，声称这个选项默认关闭、必须手动开启的旧建议可能已经过时。在添加任何内容之前，检查已安装的 WSL 版本和现有配置。

如果已安装的版本支持这个设置，而且你希望逐步回收缓存，将此条目合并到现有文件中：

[experimental]
autoMemoryReclaim=gradual

不要覆盖无关设置或创建重复的配置节。这改变缓存内存的回收方式，不会让活跃模型或数据库需要更少内存。在决定是否保留更改前，比较相同工作负载。

修改现有配置并保留回退路径

在文件资源管理器中打开 %USERPROFILE%，在创建或编辑 .wslconfig 之前启用文件扩展名。误存为 .wslconfig.txt 的文件并不是想要的配置。先把现有配置复制为备份，并保留与内存无关的配置段。

在一个现有 [experimental] 配置段下，只改动正在测试的回收项。只有在不存在配置且确实需要更改设置时，才需要新建文件。不要同时添加 dropCache 和 gradual 两行，也不要在从不同文章复制示例后重复该配置段。

Microsoft 记录的默认值本就会回收缓存。将其改为 gradual 是一次策略实验，并非总能节省更多内存的升级。它可能让缓存驻留得比立即回收更久。如果当前行为没有表现出问题，就保留默认值，转而调查活动工作负载。

通过安全的 WSL 重启应用更改后，再次运行同一任务，观察 Windows 操作是否流畅、Linux 可用内存以及任务是否完成。如果更改没有帮助，从备份恢复先前的条目，再以同样的先保存后重启的预防措施应用该恢复。不要为了移除一行实验性配置就删除整个配置文件。

仅在保存工作后重启 WSL

配置更改在 WSL 环境重启时生效。Microsoft 的 基本命令 记录了全局关闭命令：

wsl --shutdown

使用前，保存文件，停止训练或推理任务，并正常关闭受影响的容器或数据库。该命令停止所有运行中的发行版和 WSL 2 VM，包括 Docker Desktop 背后的工作。它会关闭整个环境，不能只回收其中一部分内存。

如果关闭后 VmmemWSL 内存消失，只能说明这部分内存来自刚刚关闭的环境。它不能区分泄漏与活跃任务或有用缓存。重启所需服务，在相同工作完成后比较。

将按任务需求设置内存上限

.wslconfig 的 memory 设置限制 WSL 2 的可用内存。上限太低可能导致 Linux 应用程序失败或大量交换。程序需要的内存不会因此变少。仅在测量工作负载和 Windows 也需要的 RAM 后选择它，然后确认应用仍能完成任务。

Docker Desktop 的 WSL 指南 讨论了其 WSL 后端的内存回收。使用 WSL 后端对应的配置，而不是应用无关的 Hyper-V 指令。

确认内存上限确实已生效

如果需要上限，在现有配置的 [wsl2] 下放置 memory。例如，memory=8GB 表示 8 GB 的限制，而不是为每个发行版保留 8 GB。这是语法示例，不是每台电脑的推荐预算。多个 WSL 2 发行版共享全局 VM 预算，选择上限时要算上它们同时进行的工作。

保存工作并重启 WSL 后，在某个发行版内检查 free -h 报告的总量，并与预期上限比较，同时考虑系统开销。然后运行实际的模型或构建。如果 Linux 任务现在被杀死或把时间花在交换上，任务管理器数值变小并不算成功。

如果限制似乎被忽略，检查拥有该文件的 Windows 账户、文件扩展名、目标发行版是否为 WSL 2，以及旧 VM 是否已完全停止。这些检查比反复调低数值更有信息量。不要把关闭交换作为同时进行的第二个实验，因为这会改变工作负载达到预算时的行为。

对于 Docker 工作负载，保持 Docker 正常的关闭和数据持久化行为不变。关闭终端不一定停止其容器，而全局关闭 WSL 可能中断多个无关服务。在应用 VM 级更改前，通过各应用自身的控制保存数据库和训练工作。

将 RAM 与虚拟磁盘空间分开

Windows 内存指南 涵盖主机端读数。对于磁盘容量，使用单独的 Docker 和 WSL 存储指南。永远不要将 wsl --unregister 用作清理捷径：它删除发行版及其数据，而不是解决高内存读数。