Windows 服务性能指标监控（Latency/CPU）

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 容易误判。高占用未必是问题，低占用也可能隐藏调度阻塞：

• SystemProcessor Queue Length：反映就绪线程排队等待 CPU 的数量。持续 > 2 表明 CPU 调度已饱和，即使 CPU 使用率只有 60%，服务响应也会变慢
• Process(*)% Processor Time（指定服务进程名，如 w3wp、sqlservr）：确认是哪个进程在消耗 CPU，避免被系统空闲线程或后台任务干扰判断
• Processor Information(*)% Privileged Time：若该值长期 > 30%，说明内核态开销大，可能与驱动异常、病毒扫描、过度日志写入有关

延迟指标必须绑定服务上下文

“Latency”不是单一计数器，需按协议栈层级定位：

• SMB 场景：关注 ServerBytes Total/sec + ServerWork 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 StatisticsBatch Requests/sec 单独值，而要看 SQLServer:Buffer ManagerPage life expectancy（应 > 300 秒）+ SQLServer:Wait StatisticsAverage 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 节点内存访问不均（多路服务器上），表现为 MemoryPages/sec 正常但 MemoryAvailable MBytes 局部节点耗尽