任务管理器里四个被误读的数字
提交大小与内存的区别、GPU 引擎的含义、「磁盘 100%」到底是什么，以及为什么总数永远加不起来。
测试环境Pro (26H2) / Server · 版本号 26300.9457 / 26100.33650 · x64
E1- 版本号
- 26300.9457 / 26100.33650
- 版本
- Pro (26H2) / Server
- 架构
- x64
- 支持
- 文档（E1）
- 证据
- E1官方文档
- 核验日期
- 2026-10-29
- 页面类型
- 概念
任务管理器是概览工具，不是测量工具。四个数字造成最多困惑：
- 内存 vs 提交大小——两个问题，两个答案。
- GPU %——跨引擎的平均值，而那几类引擎根本不可比。
- 磁盘 100%——活动时间，不是吞吐；队列慢也显示“满”。
- CPU %——利用率，不是速度；降频到 800MHz 的 30% 依然很慢。
内存不是一个数字
Section titled “内存不是一个数字”| 列 | 含义 |
|---|---|
| 使用中（已压缩） | 物理内存中的工作集，加上压缩存储 |
| 可用 | 待机 + 空闲——系统能分配出去的量 |
| 已提交 | 由内存或页面文件支撑的总量 |
| 已缓存 | 待机列表，可回收 |
16GB 机器“内存 90%“完全可能健康：Windows 会用缓存填满内存，需要时回收。“只用 50%“但频繁换页的机器则相反。
Get-Counter '\Memory\Available MBytes','\Memory\Committed Bytes','\Memory\Pages/sec' -MaxSamples 5看 Pages/sec 与硬缺页，不要看百分比。
GPU % 是不可比引擎的平均
Section titled “GPU % 是不可比引擎的平均”Windows 按引擎暴露利用率：3D、Copy、Video Decode、Video Encode、Compute。任务管理器那个数字视视图而定可能是平均值，也可能是最忙的引擎。
- 播放视频时“视频解码 100%“正常且便宜。
- “3D 30%“却卡顿，说明瓶颈在别处。
- “Copy”引擎饱和是合成路径的指纹——见WDDM、HAGS 与 MPO。
Get-Counter '\GPU Engine(*)\Utilization Percentage' -MaxSamples 2「磁盘 100%」不代表吞吐满
Section titled “「磁盘 100%」不代表吞吐满”磁盘列是活动时间：采样窗口内有未完成请求的时间占比。5400 转硬盘排队做小随机读时，会一直显示 100%，而吞吐只有 2MB/s。
该看的：
- 响应时间（
Avg. Disk sec/Transfer）——SSD 上超过约 25ms 就是问题； - 队列长度；
- 是哪个进程在做。
Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Transfer','\PhysicalDisk(*)\Current Disk Queue Length' -MaxSamples 5另外：Windows 更新、Defender 扫描、索引都会合理地占满磁盘几分钟。那不是故障。
CPU % 隐藏了频率
Section titled “CPU % 隐藏了频率”CPU 利用率 25%、同时被降到 800MHz 的机器，比满频 100% 的同一颗 CPU 更慢。
Get-Counter '\Processor Information(_Total)\% Processor Performance','\Processor Information(_Total)\% of Maximum Frequency'% Processor Performance 超过 100% 表示正在加速；负载下低于 100% 表示降频。
E1。计数器语义有微软文档依据。本文没有在实验室虚拟机上采集计数器数据。