# 【AI 工作流手记 #4】物理内存只用了六成，机器已经开始卡：读懂 Windows 的"提交内存"，附 30 行 Python 监控

## 起因：同一台机器，两个"内存占用"差了 18 个百分点

我给一台 Win10 开发机写了个每天自动跑的体检脚本，只读不写，落一份快照。翻了几天记录之后发现一处别扭：有一天的"内存占用"是 62.9%，机器却已经肉眼可见地卡——窗口切换有顿感，编辑器里打字偶尔掉字。

62.9% 不算高。按常识，得等到 80% 以上才开始难受。于是去任务管理器逐栏对了一遍，看到两个数：

- 「内存」栏：**10.0 / 15.9 GB（63%）**
- 「性能 → 内存 → 已提交」：**22.6 / 27.8 GB（81%）**

第二个数居然**比物理内存总量还大出 6.6GB**。

两个数都是真的，只是回答的问题不一样。搞清它们的分工之后，"为什么才六成就卡"就不再是怪事，而是一个必然结果。

## 关键发现：Windows 的内存有两本账

- **物理内存（In use / Working Set）**：此刻有多少 RAM 里正住着东西。它是**可回收**的——系统缓存随时能被踢走，所以这个数上下浮动很正常。
- **提交内存（Commit Charge）**：系统**已经答应**给所有进程的虚拟内存总量。这笔账必须由「RAM + 页面文件」共同兜底，所以：

  **提交上限 = 物理内存总量 + 页面文件当前大小**

一句话分工：**物理回答"现在住着多少"，提交回答"最坏情况下要住多少"。** 机器卡不卡，看的不是任何一个数，而是两本账之间的**缺口**——承诺出去 22.6GB，实住 10.0GB，中间 12.6GB 是"随时可能被摸"的欠账。真被摸起来，就得从页面文件来回搬，磁盘一忙，顿感立刻出现。

搞清这一层，顺手把相关的几个数字各自管什么列成一张表：

| 数字 | 取法 | 回答什么问题 | 会不会自己降下来 |
|---|---|---|---|
| 物理已用 | `TotalPhys - AvailPhys` | 此刻 RAM 住着多少 | 会（缓存可回收） |
| 可用物理 | `AvailPhys` | 新进程要内存时能立刻拿到多少 | 会 |
| 提交已用 | `TotalPageFile - AvailPageFile` | 系统已经承诺出去多少 | **基本不会**（要等进程释放） |
| 提交上限 | `TotalPageFile` | 承诺能力的天花板 | 会（页面文件可伸缩） |
| 提交峰值 | `CommitPeak` | 开机以来最高承诺到过多少 | 不会（历史极值） |

## 实测：一台 16GB 机器上的一组数

同一次采样，把这几个数一起打出来：

| 指标 | 实测值 | 说明 |
|---|---|---|
| 物理总量 | 15.95 GB | 标称 16GB |
| 物理已用 / 使用率 | 10.04 GB | **62.9%** |
| 提交已用 / 上限 / 使用率 | 22.59 / 27.75 GB | **81.4%** |
| 页面文件大小 / 实际用量 | 11.8 / 1.78 GB | 15.95 + 11.8 = 27.75 ✅ 口径自洽 |
| 提交峰值 | 28.20 GB | 比"当前上限"还高 0.45GB |
| 进程提交合计 vs 工作集合计 | 19.08 / 10.11 GB | 差 8.97 GB |
| 进程数 / 线程数 / 句柄数 | 288 / 4975 / 164315 | 采样时的负载 |

三步读这张表，三个结论全是反直觉的：

**第一步：提交（81.4%）和物理（62.9%）差了 18.5 个百分点。** 这就是卡感的来源。承诺量与实住量之间的缺口越大，系统越依赖页面文件；而页面文件在磁盘上，哪怕换页只占一小部分时间，交互延迟也会立刻被放大。

**第二步：提交峰值 28.20GB > 当前上限 27.75GB。** 这行数据说明**页面文件是弹性的，上限本身会变**——开机以来确实出现过比现在更高的需求（峰值那一刻页面文件更大），之后被系统收缩了。所以"我现在上限够用"这句话只有当下有效，欠账涨上去它自己会跟着涨，而涨的过程就是磁盘压力的过程。

