使用performancecounter获取磁盘读写速度需指定"physicaldisk"类别、"bytes read/sec"或"bytes written/sec"计数器及"_total"等有效实例名，调用nextvalue()两次（间隔≥1秒）才能获得准确字节/秒值；avg. disk queue length计数器反映平均等待请求数，持续>2（hdd）或>1（ssd）提示i/o瓶颈，同样需两次采样。
如何用 PerformanceCounter 获取磁盘读写速度（Bytes/sec）
Windows 系统自带的 PerformanceCounter 类可直接读取磁盘 I/O 速率，无需驱动或第三方库。关键在于选对性能对象（PhysicalDisk）和计数器（Bytes Read/sec、Bytes Written/sec），且必须使用实例名（如 _Total 或具体磁盘编号 0 C:）。
常见错误是直接用 "PhysicalDisk" 不带实例名，导致抛出 InvalidOperationException: Instance 'xxx' does not exist。正确做法是先枚举可用实例，或明确指定 _Total（聚合所有物理磁盘）：
var readCounter = new PerformanceCounter("PhysicalDisk", "Bytes Read/sec", "_Total");
var writeCounter = new PerformanceCounter("PhysicalDisk", "Bytes Written/sec", "_Total");
// 调用 NextValue() 两次，间隔至少 1 秒才有有效值
readCounter.NextValue(); // 第一次调用仅初始化
System.Threading.Thread.Sleep(1000);
float bytesReadPerSec = readCounter.NextValue(); // 单位：字节/秒
-
NextValue()必须调用两次，首次返回 0 或无效值，第二次才给出真实速率 - 若监控单个磁盘（如 C:），需先查实例名：
PerformanceCounterCategory.GetCategories().FirstOrDefault(c => c.CategoryName == "PhysicalDisk")?.GetCounters()，再找含C:的实例 - 返回值为
float，单位是字节/秒；除以 1024² 可转 MB/s
如何监控磁盘队列长度（Avg. Disk Queue Length）
Avg. Disk Queue Length 表示等待磁盘处理的平均请求数（含正在服务的），是判断 I/O 瓶颈的核心指标。它属于同一 PhysicalDisk 类别，但语义与吞吐量不同：持续 > 2 通常意味着磁盘饱和（尤其在 HDD 上）。
注意该计数器是“平均值”，需采样周期足够长才能稳定，不能靠单次 NextValue() 判断：
var queueCounter = new PerformanceCounter("PhysicalDisk", "Avg. Disk Queue Length", "_Total");
queueCounter.NextValue();
Thread.Sleep(1000);
float avgQueue = queueCounter.NextValue(); // 典型安全阈值：HDD ≤ 2，SSD ≤ 1
- 该值不是瞬时快照，而是采样窗口内的滑动平均，依赖系统 PerfMon 计算逻辑
- 若值长期为 0，可能是计数器未启用——需确认“Windows Management Instrumentation”服务已运行，且用户有
Performance Monitor Users组权限 - SSD 场景下队列长度普遍更低，>1 就值得警惕；而 RAID 阵列可能天然拉高该值，需结合吞吐量交叉分析
为什么第一次读数总是 0 或异常？
PerformanceCounter 的设计机制决定：首次 NextValue() 仅采集基准时间戳和原始计数，不计算差值。第二次调用才用新旧差值除以时间差得出速率。跳过首调直接用第二次结果，会得到上一次残留数据或 0。
- 必须严格遵循“调用 → 等待 ≥1s → 再调用”流程，硬编码
Sleep(1000)最稳妥 - 不要用
Console.WriteLine(counter.NextValue())连续打印两次——中间没延时，第二值仍是无效的 - 若需高频采样（如每 500ms），应启动后台线程持续调用
NextValue()并缓存最近两个值，自行计算 Δt 和 Δvalue - 进程退出前务必调用
counter.Close()和counter.Dispose()，否则句柄泄漏可能导致后续创建失败
实际部署时权限和兼容性问题
在 Windows Server 或非管理员账户下，PerformanceCounter 常因权限不足静默失败（不抛异常，但 NextValue() 返回 0）。这不是代码 bug，而是系统策略限制。
- 开发机默认允许，但生产环境需将运行用户加入
Performance Monitor Users本地组（而非仅 Administrators） - .NET Core/.NET 5+ 在 Windows 上完全支持
PerformanceCounter，但 Linux/macOS 不支持——跨平台方案需改用System.IO.Ports或 WMI（ManagementObjectSearcher） - WMI 查询更灵活（如过滤特定磁盘），但性能开销大、延迟高，不适合实时监控；
PerformanceCounter是唯一低开销原生方案 - 若程序以服务方式运行，确保服务登录身份具备上述性能监视权限，而非默认 Local System
真正难的不是读取数值，而是理解 Avg. Disk Queue Length 和 Bytes/sec 的耦合关系：高吞吐伴随高队列说明磁盘在全力响应；高队列却低吞吐，则大概率是随机小 IO 或锁竞争——这时候看计数器只是起点，得接着查 Split IO/sec 或用 xperf 定位源头。
