Windows SMB性能监控需聚焦客户端行为、协议层表现和底层资源瓶颈三层：首选SMB Client Shares与Network Interface计数器，如Server Response Time（>50ms局域网需排查）、Read/Write Bytes/sec（对比预配吞吐），并同步观察CPU（% Processor Time>85%）、内存（Available MBytes<10%）、磁盘延迟（Avg. Disk sec/Read>15ms）及网络接口指标，云环境需叠加Azure FileShares服务端指标交叉验证。
windows 环境下做文件共享性能监控，核心目标是定位延迟高、吞吐低、连接不稳定等问题。指标选取不能堆数量，而要聚焦客户端行为、协议层表现和底层资源瓶颈三个层面，兼顾可采集性与诊断指向性。
SMB 客户端性能计数器是首选指标来源
Windows 内置 SMB 客户端驱动（SMB Direct、SMB 3.x）暴露了完整性能计数器，无需安装额外代理。关键对象是 SMB Client Shares 和 SMB Client Network Interface：
-
SMB Client Shares\Read Bytes/sec和Write Bytes/sec：反映实际业务吞吐，单位为字节/秒。若远低于共享预配吞吐（如 Azure File Share 的FileShareProvisionedThroughputMiBps），说明应用或网络未打满带宽。 -
SMB Client Shares\Read Operations/sec和Write Operations/sec：衡量 I/O 并发强度。结合平均读写大小（可用SMB Client Shares\Average Read Bytes计算），可判断是否因小 IO 导致延迟升高。 -
SMB Client Shares\Server Response Time：单位毫秒，直接体现端到端延迟。持续 >50ms（局域网）或 >200ms（跨公网）需排查网络抖动、服务端排队或客户端重试。 -
SMB Client Shares\Connection Failures/sec和Session Failures/sec：异常连接中断的信号，常关联防火墙拦截、认证失败或服务端负载过载。
系统级基础指标必须同步观察
单看 SMB 计数器容易误判，需绑定底层资源状态交叉验证：
-
Processor(_Total)\% Processor Time：若长期 >85%，SMB 客户端处理（加密、签名、重定向）可能成为瓶颈，尤其启用 SMB 3.1.1 加密时。 -
Memory\Available MBytes：低于物理内存 10% 时，系统频繁换页会拖慢 SMB 缓存（如SMB Client Shares\Cache Hit Ratio下降）。 -
PhysicalDisk(_Total)\Avg. Disk sec/Read和Avg. Disk sec/Write：>15ms 表示本地磁盘响应慢，会影响 SMB 客户端缓存写入或脱机文件同步。 -
Network Interface(*)\Bytes Total/sec：对比 SMB 实际吞吐，确认是否被网卡或 TCP 栈限制（如接收窗口不足、丢包）。
Azure 文件共享等云服务需补充平台指标
若共享托管在 Azure，务必拉取 Microsoft.FileShares/fileShares 的服务端指标作对照：
-
FileCapacity和FileCount：突增可能触发存储分片调整，引发临时延迟。 -
FileShareSnapshotSize：快照占用空间过大时，会影响写入性能（尤其启用了写时复制）。 -
FileShareProvisionedIOPSCount：客户端观测到高延迟但服务端 IOPS 未达上限，说明问题在客户端或网络；若已达上限，则需扩容。
指标采集建议用 Perfmon 创建数据收集器集，保存为 BLG 格式，避免日志轮转丢失关键窗口。重点不是看单点峰值，而是关注 Server Response Time 与 Connection Failures/sec 是否存在时间相关性——这能快速区分是网络抖动、服务端故障还是客户端配置问题。
