windows性能计数器是一套面向诊断的数据采集体系，核心价值在于指标可解释、行为可归因、瓶颈可定位；需结合processor queue length、pages/sec、page reads/sec、avg. disk sec/read等关键计数器综合分析cpu、内存、磁盘及进程级问题。
windows 性能计数器不是“高级任务管理器”，而是一套内建的、面向诊断的数据采集体系。它不靠界面炫酷取胜，靠的是指标可解释、行为可归因、瓶颈可定位——真正帮你回答“为什么慢”，而不是只告诉你“它在忙”。
CPU 负载不能只看百分比
Processor(_Total)\% Processor Time 高，不代表一定出问题；低，也不代表一切正常。关键要看线程是否在排队等待调度：
- System\Processor Queue Length：就绪态线程数。持续大于（逻辑处理器数 + 1）即存在真实CPU争用，哪怕% Processor Time只有60%
- 搭配观察 Context Switches/sec：若队列长但上下文切换频次低，可能是I/O阻塞或锁等待；若两者都高，更倾向线程调度过载或应用并发失控
- 单核虚拟机上该值 > 2、4核物理机上 > 5，就该介入排查，而非等CPU打满才行动
内存压力藏在“可用”与“换页”之间
Memory\Available MBytes 低于500MB只是预警信号，必须结合 Memory\Pages/sec 和 Memory\Page Reads/sec 才能定性：
- Available MBytes 低 + Pages/sec
- Available MBytes 低 + Pages/sec > 1000 + Page Reads/sec > 50 → 硬缺页频繁，磁盘正在替内存打工，I/O延迟大概率同步升高
- Page Reads/sec 单独突破100/sec，即使内存充足，也提示某进程反复触发未缓存数据加载（如数据库扫描未走索引）
磁盘响应时间比吞吐量更能暴露瓶颈
PhysicalDisk(_Total)\Avg. Disk sec/Read 和 \Avg. Disk sec/Write 是黄金指标，单位是秒，不是毫秒：
- > 0.02s（20ms）：用户已可感知卡顿；数据库写入 > 0.015s 就需关注
- Avg. Disk Queue Length > 2 仅作辅助参考：若延迟正常，可能是短时并发高；若延迟也高，基本确认I/O子系统饱和
- 不要只盯“% Disk Time”——SSD下该值常接近100%，但延迟仍很低，它已失去参考价值
进程级内存泄漏有迹可循
Process(YourApp)\Private Bytes 是识别原生或托管内存泄漏最直接的计数器：
- 随时间持续、近似线性增长，且服务重启后归零 → 高度疑似内存泄漏
- 缓慢上升后稳定在平台期 → 更可能是JVM堆预分配、.NET GC代际策略或大对象堆（LOH）自然驻留，属合理行为
- 对比 Process(YourApp)\Working Set：若Private Bytes涨而Working Set不涨，说明内存已提交但未实际使用（常见于malloc未free或GC未触发）