**第三步：进程提交合计 19.08GB，比系统提交量 22.59GB 少 3.51GB。** 差额是内核与驱动——那次采样里内核池合计 1.13GB（分页池 0.56 + 非分页池 0.57），其余落在驱动、会话池和共享部分。这也解释了一个常见困惑：**把任务管理器"进程"页里所有数字加起来，永远对不上"已提交"总数**——不是你算错了，是总数里本来就有一部分不属于任何用户进程。

## 实现：三套 API 互相对照

Windows 上读这些数有三条路（都只读，不改任何设置），覆盖范围不同，我把三条都调一遍做交叉验证。

**① `GlobalMemoryStatusEx`：最省事，也是任务管理器"内存"栏的同源**

```python
import ctypes
from ctypes import wintypes

G = 1024 ** 3


class MEMORYSTATUSEX(ctypes.Structure):
    _fields_ = [
        ("dwLength", wintypes.DWORD),
        ("dwMemoryLoad", wintypes.DWORD),          # 物理使用率（%）
        ("ullTotalPhys", ctypes.c_ulonglong),      # 物理总量
        ("ullAvailPhys", ctypes.c_ulonglong),      # 物理可用
        ("ullTotalPageFile", ctypes.c_ulonglong),  # 提交上限 = 物理 + 页面文件
        ("ullAvailPageFile", ctypes.c_ulonglong),  # 还可提交多少
        ("ullTotalVirtual", ctypes.c_ulonglong),
        ("ullAvailVirtual", ctypes.c_ulonglong),
        ("ullAvailExtendedVirtual", ctypes.c_ulonglong),
    ]


def mem_status():
    ms = MEMORYSTATUSEX()
    ms.dwLength = ctypes.sizeof(ms)      # 必须先填长度，否则调用失败且不报错
    if not ctypes.windll.kernel32.GlobalMemoryStatusEx(ctypes.byref(ms)):
        raise OSError("GlobalMemoryStatusEx 调用失败")
    commit_used = ms.ullTotalPageFile - ms.ullAvailPageFile
    return {
        "物理使用率%": ms.dwMemoryLoad,
        "物理已用GB": round((ms.ullTotalPhys - ms.ullAvailPhys) / G, 2),
        "提交已用GB": round(commit_used / G, 2),
        "提交上限GB": round(ms.ullTotalPageFile / G, 2),
        "提交使用率%": round(commit_used / ms.ullTotalPageFile * 100, 1),
    }


print(mem_status())
```

**② `GetPerformanceInfo`：多给你"提交峰值"和内核池**

```python
class PERFORMANCE_INFORMATION(ctypes.Structure):
    _fields_ = [
        ("cb", wintypes.DWORD),
        ("CommitTotal", ctypes.c_size_t),
        ("CommitLimit", ctypes.c_size_t),
        ("CommitPeak", ctypes.c_size_t),        # 提交峰值，这行是重点
        ("PhysicalTotal", ctypes.c_size_t),
        ("PhysicalAvailable", ctypes.c_size_t),
        ("SystemCache", ctypes.c_size_t),       # 系统缓存（含 standby 那部分）
        ("KernelTotal", ctypes.c_size_t),
        ("KernelPaged", ctypes.c_size_t),
        ("KernelNonpaged", ctypes.c_size_t),
        ("PageSize", ctypes.c_size_t),          # 下面所有值都是"页数"
        ("HandleCount", wintypes.DWORD),
        ("ProcessCount", wintypes.DWORD),
        ("ThreadCount", wintypes.DWORD),
    ]


def perf_info():
    pi = PERFORMANCE_INFORMATION()
    pi.cb = ctypes.sizeof(pi)
    ctypes.windll.psapi.GetPerformanceInfo(ctypes.byref(pi), pi.cb)
    fields = ("CommitTotal", "CommitLimit", "CommitPeak", "PhysicalTotal",
              "PhysicalAvailable", "SystemCache", "KernelTotal")
    # 关键：这个 API 返回的单位是页数，必须乘 PageSize 才是字节
    return {k: round(getattr(pi, k) * pi.PageSize / G, 2) for k in fields}


print(perf_info())
```

