CPU利用率曲线反映调度效率而非忙闲，单线程瓶颈需查Process Explorer，内核时间超30%多因驱动异常；已提交内存逼近限制值将致进程失败；磁盘响应时间超20ms即感知卡顿；GPU内存使用率高未必真忙；句柄泄漏比CPU满载更危险。
CPU利用率曲线背后是调度效率，不是忙闲判断
任务管理器性能页的cpu图表不是“用了多少算力”，而是“操作系统如何分派任务”。单看% processor time数值没意义，关键要看多核心曲线分布和内核时间占比。
- 若仅1–2个逻辑处理器长期满载，其余近乎空闲，说明是单线程瓶颈（如老旧Python脚本、未优化的SQL查询），换更多核CPU无效，应查
Process Explorer定位具体线程 - 右下角标注的“内核时间”持续高于30%，大概率是驱动异常或硬件中断风暴，不是软件问题；可运行
verifier.exe开启驱动验证后复现观察 - 频率值卡在基础频率（如标称4.5 GHz但只跑3.2 GHz），优先检查
Power Plan是否设为“省电”，再排查散热——用HWiNFO64看PPT / TDC / EDC三值是否触发限频
内存“已提交量”才是真实压力红线
别被“已使用/可用”误导。“已提交(Committed)”才是系统承诺给进程的总内存配额，它 = 物理内存 + 页面文件大小。一旦逼近该值，新进程就会失败，报错0x8007000E。
- 在性能页底部查看“已提交”和“限制”两栏，差值小于500 MB即进入高危区；此时即使“可用内存”还有1 GB，也极可能无法启动VS Code或Chrome新窗口
- “已修改”内存长期高于500 MB且不下降，说明脏页未刷盘，断电易丢数据；可结合
perfmon中Memory\Pages/sec> 1000 判断是否频繁换页 - “硬件保留”异常偏高（如16 GB机器显示保留2 GB），常见于独显BIOS映射冲突，需进UEFI关闭
Above 4G Decoding或更新固件
磁盘延迟比队列长度更能暴露I/O瓶颈
任务管理器磁盘页的“响应时间”（Avg. Disk sec/Read）比“活动时间%”或“队列长度”更敏感。用户感知卡顿往往始于毫秒级延迟抬升，而非吞吐饱和。
-
Avg. Disk sec/Read> 0.02 s（20 ms）即可感知卡顿；SSD正常应≤5 ms，HDD ≤15 ms；若持续>30 ms，先排除chkdsk /f未完成导致的元数据锁定 - 队列长度
Avg. Disk Queue Length> 2 每磁盘才提示I/O拥塞，但很多NVMe设备因并行度高，队列长度常年>10却无感——必须和延迟交叉看 - 磁盘“活跃时间%”接近100%但延迟不高，可能是大块顺序读写（如视频转码），属健康负载；若伴随高延迟，则是随机小IO风暴（如杀毒扫描+Windows Search同时索引）
GPU专用内存使用率高≠显卡真忙
独立GPU页的“专用GPU内存”使用率高，但“共享GPU内存”几乎为零，大概率是驱动未启用WDDM 2.7+统一内存管理，而非应用真在压榨显存。
- 用
GPU-Z切到Sensors页，对比Memory Controller Load和Memory Usage：若显存使用率95%但控制器负载仅60%，说明带宽未打满，瓶颈在GPU核心调度或驱动 - “GPU负载”长期100%但帧生成时间（
Frame Time）抖动剧烈，大概率是CPU端提交指令慢（如浏览器JS阻塞渲染线程），不是显卡不行 - 集成显卡的“GPU内存”实际来自系统内存，其“专用”部分受BIOS中
UMA Frame Buffer Size设置限制；若该值被设为64 MB，哪怕你有32 GB内存，显卡也撑不起4K视频播放
真正容易被忽略的是句柄泄漏——Handle Count在性能页底部持续缓慢上涨且重启后回落，比CPU 100%更危险。它不会立刻卡死，但会悄无声息耗尽系统句柄池（默认约1600万），最终导致CreateProcess失败、桌面窗口管理器崩溃，而任务管理器自身都可能无法打开。
