Windows服务性能监控需区分瞬时抖动与持续瓶颈，结合IIS、SQL Server、SMB等服务类型选择业务相关指标：CPU要分层看Processor Queue Length（>2即调度饱和）、进程级% Processor Time及Privileged Time（>30%提示内核异常）；延迟需按协议栈定位，如SMB关注Work Requests Queued与Output Queue Length，SQL Server侧重Page life expectancy（>300秒）和Wait Statistics；必须建立3–5日基线并设P95动态阈值，警惕CPU低但延迟高的伪低负载陷阱。
windows 服务性能监控不能只看 cpu 占用率或平均延迟数字，关键在于区分“瞬时抖动”和“持续瓶颈”，并结合服务类型（如 iis、sql server、smb 文件服务）选择有业务意义的指标组合。
CPU 相关指标要分层看
单纯看 \Processor(_Total)\% Processor Time 容易误判。高占用未必是问题，低占用也可能隐藏调度阻塞：
- System\Processor Queue Length：反映就绪线程排队等待 CPU 的数量。持续 > 2 表明 CPU 调度已饱和，即使 CPU 使用率只有 60%，服务响应也会变慢
- \Process(*)\% Processor Time（指定服务进程名，如 w3wp、sqlservr）：确认是哪个进程在消耗 CPU，避免被系统空闲线程或后台任务干扰判断
- \Processor Information(*)\% Privileged Time：若该值长期 > 30%，说明内核态开销大，可能与驱动异常、病毒扫描、过度日志写入有关
延迟指标必须绑定服务上下文
“Latency”不是单一计数器，需按协议栈层级定位：
- SMB 场景：关注 Server\Bytes Total/sec + Server\Work Requests Queued + Network Interface(*)\Output Queue Length。当队列长度 > 5 且延迟升高，说明 SMB 请求堆积，而非磁盘慢
- HTTP/ASP.NET：依赖 IIS 日志或 .NET CLR Memory(*)\% Time in GC 和 Web Service(*)\Get Requests/sec。GC 时间占比 > 10% 会直接拖慢请求响应
- SQL Server：不用看 SQLServer:SQL Statistics\Batch Requests/sec 单独值，而要看 SQLServer:Buffer Manager\Page life expectancy（应 > 300 秒）+ SQLServer:Wait Statistics\Average Wait Time (ms)（重点看 PAGEIOLATCH_XX、ASYNC_NETWORK_IO）
采样与基线缺一不可
实时图表只能发现“正在发生什么”，无法判断“是否异常”。必须建立基线：
- 用 PerfMon 创建数据收集器集，采样间隔设为 15 秒（尤其对文件/数据库服务），保存为 .blg 格式
- 连续采集 3–5 个工作日，覆盖业务高峰与低谷，导出后用 Excel 或 Power BI 计算各指标 P95 延迟、平均队列长度、CPU 空闲时间下限
- 把基线值设为告警阈值——例如 SMB 队列长度 P95 是 3，则告警线设为 8；而不是固定写死“>5 就告警”
别忽略“伪低负载”陷阱
有些服务 CPU 占用常年低于 10%，但延迟飙升。常见原因：
- 进程被挂起（\Process(*)\Thread Count 突降 + \Process(*)\Handle Count 持续高位）
- 等待外部依赖（如 DNS 超时、LDAP 连接池耗尽），此时 \Process(*)\Elapsed Time 会远大于 \Process(*)\Processor Time
- NUMA 节点内存访问不均（多路服务器上），表现为 Memory\Pages/sec 正常但 Memory\Available MBytes 局部节点耗尽