**③ `psutil`：最方便，但口径要先说清**

```python
import psutil

vm = psutil.virtual_memory()
print(vm.total / G, vm.available / G, vm.used / G, vm.percent)

# 下面这三个在 Windows 上恒为 0——不是"没有缓存"，是这套口径没在 Windows 上实现
print(vm.active, vm.inactive, vm.cached)

# 页面文件要单独取
sw = psutil.swap_memory()
print(sw.total / G, sw.used / G, sw.percent)
```

三套跑下来，`GlobalMemoryStatusEx` 和 `GetPerformanceInfo` 的提交量**完全一致**（都是 22.59 / 27.75），可以互相当作校验；而 psutil 在 Windows 上给的是**物理口径**——`percent` 就是 62.9，`free` 和 `available` 是同一个数（都是 5.92GB），因为它在 Windows 上把 `free` 直接映射成了 `AvailPhys`。

## 谁在"承诺"内存：换成按提交量排序

知道总数之后要抓大头。这里有个容易搞混的点：任务管理器默认按**工作集**（谁住得多）排序，但把提交量推高、把系统逼到上限边缘的，往往是那些"承诺了很多、其实没住多少"的进程。所以我按**提交量**排：

```python
import psutil

rows = []
for p in psutil.process_iter(["pid", "name", "memory_info"]):
    try:
        mi = p.info["memory_info"]
        # Windows 上 memory_info().pagefile 就是该进程的提交量（commit charge）
        rows.append((p.info["name"], mi.pagefile, mi.rss))
    except psutil.NoSuchProcess:
        pass

rows.sort(key=lambda r: r[1] or 0, reverse=True)
for name, commit, wset in rows[:10]:
    commit, wset = commit or 0, wset or 0
    ratio = commit / max(wset, 1)
    print(f"{name:<26}{commit / G:>7.2f} GB{wset / G:>8.2f} GB{ratio:>7.1f}x")
```

实测结果（进程名做了匿名化，只留类别；数值为真实采样）：

| 进程类别 | 提交量 | 工作集 | 提交 ÷ 工作集 |
|---|---|---|---|
| 桌面客户端主进程 | 2.26 GB | 1.53 GB | 1.5× |
| 同一客户端第二实例 | 0.77 GB | 0.63 GB | 1.2× |
| 文档编辑器内核进程 | 0.67 GB | 0.09 GB | **7.4×** |
| 邮件客户端 | 0.58 GB | 0.52 GB | 1.1× |
| 浏览器进程 A | 0.45 GB | 0.03 GB | **15.0×** |
| 浏览器进程 B | 0.34 GB | 0.20 GB | 1.7× |

这张表的价值全在最后一列。**提交 ÷ 工作集**越大，说明这个进程"占着账、没住人"——它向系统要了一大片虚拟地址，实际只碰了一小块。平时看不出来，但它是把提交量推到上限边缘的主力：一旦它真去摸那片内存，系统就得临时腾地方，那一刻的卡顿跟它此刻占的 RAM 大小完全不成比例。

所以排查内存只有两个动作：**问"谁住着"，按工作集排；问"谁把账占了"，按提交量排。** 排出来通常是两份不同的名单。

## 踩坑表：七个真踩过的

