Windows 11 性能监视器怎么用？适合进阶用户的系统诊断工具

Windows 11 自带的性能监视器，也就是 Performance Monitor，通常通过 perfmon 启动。它和任务管理器、资源监视器看起来都在监控 CPU、内存、磁盘和网络，但三者的用途并不完全相同。 任务管理器更适合快速判断当前哪个进程占用 CPU、内存、磁盘或 GPU；资源监视器适合把进程和实际资源活动联系起来，例如查看哪个进程正在访问某个文件、建立哪些 TCP 连接；性能监视器则更适合建立长期性能计数器、记录数据、观察趋势，并通过 Data Collector Sets 保存持续运行期间的性能数据。 对于进阶用户来说，Performance Monitor 的价值并不是“看几个百分比”，而是建立一套可重复的数据采集方法。 当系统出现卡顿、应用响应变慢、磁盘延迟升高、内存压力、网络异常或者服务器负载波动时，可以通过性能计数器观察故障发生前后的变化，再结合事件日志和其他诊断工具进行交叉验证。 perfmon 就可以直接启动性能监视器 Windows 11 中可以按 Win + R，输入： perfmon 然后回车。 也可以在开始菜单中搜索“性能监视器”。 原文中所说的“需要通过 Windows 功能安装性能监视器”并不准确。Performance Monitor 属于 Windows 管理和诊断工具，并不是通常意义上需要通过“启用或关闭 Windows 功能”额外安装的组件。 性能监视器打开以后，可以看到监视工具、数据收集器集以及报告等功能。 其中最常用的入口之一是 Performance Monitor 本身。 进入以后，可以添加需要观察的性能计数器。 性能计数器比单纯看资源百分比更有价值 Windows Performance Counters 的设计思路，是把系统运行状态拆成大量可以持续采集的指标。 例如 CPU 可以观察 Processor、Process、System 等对象。 内存可以观察 Memory、Process、Cache Manager 等对象。 磁盘可以观察 PhysicalDisk、LogicalDisk 等对象。 网络则可以观察 Network Interface、TCPv4、TCPv6 等对象。 不同 Windows 版本和不同硬件环境下，可用计数器并不完全一样，因此不要机械照抄某一篇教程中的计数器名称。 更重要的是理解计数器背后的含义。 例如： Processor Process Memory PhysicalDisk LogicalDisk Network Interface System 这些对象分别从不同层次描述系统运行状态。 如果只是想知道“现在谁占 CPU”，任务管理器通常更方便。 如果想知道“过去两个小时 CPU、磁盘和内存压力是如何变化的”，Performance Monitor 的价值就开始体现出来。 CPU 使用率不能简单用80%或者90%判断故障 Processor(_Total)\% Processor Time 是非常常见的 CPU 性能计数器。 它可以帮助判断系统是否处于较高 CPU 活动状态。 但“超过80%就是异常”并不是一个通用规则。 如果一台服务器在进行视频编码、编译大型项目或者数据库批处理时长时间保持90%以上 CPU 使用率，这可能完全正常。 反过来，一台办公电脑如果 CPU 只有30%，用户却感觉整个系统严重卡顿，也不能因为“CPU没有超过80%”就认为 CPU 没问题。 因此 CPU 分析应该结合具体工作负载。 如果整体 CPU 使用率很高，可以进一步观察： Processor(_Total) Processor() Process() System 这样可以判断问题究竟是整个系统 CPU 压力，还是某一个进程占用大量处理时间。 对于多核心处理器，还需要观察单个逻辑处理器的负载。 某些应用程序线程并行能力有限，可能出现一个或少数几个逻辑处理器高度繁忙，而整体 CPU 百分比并不高。 这种情况下，不能只看 _Total。 内存分析不能靠一个50MB阈值 原文中“Available MBytes 低于50MB就说明内存不足”的说法不适合作为现代 Windows 的通用判断标准。 Windows 内存管理会根据系统工作负载动态使用空闲内存、Standby Cache、文件缓存以及提交内存。 因此“剩余内存少”本身不等于系统正在发生严重内存压力。 分析内存时应该同时关注： Memory\Available MBytes Memory\Committed Bytes Memory\Commit Limit Memory\Pages/sec Process\Working Set Process\Private Bytes 其中 Pages/sec 也不能简单理解成“超过50就说明内存不足”。 Windows 的页面活动可能来自正常文件访问、内存映射和缓存行为。 真正值得关注的是持续性的异常页面活动是否与应用响应变慢、Commit 接近上限以及工作集增长等现象同时出现。 如果怀疑应用存在内存泄漏，可以长期观察某个进程的 Private Bytes 或其他适合该进程的内存计数器。 如果数值随着运行时间不断增长，而且没有合理的业务原因，就比一次性的“内存使用率很高”更有诊断价值。 虚拟内存不是看到页面活动就应该手动调整 现代 Windows 使用虚拟内存机制是正常现象。 不要因为看到 Pagefile 活动，就直接关闭页面文件，也不要因为看到内存压力，就随意修改虚拟内存大小。 页面文件的具体行为与系统提交限制、物理内存容量、应用工作集和内存管理策略有关。 如果系统出现内存不足，首先应该确定到底是物理内存容量不足、应用内存泄漏、异常提交增长，还是某个工作负载本身需要大量内存。 修改 Pagefile 并不能从根本上解决应用泄漏。 磁盘队列长度不能使用统一的2作为故障线 PhysicalDisk\Avg. Disk Queue Length 经常出现在 Windows 性能监控教程中，但“队列长度超过2就是磁盘性能不足”是一种过度简化。 机械硬盘、SATA SSD、NVMe SSD、RAID 阵列以及不同 I/O 工作负载之间的性能完全不同。 更重要的是，队列长度需要结合磁盘延迟、IOPS、吞吐量和请求类型一起分析。 例如 NVMe SSD 在高并发随机 I/O 下出现一定队列并不意味着硬件出现故障。 相反，如果应用只产生很少的 I/O 请求，但磁盘延迟已经明显升高，队列长度可能并不突出。 因此磁盘诊断应该同时观察： Disk Bytes/sec Disk Transfers/sec Avg. Disk sec/Transfer Disk Read Bytes/sec Disk Write Bytes/sec Avg. Disk Queue Length 不同 Windows 版本中具体计数器名称可能略有变化，因此应该以实际系统显示为准。 延迟往往比吞吐量更能解释“卡顿” 很多用户看到 SSD 标称读取速度达到数GB/s，就认为系统一定不会卡。 实际应用并不是这样工作的。 操作系统、数据库、编译器、虚拟机和应用程序可能产生大量小块随机 I/O。 这时候单纯观察 MB/s 并不能解释用户为什么觉得系统响应慢。 例如一个 SSD 可能拥有非常高的顺序吞吐量，但某一时刻因为大量随机 I/O、后台任务、队列堆积或者设备自身状态导致 I/O 延迟明显上升。 因此磁盘诊断应该把吞吐量、IOPS、队列和延迟结合起来分析。 如果需要进一步确认 SSD 健康状况，还应该使用 SMART、NVMe Health Information、厂商诊断工具等手段。 Performance Monitor 看到的是操作系统层面的 I/O 行为，并不能直接替代 SSD 硬件健康检测。 网络计数器不能直接证明遭到DDoS Network Interface 可以用来观察网络接口的流量，例如接收和发送字节速率。 TCPv4 和 TCPv6 相关计数器也可以提供连接活动信息。 但如果看到大量连接，就直接得出“系统正在遭受 DDoS 攻击”的结论是不可靠的。 服务器可能因为正常业务、浏览器连接池、API 调用、数据库通信、负载均衡器、监控系统等原因建立大量连接。 网络诊断需要结合连接来源、端口、进程、流量方向、连接状态、应用日志以及防火墙日志。 如果需要分析具体数据包，还应该使用 Wireshark 等专业工具。 Performance Monitor 更适合回答“网络接口当前产生了多少流量以及这种流量如何随时间变化”，而不是单独承担完整的网络安全取证。 Performance Monitor 更适合做长期采样 这是它与任务管理器最大的区别之一。 如果用户打开任务管理器看到 CPU 90%，只能说明此刻 CPU 很忙。 如果系统偶尔卡顿，但用户无法预测什么时候发生，那么持续采集性能数据就非常有价值。 可以创建 Data Collector Set，让 Windows 按指定间隔记录性能计数器。 例如可以采集： Processor\% Processor Time Memory\Available MBytes Memory\Pages/sec PhysicalDisk\Avg. Disk sec/Transfer PhysicalDisk\Disk Transfers/sec Network Interface\Bytes Total/sec System\Processor Queue Length 然后让系统运行一段时间。 当问题再次出现以后，再回头分析采样数据，就能够看到故障发生前后各项指标的变化。 这对于服务器、工作站、虚拟机以及偶发性卡顿问题尤其有价值。 采样间隔没有统一的5秒标准 原文把5秒作为建议默认值，并不适合作为所有场景的标准。 采样间隔应该根据问题持续时间和数据量决定。 如果调查的是几分钟内发生的短暂异常，可以采用较短的采样周期。 如果需要运行数天甚至数周，则需要考虑数据量和长期存储。 采样越频繁，记录的数据越细，但数据量也会增加。 因此实际诊断应该根据问题时间尺度选择采样策略，而不是机械地认为5秒就是最佳设置。 系统卡顿应该建立关联，而不是只看CPU 假设用户报告： “Windows 11 每隔几个小时卡顿一次。” 最简单的做法是打开任务管理器等待下一次卡顿。 更有效的方法是提前建立采集方案。 同时记录 CPU、内存、磁盘和网络相关指标。 如果卡顿发生时 CPU 飙升，可以继续查进程。 如果 CPU 正常但磁盘延迟明显增加，则应该调查磁盘 I/O。 如果 Commit 持续增长并接近限制，则需要检查内存压力。 如果网络流量出现异常变化，则继续检查网络接口和具体连接。 如果这些指标都正常，而用户仍然感觉界面冻结，就不能继续围绕资源占用率猜测。 此时应该考虑 Windows 内核、驱动、DPC/ISR、GPU、存储驱动、应用程序自身以及 ETW 事件等更深层次的问题。 Performance Monitor 不是所有性能问题的终点 这是进阶用户特别需要理解的一点。 Performance Monitor 可以告诉你“哪里出现了异常趋势”，但不一定能告诉你“为什么”。 例如 CPU 使用率突然升高。 Performance Monitor 可以证明 CPU 活动增加，但如果需要进一步分析到底是哪个线程、哪个调用路径或者哪个驱动造成问题，就需要进入更专业的工具。 Windows Performance Recorder 和 Windows Performance Analyzer，也就是 WPR 和 WPA，可以利用 ETW 进行更深入的性能分析。 对于蓝屏和内核异常，可以使用 WinDbg。 对于实时进程、文件、网络活动，可以使用 Resource Monitor。 对于 GPU，可以结合 Task Manager、GPUView、WPR/WPA、厂商工具以及 HWiNFO 等工具。 对于存储硬件健康，则应该结合 SMART、NVMe Health 数据和厂商诊断软件。 所以 Performance Monitor 更像是一层“性能数据采集和趋势分析工具”，而不是万能诊断工具。 GPU监控不能简单套用普通性能计数器 原文把“GPU Usage”和“GPU Memory Usage”直接放进 Performance Monitor 的硬件兼容性测试中，这个说法也需要修正。 现代 Windows GPU 监控涉及 Windows GPU Performance Counters、GPU Engine、Video Decode、Video Encode、Dedicated GPU Memory、Shared GPU Memory 等不同指标。 而且 GPU 使用率本身也需要结合具体 Engine 判断。 例如一个应用可能主要占用 3D Engine，另一个应用可能主要使用 Video Decode 或 Compute Engine。 因此安装显卡以后，如果目标是验证显卡是否工作正常，应该结合设备管理器、GPU-Z、HWiNFO、事件查看器以及实际负载测试。 Performance Monitor 可以提供部分系统级性能数据，但不能替代显卡诊断工具。 新硬件稳定性不能靠性能监视器证明 安装显卡、SSD、内存或者其他硬件以后，Performance Monitor 可以帮助观察系统负载和资源行为，但不能单独证明硬件“兼容”。 例如新显卡运行正常，不代表显卡 VRAM、PCIe 链路和供电系统已经通过完整稳定性验证。 如果出现 WHEA 错误、驱动重置、黑屏或者高负载重启，需要结合事件查看器、硬件监控和压力测试进一步分析。 内存稳定性需要独立内存测试。 SSD 健康需要 SMART/NVMe Health 和厂商工具。 显卡稳定性需要结合 GPU 压力测试、VRAM 测试、温度、电压、功耗和事件日志。 电源问题则可能需要示波器和交叉替换电源进一步确认。 Performance Monitor 在这里主要负责观察系统层面的表现，而不是替所有硬件诊断工具完成工作。 一个更适合进阶用户的诊断流程 遇到 Windows 11 性能异常时，可以按照故障持续时间选择工具。 如果问题正在发生，可以先用任务管理器和资源监视器快速定位。 如果问题偶发，需要提前启动 Performance Monitor 或 Data Collector Set 进行持续采样。 如果发现明显的 CPU、内存、磁盘或者网络异常，再针对具体资源建立更详细的计数器。 如果资源计数器没有解释问题，则进入事件查看器、WHEA、驱动日志和应用程序日志。 如果仍然无法定位，再使用 WPR/WPA、ETW、WinDbg 或专业硬件诊断工具。 这套方法比单纯盯着一个“CPU 80%”或者“磁盘队列2”更加可靠。 Windows 11 性能监视器真正有价值的地方，并不是给用户提供几个漂亮的实时曲线，而是让系统运行状态变成可以持续记录、比较和分析的数据。 性能问题往往不是一个数字突然超过某个所谓“危险线”这么简单。CPU 高负载可能是正常工作，内存使用量高可能是正常缓存，磁盘队列增加可能是正常并发 I/O，网络连接增加也可能只是正常业务增长。 进阶诊断的核心，是观察这些指标之间的关系，以及它们与故障发生时间之间的关系。 当 Performance Monitor、Resource Monitor、Task Manager、Event Viewer、WPR/WPA、WinDbg 和硬件监控工具各自承担合适的任务时，Windows 11 的性能问题才能从“感觉很卡”逐渐变成可以复现、采集、比较和验证的工程问题。