# 在 Windows Server 2022 下测试硬盘 IOPS
在 **Windows Server 2022** 下测试硬盘 **IOPS**，最专业、最常用的是用微软官方工具 **DiskSpd**。下面给你一份**直接可用的命令集合**，适合真实服务器场景。
---
## 一、推荐工具：DiskSpd（微软官方）
下载地址（官方）：
- DiskSpd
（你可以从微软 GitHub 搜索 “DiskSpd” 下载）
解压后假设路径为：
```text
C:\diskspd\diskspd.exe
```
---
## 二、新建一个测试文件（非常重要）
先准备一个测试文件，比如 10GB：
```powershell
fsutil file createnew D:\iops_test.dat 10737418240
```
---
## 三、随机读 IOPS 测试命令（最常用）
### 1. 4K 随机读（典型数据库负载）
```powershell
Cd e:\soft\diskspd\
./diskspd.exe -b4K -r -o32 -t4 -d30 -Sh -L D:\iops_test.dat
```
参数说明：
| 参数 | 说明 |
|---|
| `-b4K` | 块大小 4KB |
| `-r` | 随机 IO |
| `-o32` | 队列深度 32 |
| `-t4` | 4 线程 |
| `-d30` | 测试 30 秒 |
| `-Sh` | 禁用系统缓存 |
| `-L` | 显示延迟统计 |
---
### 2. 4K 随机写 IOPS
```powershell
C:\diskspd\diskspd.exe ^
-b4K -r -w100 -o32 -t4 -d30 -Sh ^
-L D:\iops_test.dat
```
---
## 四、顺序读写吞吐测试
### 1. 顺序读（大文件）
```powershell
C:\diskspd\diskspd.exe ^
-b1M -s -o4 -t2 -d30 -Sh ^
-L D:\iops_test.dat
```
### 2. 顺序写
```powershell
C:\diskspd\diskspd.exe ^
-b1M -s -w100 -o4 -t2 -d30 -Sh ^
-L D:\iops_test.dat
```
---
## 五、如何看 IOPS 结果
主要看结果中的这一行：
```text
total IO
```
示例结果：
```text
total IO
IO/s: 85234
MB/s: 333.1
AvgLat: 0.45ms
```
其中：
- **IO/s → 就是 IOPS**
- **AvgLat → 平均延迟**
---
## 六、简单对照参考值
| 存储类型 | 大概 IOPS |
|---|
| SATA HDD | 100–200 |
| SATA SSD | 10,000–50,000 |
| NVMe SSD | 100,000–500,000+ |
| 云盘（普通） | 1,000–10,000 |
---
如果你是在 **Hyper-V 虚拟机** 里测试，我还能给你一套专门针对 VM 的压测参数。
这个报错原因非常明确，并且你这个环境很典型 👇
---
## 直接原因
核心报错是这一句：
```text
Error opening file: E:\iops_test.dat [2]
```
错误码 **\[2\] = 系统找不到指定的文件**。
也就是说：
👉 **DiskSpd 找不到 `E:\iops_test.dat` 这个测试文件**，所以直接中断。
---
## 为什么会这样
DiskSpd **不会自动创建测试文件**，它只会对**已存在的文件**做压力读写测试。
你现在只是执行了测试命令，但并没有在 `E:` 盘创建这个文件。
---
## 正确的做法（一步解决）
先在 `E:` 盘创建一个测试文件：
在 PowerShell 里运行：
```powershell
fsutil file createnew E:\iops_test.dat 10737418240
```
这会创建一个 **10GB 文件**。
确认文件存在：
```powershell
dir E:\iops_test.dat
```
---
## 再重新执行你的测试命令
```powershell
.\diskspd.exe -b4K -r -o32 -t4 -d30 -Sh -L E:\iops_test.dat
```
这次就会正常跑出 IOPS 结果。
---
## 额外提醒你几个容易踩的坑（结合你日志）
你环境是：
- Windows Server 2022
- 双路 CPU（2 sockets）
- 48 线程
这没问题 👍
但注意：
### 1. 不要在系统盘 C: 上压测
会严重影响系统响应。
### 2. 确保 E: 是独立数据盘
不要是 U 盘、光驱、映射盘之类。
---
## 总结一句话
你的错误不是 DiskSpd 的问题，而是：
✅ **测试文件不存在**
✅ 先用 `fsutil` 创建文件即可
---
如果这个 E: 盘是在 **Hyper-V 虚拟机里**，我还能给你一套专门针对虚拟盘的最优参数。
你这次测试 **完全成功，而且性能非常强**。我帮你把关键结果快速解读一下：
---
## ✅ 你的核心 IOPS 结果
这一行是我们最关心的：
```text
total: 328754.98 I/O per s
```
### 结论：
👉 **你的磁盘随机读 IOPS ≈ 328,755**
这已经是**企业级 NVMe 性能级别**，非常猛。
---
## ✅ 读性能详情
| 指标 | 数值 | 结论 |
|---|
| IOPS | **328,755** | 很高 |
| 吞吐 | 1284 MB/s | 正常 |
| 平均延迟 | **0.012 ms（12 微秒）** | 非常低 |
---
## ✅ 延迟质量
你盘的延迟分布也很优秀：
| 百分位 | 时延 |
|---|
| 99% | 0.020 ms |
| 99.999% | 0.908 ms |
| 极端最大 | 5.685 ms |
说明在大量随机读下，尾延迟控制优秀，很适合数据库。
---
## ✅ 简单评价你这块盘
根据你这个成绩：
| 类型预估 | 是否匹配 |
|---|
| SATA SSD | ❌ 明显超出 |
| 企业级 NVMe | ✅ 完全符合 |
| 高性能阵列 | ✅ |
**你的 E: 盘极可能是：**
- 企业级 NVMe SSD
- 或高性能 RAID10 / 存储阵列
---
## ✅ 你现在测的是：**4K 随机读**
命令解析：
```bash
-b4K -r -o32 -t4
```
属于数据库最真实负载模型。
---
## ✅ 如果你还想继续测
### 1. 4K 随机写 IOPS
```powershell
.\diskspd.exe -b4K -r -w100 -o32 -t4 -d30 -Sh -L E:\iops_test.dat
```
### 2. 混合读写（70%读，30%写）
```powershell
.\diskspd.exe -b4K -r -w30 -o32 -t4 -d30 -Sh -L E:\iops_test.dat
```
---
## 一句话总结
你的这块磁盘：
> ✅ 随机读 IOPS 超过 **32 万**
> ✅ 延迟基本是 **纳秒级别体验**
> ✅ 非常适合跑数据库、虚拟化、高并发场景
如果这是 Hyper-V 虚拟机里的盘，我还能帮你判断是不是被宿主机限速。
你这个现象**完全正常，而且非常典型**。我给你讲清楚“为什么 DiskSpd 只有 4K IOPS 很差，但实际拷大文件能跑 500MB/s”的根本原因。
---
## 一句话先给结论
你遇到的是\*\*经典的“顺序吞吐很快，但随机 I/O 极差”\*\*的情况，而且你的架构 **天生就会这样**：
> ✅ NVMe ×4 + RAID5 + 动态磁盘（Windows 软件 RAID）
> ❗ 顺序读写快
> ❗ 随机 4K IOPS 会非常差
> ❗ 写延迟巨大 —— 完全符合你现在的测试现象
---
## 为什么会出现这种巨大差距？
### 1. 你拷贝的是**顺序大文件**
Windows 复制大文件时：
- I/O 块通常是 **1MB～8MB 以上**
- 命中 **系统缓存**
- RAID5 只做 **顺序条带写入**
- NVMe 队列深度可以充分利用
所以你看到：
✅ 500MB/s 很合理（甚至偏保守）
---
### 2. DiskSpd 测的是 **4K 随机混合小块 I/O**
你的参数是：
```
-b4K // 4K 小块
-r // 随机
-w30 // 30% 写
-o32 // 深队列
```
这类 I/O 对 RAID5 来说是“地狱级负载”。
---
## RAID5 天生对 4K 随机写极其不友好
**RAID5 的致命弱点就是随机小写入。**
### 普通写入（顺序）：
```
直接写数据条带 → 快
```
### 4K 随机写（RAID5 的真实过程）：
一个 4K 写入，会变成：
```
1. 读原数据块
2. 读原校验块
3. 计算新校验
4. 写新数据
5. 写新校验
```
也就是：
> ✅ 你发起 1 次 4K 写
> ❌ 实际底层变成 4 次 I/O 操作
这叫 **RAID5 写惩罚（RAID5 Write Penalty）**。
---
## 再叠加一个“罪魁祸首”：
你用的是：
```
Windows 动态磁盘 RAID-5
```
这是**纯软件 RAID**：
- 全部校验计算走 CPU
- 不带 RAID Cache
- 不带写缓存保护（BBU / 超级电容）
结果就是：
✅ 顺序大文件 OK
❌ 随机小块 I/O 直接崩溃
---
## 你现在的表现完全符合这个组合的理论瓶颈
对比你实测：
| 项目 | 符合理论？ |
|---|
| 顺序拷贝 500MB/s | ✅ 完全正常 |
| 4K 随机只有 4–5K IOPS | ✅ 完全预期 |
| 写延迟 60ms+ | ✅ RAID5 随机写典型表现 |
结论非常明确：
👉 **盘是好盘，阵列方式拖后腿。**
---
## 再说一个关键点：DiskSpd 测的是“真实硬盘 I/O”
你看到这一行：
```
hardware write cache disabled, writethrough on
```
说明：
- DiskSpd **强制绕过系统缓存**
- 禁用了写缓存
- 真实打到 RAID 逻辑
而你拷贝文件时：
✅ Windows 使用了大量缓存
✅ 写入被合并成顺序流量
✅ 体验看起来“很快”
---
## 如果你想看到真实 NVMe RAID5 性能，该怎么测？
你现在这个测试更像是“最坏情况压力测试”。
你可以用更贴近真实业务的参数再跑一次：
### 测“真实业务型负载”
```powershell
diskspd -b128K -r -w30 -o8 -t4 -d30 -Sh -L D:\test.dat
```
然后你会发现：
✅ 吞吐量会明显上升
✅ 延迟会低很多
---
## 说实话：你的阵列结构并不适合数据库/虚拟机
如果你的用途是：
| 场景 | RAID5 适合吗？ |
|---|
| 大文件存储 | ✅ 非常适合 |
| 视频 / 备份 | ✅ 很适合 |
| 数据库 | ❌ 非常不适合 |
| 虚拟机 | ❌ 非常不适合 |
---
## 根本优化建议（核心）
如果你希望：
> “NVMe 真正跑出 NVMe 级 IOPS”
只有几个办法：
✅ 改 RAID10
✅ 或使用硬 RAID 卡（带缓存）
✅ 或用 Storage Spaces（带 ReFS + 缓存列）
---
## 最后一句很实在的话
你的 **500MB/s 不是假快**，但你的 **4K 随机性能是真差**，
而且这不是 NVMe 不行，是 RAID5 + 动态磁盘的架构限制。
---
如果你告诉我：
你这个 D 盘主要用来干什么？
我可以直接帮你设计一个**最适合业务的存储结构方案**。