1. 性能监控这件事为什么值得单独拎出来讲做系统运维和性能调优这些年我越来越觉得perfmon这个工具被严重低估了。很多人一提到性能分析第一反应就是上各种花哨的APM平台、分布式追踪系统觉得那些可视化大屏才叫专业。但真到了线上出问题、需要快速定位瓶颈的时候往往还是得回到操作系统自带的基础工具上来。perfmon就是Windows平台上那个最基础、最可靠、也最容易被忽视的性能监控利器。它到底是什么简单说perfmon是Windows系统内置的性能监视器全称Performance Monitor。它能做的事情非常实在实时采集CPU、内存、磁盘、网络、进程等各个维度的性能计数器数据把数据记录下来做趋势分析还能设置阈值告警。你不需要装任何第三方软件不需要额外授权打开就能用。对于运维工程师、后端开发、数据库管理员甚至是对自己电脑性能有追求的重度用户来说这都是一个必须掌握的技能。我见过太多场景一个服务响应变慢大家第一反应是去翻应用日志结果日志里什么异常都没有。这时候如果有人能打开perfmon看一眼可能五分钟就发现是磁盘队列长度爆了或者某个进程的内存工作集在持续增长导致频繁换页。性能问题的根因往往不在应用层而在系统资源层。perfmon就是帮你看到这一层的那双眼睛。这篇文章我打算把perfmon从打开到用明白的完整路径讲清楚。包括怎么选计数器、怎么读懂数据、怎么用数据日志做离线分析、怎么设置数据收集器集以及我在实际排查中踩过的那些坑。不管你是刚接触性能监控的新手还是已经用过但总觉得没抓到重点的老手应该都能从里面找到有用的东西。2. 核心概念拆解计数器、对象与实例到底是什么关系2.1 性能计数器的三层结构perfmon的数据模型其实不复杂但很多人第一次打开界面就被那一长串列表搞晕了。它的结构是三层性能对象、计数器、实例。打个比方你可以把性能对象理解成一个大类比如Processor处理器、Memory内存、PhysicalDisk物理磁盘、Network Interface网络接口。每个大类下面有多个指标也就是计数器。比如Processor对象下面有% Processor Time处理器时间百分比、Interrupts/sec每秒中断数等。而实例则是当同一个对象有多个具体实体时用来区分的比如你有4个逻辑核心Processor对象就会有0、1、2、3四个实例还有一个_Total表示总体。这个三层结构在添加计数器的时候体现得特别明显。你点添加按钮先选性能对象再选计数器如果这个对象有多个实例还要选实例。很多人图省事直接选_Total但**_Total有时候会掩盖单个实例的异常**。比如4个核心里有1个核心跑满_Total可能只显示25%看起来一切正常实际上那个核心上的线程已经在排队了。2.2 常用性能对象速查我把日常排查中最常用的几个对象和计数器整理了一下这些是真正能帮你定位问题的核心指标性能对象关键计数器说明正常范围参考Processor% Processor TimeCPU总体使用率持续低于80%Processor% Privileged Time内核态CPU时间占比一般低于30%SystemProcessor Queue Length处理器队列长度持续小于核心数MemoryAvailable MBytes可用物理内存不低于总内存10%MemoryPages/sec每秒换页次数持续低于几百PhysicalDiskAvg. Disk Queue Length平均磁盘队列长度持续小于2PhysicalDisk% Disk Time磁盘忙碌时间占比持续低于80%Network InterfaceBytes Total/sec网络总吞吐对比网卡带宽这张表建议你存下来排查的时候对着看。Processor Queue Length和Avg. Disk Queue Length这两个队列指标是我个人认为最能反映系统真实压力的。CPU使用率高不一定有问题但如果队列长度持续超过核心数说明请求已经在排队了用户体验必然下降。2.3 实时监控与数据日志的区别perfmon有两种工作模式很多人只知道第一种。实时监控就是打开界面直接看曲线适合现场快速判断。但实时监控有个致命问题它只能看当前你没法回放。问题发生的那一瞬间你没盯着屏幕就错过了。数据日志才是perfmon真正强大的地方。你可以创建一个数据收集器集让它后台持续记录性能数据到文件出问题的时候再打开日志回放分析。我现在的习惯是但凡要排查一个偶发性的性能问题第一件事就是先架一个数据收集器集跑起来等复现了再去看日志。这样你抓到的是问题发生时的真实数据而不是事后凭感觉猜。提示实时监控的采样间隔默认是1秒数据日志可以设置更细或更粗。排查短时尖刺用1秒甚至更细做长期趋势分析用15秒到60秒就够了否则日志文件会大得吓人。3. 从零开始手把手搭建一个可用的监控环境3.1 打开perfmon的正确姿势最直接的方式是WinR输入perfmon回车。但我更推荐用命令行方式因为可以带参数直接打开数据收集器集。在CMD或PowerShell里输入perfmon /res这个/res参数会直接打开资源视图比默认界面更直观。另外还有一个perfmon /report命令它会自动采集60秒的系统数据然后生成一份完整的诊断报告包含硬件配置、诊断结果、CPU/内存/磁盘/网络的分析。这个命令特别适合快速给一台陌生服务器做体检一条命令下去等一分钟报告就出来了。不过要注意/report生成的报告是HTML格式的里面有些建议可能比较通用不要完全照搬要结合实际情况判断。3.2 创建数据收集器集的完整步骤数据收集器集是perfmon做持续监控的核心。我以排查一个服务间歇性变慢的问题为例走一遍完整流程。第一步在perfmon左侧导航栏展开数据收集器集右键用户定义选择新建-数据收集器集。给它起个名字比如PerfCheck_WebServer选择手动创建下一步。第二步选择创建数据日志勾选性能计数器和系统配置信息后者会记录硬件和软件配置方便对比。下一步。第三步添加计数器。这里有个技巧不要贪多。我见过有人一口气加几十个计数器结果日志文件巨大分析的时候反而找不到重点。针对服务变慢的场景我一般先加这几组Processor% Processor Time、% Privileged Time、% Interrupt TimeSystemProcessor Queue Length、Context Switches/secMemoryAvailable MBytes、Pages/sec、Pool Nonpaged BytesPhysicalDiskAvg. Disk Queue Length、Avg. Disk sec/Read、Avg. Disk sec/Write目标进程% Processor Time、Working Set、Private Bytes采样间隔设为5秒。这个间隔对于排查分钟级的性能波动足够了日志大小也可控。第四步设置输出位置。默认在C:\PerfLogs\Admin\下面你可以改到空间充足的盘。文件格式选二进制.blg比CSV紧凑得多而且perfmon可以直接打开回放。第五步选择保存并关闭然后右键这个收集器集选择开始。它会立刻开始后台记录。等你的问题复现之后右键选择停止然后就可以打开日志分析了。3.3 用命令行自动化采集如果你需要在多台机器上批量部署监控图形界面就太慢了。perfmon支持通过logman命令行工具来创建和管理数据收集器集。比如创建一个采集CPU和内存的收集器logman create counter PerfCheck_CPU -c \Processor(_Total)\% Processor Time \Memory\Available MBytes -si 00:00:05 -o C:\PerfLogs\cpu_mem.blg -f bincirc -max 500这条命令的意思是创建一个叫PerfCheck_CPU的计数器收集器采集总CPU使用率和可用内存采样间隔5秒输出到指定blg文件使用循环二进制格式最大500MB。-f bincirc这个循环格式很实用它会在文件达到上限后自动覆盖最旧的数据适合长期运行不用担心磁盘被撑爆。启动和停止的命令分别是logman start PerfCheck_CPU logman stop PerfCheck_CPU用命令行还有一个好处就是可以把这些命令写进脚本配合计划任务实现定时采集。比如每天业务高峰期自动采集两小时其他时间停止既拿到了关键数据又节省了资源。4. 读懂数据性能指标背后的真实含义4.1 CPU相关指标的深度解读CPU使用率高这是最常被报告的问题但高本身不是问题持续高且伴随队列增长才是问题。我判断CPU是否真的成为瓶颈会看三个指标的组合% Processor Time、Processor Queue Length、% Privileged Time。% Processor Time持续超过80%说明CPU确实忙。但如果Processor Queue Length一直小于逻辑核心数说明请求还能及时被处理不一定需要立即扩容。反过来如果队列长度持续大于核心数的两倍那即使CPU使用率只有60%也说明调度已经出现明显延迟了。% Privileged Time这个指标特别值得关注。它表示CPU花在内核操作上的时间比例。正常情况下这个值应该比较低如果它持续超过30%甚至更高往往意味着有大量的系统调用、驱动问题或者硬件中断在处理。我曾经遇到过一个案例一台服务器的% Privileged Time异常高最后查出来是某个网卡驱动版本有缺陷导致中断风暴。这种问题在应用层是永远查不出来的。还有一个容易被忽略的指标是Context Switches/sec每秒上下文切换次数。这个值没有绝对的标准但如果你发现它比平时高出一个数量级同时系统响应变慢那可能是线程锁竞争激烈或者有进程在频繁创建销毁线程。4.2 内存指标Available MBytes与Pages/sec的配合内存排查的核心逻辑是看可用内存是否充足看是否发生了频繁换页。Available MBytes表示当前可用的物理内存量。这个值如果持续低于总内存的10%系统就开始有压力了。但光看这个还不够因为Windows会尽量利用空闲内存做缓存Available低不一定代表有问题。真正的关键指标是Pages/sec。它表示每秒从磁盘读取或写入页面的次数也就是换页频率。当物理内存不够时系统会把不常用的内存页写到磁盘的页面文件里需要时再读回来。这个过程涉及磁盘IO速度比内存慢几个数量级。Pages/sec持续超过几百就说明系统在频繁换页性能必然受影响。我一般会把Available MBytes和Pages/sec放在同一个视图里对比看。如果Available低但Pages/sec也低说明内存虽然用得满但还没到换页的程度可以继续观察。如果Available低且Pages/sec高那就是明确的内存不足信号需要考虑加内存或者排查内存泄漏。排查内存泄漏的时候我会重点看目标进程的Private Bytes和Working Set。Private Bytes表示进程独占的虚拟内存Working Set表示进程实际占用的物理内存。如果Private Bytes持续增长且不回落基本可以确定有泄漏。4.3 磁盘指标队列长度和响应延迟磁盘往往是整个系统中最慢的一环也是最容易成为瓶颈的地方。判断磁盘是否过载我主要看两个指标Avg. Disk Queue Length和Avg. Disk sec/Transfer。Avg. Disk Queue Length表示平均有多少个IO请求在排队等待磁盘处理。对于单块机械硬盘这个值持续超过2就说明磁盘忙不过来了。对于SSD可以适当放宽但持续超过4也应该警惕。如果是RAID阵列判断标准要乘以阵列中的物理磁盘数量比如4块盘的RAID 10队列长度持续超过8才需要关注。Avg. Disk sec/Transfer表示平均每次IO传输的耗时。这个指标直接反映了用户感受到的磁盘延迟。机械硬盘正常在10ms以内SSD应该在1ms以内。如果这个值飙升到几十甚至上百毫秒那应用层的任何数据库查询、文件读写都会变得极其缓慢。注意PhysicalDisk对象下的_Total实例是所有物理磁盘的汇总但如果你用的是RAID看到的可能是逻辑卷。排查的时候要具体到单块物理磁盘才能定位到是哪块盘出了问题。4.4 网络指标不要只看吞吐量网络排查很多人只看Bytes Total/sec觉得没跑满带宽就没问题。但实际上网络问题更多时候不是带宽不够而是延迟高或者丢包。perfmon里网络相关的计数器相对有限但有几个值得关注Bytes Total/sec看总吞吐Packets/sec看包速率Packets Outbound Errors和Packets Received Errors看错误包数量。如果错误包数量持续增长说明网卡、驱动或者链路有问题。另外TCP相关的计数器在TCPv4对象下面比如Segments Retransmitted/sec每秒重传段数。重传率高说明网络质量差即使带宽没用满应用层的体验也会很差。5. 实战排查三个典型性能问题的完整分析过程5.1 案例一Web服务响应时间间歇性飙升之前遇到过一个问题一个Web服务平时响应很快但每隔十几分钟就会出现几秒钟的响应时间飙升。应用日志里没有任何异常GC日志也正常。我的处理方式是先架了一个数据收集器集采集了CPU、内存、磁盘和网络的核心指标采样间隔设为1秒跑了大概一个小时抓到了几次响应飙升的时间点。打开日志回放把时间轴定位到响应飙升的那几秒发现一个很明显的模式每次飙升的时候PhysicalDisk的Avg. Disk Queue Length都会从接近0跳到5以上同时Avg. Disk sec/Write从几毫秒跳到几十毫秒。而CPU和内存指标完全正常。这就把方向指向了磁盘IO。进一步排查发现这台服务器上还有一个定时任务每隔十几分钟会批量写入一批日志文件。这个写入操作本身数据量不大但它触发了磁盘的写缓存刷盘导致其他IO请求被阻塞。解决办法也很简单把那个定时任务的写入时间打散或者换到另一块物理磁盘上。问题解决。如果没有perfmon的数据日志这种间歇性问题靠猜是永远猜不到的。5.2 案例二进程内存持续增长但不下落另一个案例是一个后台服务运行几天后内存占用越来越高最终被系统杀掉重启。应用本身的监控只显示了进程的Working Set在增长但看不出原因。我用perfmon加了几个计数器Process对象的Private Bytes、Working Set、Handle Count、Thread Count还有.NET CLR Memory相关的计数器因为这个服务是.NET写的。采集了一天的数据。回放日志发现Private Bytes和Working Set确实在持续增长但Handle Count和Thread Count保持稳定。这说明不是句柄泄漏或线程泄漏而是纯粹的内存分配没有释放。再结合.NET CLR的Gen 2堆大小和GC回收次数发现Gen 2堆持续增长且GC回收后回落很少基本确定是托管内存泄漏。后来通过分析内存转储找到了问题代码是一个静态字典只增不减。这个案例里perfmon的作用是快速缩小了排查范围从内存涨了缩小到是托管内存泄漏而不是非托管资源泄漏省了大量时间。5.3 案例三CPU使用率不高但系统卡顿这个案例比较反直觉。一台服务器CPU使用率只有40%左右内存也充足磁盘也不忙但用户就是感觉卡。我加了Processor Queue Length和Context Switches/sec这两个计数器。结果发现Processor Queue Length持续在10以上那台机器是4核Context Switches/sec也异常高。这说明CPU虽然没跑满但线程调度非常频繁大量时间花在了上下文切换上。进一步用Process对象的Thread Count和% Processor Time per Thread排查发现某个进程创建了大量线程这些线程在频繁地争抢锁。这种问题的根因不在资源不足而在程序设计。解决办法是优化那个进程的并发模型减少线程数量和锁竞争。如果只看CPU使用率这个问题永远发现不了。6. 进阶技巧与常见问题排查6.1 用数据收集器集模板提高效率如果你经常需要排查同类问题每次都手动添加计数器太浪费时间。perfmon支持把配置好的数据收集器集导出为模板文件XML格式下次直接导入就能用。操作方法是右键已经配置好的数据收集器集选择导出模板保存为XML文件。需要的时候右键用户定义选择新建-从模板创建导入那个XML就行。我自己的习惯是维护几个模板一个基础体检模板包含CPU、内存、磁盘、网络的核心指标一个SQL Server排查模板包含SQL Server相关的计数器一个ASP.NET应用模板包含CLR相关的计数器。用的时候直接导入省去了每次选计数器的麻烦。6.2 常见问题速查表现象可能原因重点查看的计数器排查方向系统整体卡顿CPU调度瓶颈Processor Queue Length、Context Switches/sec检查线程数和锁竞争应用响应慢但CPU不高磁盘IO瓶颈Avg. Disk Queue Length、Avg. Disk sec/Transfer检查磁盘负载和IO模式内存持续增长内存泄漏Private Bytes、Working Set、Handle Count区分托管和非托管泄漏服务间歇性超时资源争抢全指标对比时间轴找时间相关性网络传输慢网络质量差Segments Retransmitted/sec、Packets Errors检查链路和驱动系统启动后越来越慢内存换页Available MBytes、Pages/sec考虑加内存或优化内存使用6.3 几个容易踩的坑第一个坑是采样间隔设置不当。间隔太长会漏掉短时尖刺间隔太短会导致日志文件过大且采集本身消耗资源。我的经验是排查已知的间歇性问题用1秒做长期趋势监控用15到60秒不确定的时候先用5秒跑一段时间看看。第二个坑是只看平均值不看峰值。perfmon默认显示的是平均值但很多性能问题恰恰出在峰值上。你可以在图表上右键选择显示-最大值或最小值或者直接在数据属性里切换。我一般会同时看平均值和最大值如果最大值远高于平均值说明存在尖刺。第三个坑是忽略了_Total和单实例的区别。前面提过多核心CPU只看_Total会掩盖单核心过载。多块磁盘只看_Total会掩盖单块盘的问题。排查的时候一定要展开到具体实例。第四个坑是采集了数据但没采集系统配置信息。系统配置信息包括硬件配置、驱动版本、运行的软件等。没有这些信息你事后分析的时候可能无法解释某些数据变化。比如驱动更新可能导致某个计数器行为改变如果没有记录就无从对比。6.4 性能基线的建立最后想强调一点性能分析最怕的是没有基线。你不知道系统正常的时候是什么样就无法判断现在是否异常。我的做法是对于重要的服务器在业务低峰期采集一段时间的性能数据作为基线。记录下CPU、内存、磁盘、网络各项指标的正常范围。以后出问题的时候直接和基线对比异常一目了然。基线不需要很复杂用数据收集器集跑一天采样间隔30秒然后把关键指标的平均值和峰值记下来就行。这个工作一次投入长期受益。提示基线不是一成不变的。业务量增长、软件版本更新、硬件变更之后都需要重新采集基线。我一般每季度更新一次或者在重大变更之后立即更新。7. 我个人的一些使用体会perfmon这个工具我用了很多年最大的感受是它不花哨但足够可靠。它不会给你自动分析出根因但它会老老实实把所有的原始数据摆在你面前让你自己去发现规律。这种笨工具在关键时刻往往比那些智能平台更管用因为你知道数据是怎么来的你信任它。另外一个体会是性能分析这件事工具只占三成经验占七成。同样的计数器数据有经验的人一眼就能看出问题在哪没经验的人看半天也找不到重点。而经验这东西只能靠一次次实际排查积累。perfmon就是积累经验的好帮手因为它让你能看到系统内部的真实运行状态而不是停留在应用层的表象。如果你还没认真用过perfmon我建议你找一台测试机按照上面的步骤搭一个数据收集器集跑上一天然后打开日志仔细看看那些曲线。你会发现原来系统内部有这么多故事在发生。