| 坑 | 现象（实测） | 解法 |
|---|---|---|
| 只看"内存占用百分比" | 62.9% 的机器已经明显卡，因为同期提交占到 81.4% | 两个数一起看，**差值**才是卡感的来源 |
| 拿 `psutil.virtual_memory().used` 当提交量 | 它给的是物理口径（10.04GB），提交量它不返回 | 要提交量必须走 ctypes 的 `GlobalMemoryStatusEx` / `GetPerformanceInfo` |
| 以为 `free` 和 `available` 是两个指标 | 实测两者都是 5.92GB，完全相同 | Windows 上只认 `available`，`free` 是它的别名 |
| 看到 `active/inactive/cached` 为 0 就以为没缓存 | 同一时刻 `SystemCache` 是 5.09GB | 缓存看性能信息里的 `SystemCache`，那三个字段在 Windows 上没实现 |
| 把"进程"页各行相加去核对总数 | 进程提交合计 19.08GB，系统提交 22.59GB，差 3.51GB | 差额属于内核与驱动（那次内核池 1.13GB 起），对不上是正常的 |
| 认为提交上限是固定值 | 提交峰值 28.20GB 反而高于当前上限 27.75GB | 页面文件可伸缩，上限会变；留出余量，别贴着跑 |
| 忘了给结构体填 `dwLength` | API 返回 0、不抛异常，所有字段保持 0，看起来像"内存是 0" | 调 `GlobalMemoryStatusEx` 前先赋 `sizeof(Structure)` |

## 效果

- **成本**：288 个进程全扫一遍 **30.1 ms**，热态连扫三次是 **16~17 ms**。一天落一次快照，写进一行 CSV，七天就能看出趋势——开销可以忽略。
- **可解释性**：搞清两本账之后，"62.9% 就卡"从怪事变成了可预期的结果——缺口 12.6GB，系统已经在换页边缘工作。
- **可定位**：按提交量排序，一眼就能挑出"提交 ÷ 工作集"超过 7 倍的那几个进程，比按工作集排序靠谱得多。
- **可复现**：上面每个数字都是同一次采样的真实输出；`GlobalMemoryStatusEx` 与 `GetPerformanceInfo` 两条路互相印证，口径自洽（15.95 + 11.8 = 27.75）。

## 你可以怎么用

1. **排查"莫名卡顿"先看两个数**：提交使用率、以及它和物理使用率的差值。差值拉开到 15 个百分点以上，卡顿就不再是玄学。
2. **找内存大户分两次排**：问"谁住着"按工作集排，问"谁把账占了"按提交量排。抓不同的人，用不同的名单。
3. **提交量是查泄漏的正确指标**：物理占用会因为缓存回收而回落，提交量不会。一个进程的提交量单调上涨而工作集平稳，基本就是它。
4. **别贴着提交上限跑**：上限本身会随页面文件伸缩，留出余量，才有应对突发承诺的余地。
5. **在 Windows 上用 psutil 要认口径**：`free == available`、`active/inactive/cached` 恒为 0、`swap` 才是页面文件。要提交量，老老实实走 ctypes。

---

> **关于作者**：10 年跨境电商老兵，拥抱 AI 时代。这里记录我踩过的坑和跑通的方法。

---

我给一台 Win10 开发机写了个每天自动跑的体检脚本，只读不写，落一份快照。翻了几天记录之后发现一处别扭：有一天的"内存占用"是 62.9%，机器却已经肉眼可见地卡——窗口切换有顿感，编辑器里打字偶尔掉字。

【AI 工作流手记 #4】物理内存只用了六成，机器已经开始卡：读懂 Windows 的"提交内存"，附 30 行 Python 监控

同一台机器，物理内存占用 62.9%、提交内存 81.4%，提交量还比物理总量多出 6.6GB。三套 API 对照实测，讲清这两个数各自回答什么问题。

操作系统

运维

开发工具

Windows卡顿根源：物理内存占用62.9%时提交内存已达81.4%，两本账缺口12.6GB触发磁盘换页。提交量按虚拟内存承诺计算，需RAM+页面文件兜底，高承诺进程是元凶。附30行Python监控脚本，三套API交叉验证，按提交量排序定位内存大户。

代码解释

Windows

Python

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【AI 工作流手记 #4】物理内存只用了六成，机器已经开始卡：读懂 Windows 的"提交内存"，附 30 行 Python 监控-腾讯云开发者社区-腾讯云

【AI 工作流手记 #4】物理内存只用了六成，机器已经开始卡：读懂 Windows 的"提交内存"，附 30 行 Python 监控

【AI 工作流手记 #4】物理内存只用了六成，机器已经开始卡：读懂 Windows 的"提交内存"，附 30 行 Python 监控

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