2. 性能指标：IOPS、吞吐量、延迟、IO大小、队列深度
聊磁盘性能，绕不开这五个指标。我见过不少运维同事，上来就盯着IOPS看，觉得IOPS高就是好。其实没那么简单。这五个指标是互相牵制的，你得把它们放在一起看，才能看清系统的真实状态。
一句话总结：IOPS看次数，吞吐量看总量，延迟看快慢，IO大小看单次搬运量，队列深度看并发能力。五个指标缺一不可。
2.1 IOPS：每秒能处理多少个请求
IOPS，全称是Input/Output Per Second。说白了，就是磁盘一秒钟能处理多少个读写请求。这个指标在随机读写场景下特别重要，比如数据库、邮件服务器这类应用。
我个人习惯把IOPS分成两类来看：
- 随机IOPS：数据库场景的核心指标。你想想看，MySQL每次查一条记录，可能就要去磁盘上随机读一个4KB的数据块。这时候IOPS就是命门。
- 顺序IOPS：大文件读写场景。比如视频流、日志归档，这时候IOPS反而不是瓶颈，吞吐量更重要。
我在项目中遇到过一件事：某电商平台的MySQL实例，业务高峰期响应突然变慢。监控一看，磁盘IOPS已经飙到8000了，而那块SSD的标称随机读IOPS是10000。嗯，已经接近极限了。后来我们做了读写分离，把读请求分流到只读实例上，IOPS降到了6000左右，系统才恢复正常。
避坑指南：我曾经见过有人拿顺序读的IOPS去评估数据库性能，结果买回来的盘根本扛不住随机写。记住，数据库场景一定要看随机写IOPS，尤其是4KB/8KB小块的随机写能力。
2.2 吞吐量：每秒能搬运多少数据
吞吐量，也叫带宽，单位是MB/s或GB/s。它衡量的是磁盘在一秒内能传输多少数据。IOPS和吞吐量之间的关系，其实有个公式：
吞吐量 = IOPS × IO大小举个例子：如果IOPS是10000，每次IO大小是4KB，那吞吐量就是10000 × 4KB = 40MB/s。但如果IO大小变成256KB，同样的IOPS，吞吐量就变成了2560MB/s。你看，同样都是10000 IOPS，吞吐量能差60多倍。
所以，只看IOPS不看IO大小，很容易被误导。我建议你每次排查性能问题时，把IOPS和吞吐量放在一张图上对比着看。
| 场景 | 典型IO大小 | 关注指标 |
|---|---|---|
| OLTP数据库 | 4KB - 16KB | 随机IOPS |
| OLAP/数仓 | 64KB - 1MB | 吞吐量 |
| 视频流媒体 | 512KB - 4MB | 吞吐量 |
| 日志写入 | 1KB - 8KB | IOPS + 延迟 |
2.3 延迟：一个请求到底要等多久
延迟，就是发出去一个IO请求，到收到响应，中间花了多少时间。单位通常是毫秒（ms）。这个指标最直观，也最让人头疼。
我一般把延迟分成三个阶段来看：
- 设备延迟：磁盘本身处理请求的时间。SSD一般在0.1ms - 1ms，机械盘在5ms - 15ms。
- 队列延迟：请求在队列里排队等待的时间。这个时间往往比设备延迟还长。
- 网络延迟：如果是SAN或NAS存储，还得算上网络传输的时间。
为什么会这样？因为磁盘处理请求的速度是有限的。当请求太多，队列就会变长，后面的请求就得等着。我曾经遇到过一台服务器，磁盘利用率才30%，但应用已经慢得不行了。查了半天，发现队列深度到了32，平均延迟飙到了200ms。说白了，就是请求在排队上浪费了太多时间。
注意：不要只看平均延迟。我建议你同时关注P99延迟（99%的请求都在这个延迟以内）。平均延迟可能只有10ms，但P99延迟可能已经到500ms了。那些慢请求，才是真正影响用户体验的元凶。
2.4 IO大小：单次搬运的数据量
IO大小，就是每次读写操作的数据量。这个指标看似简单，但影响很大。不同的应用，IO大小差异很大：
- 数据库的随机读写，通常是4KB、8KB、16KB
- 文件服务器的读写，可能是64KB、128KB
- 视频编辑、大数据分析，可能是1MB甚至更大
IO大小直接影响IOPS和吞吐量的换算关系。而且，不同的存储设备对不同IO大小的表现也不一样。我记得有一次帮客户调优，他们用的是全闪存阵列，但业务IO大小只有512字节。结果IOPS上不去，延迟还高。后来把应用层的IO合并策略改了一下，把512字节合并成4KB再下发，IOPS直接翻了一倍。
2.5 队列深度：并发能力的上限
队列深度，就是操作系统或存储控制器允许同时排队的IO请求数量。这个指标决定了系统的并发能力。
队列深度和延迟的关系，有点像高速公路上的车流量：
- 队列深度太小：并发能力不足，磁盘利用率低，吞吐量上不去
- 队列深度太大：请求排队时间变长，延迟飙升，甚至引发抖动
我个人的经验是，队列深度需要根据磁盘类型来调整：
| 磁盘类型 | 建议队列深度 | 说明 |
|---|---|---|
| SATA SSD | 32 - 64 | 队列深度过高会导致延迟抖动 |
| NVMe SSD | 128 - 256 | NVMe支持高并发，队列深度可以大一些 |
| 机械盘（SAS） | 8 - 16 | 机械盘并发能力有限，队列深度不宜过大 |
| 全闪存阵列 | 64 - 128 | 取决于控制器能力，需要实际压测 |
调优技巧：我曾经在调优一个NVMe SSD时，把队列深度从默认的32调到128，IOPS从30万涨到了50万。但再往上调到256，IOPS反而没怎么涨，延迟却从0.5ms涨到了1.2ms。所以，队列深度不是越大越好，找到那个拐点才是关键。
2.6 五个指标的关系图
下面这张图，把这五个指标的关系梳理了一下。你一看就明白：
2.7 实战：如何用这五个指标定位问题
光知道概念没用，得会用。我分享一个排查思路：
- 先看延迟：如果应用感觉慢，先看磁盘平均延迟和P99延迟。延迟高了，再往下查。
- 再看队列深度：延迟高的时候，看看队列深度是不是也高了。如果是，说明请求在排队。
- 然后看IOPS和吞吐量：看看磁盘是不是已经达到性能上限了。如果IOPS接近标称值，那就是磁盘瓶颈。
- 最后看IO大小：如果IOPS不高但吞吐量很高，说明IO大小比较大。反之，如果IOPS很高但吞吐量很低，说明是小IO。
举个例子。有一次线上告警，说数据库响应变慢。我按这个思路查了一遍：
- 延迟：平均延迟从2ms涨到了50ms，P99延迟到了200ms
- 队列深度：从8涨到了64
- IOPS：从5000涨到了9000，接近SSD上限
- IO大小：平均4KB，典型的数据库随机写
结论很明确：磁盘IOPS不够了。后来我们加了块缓存盘，把热数据放到更快的NVMe SSD上，问题就解决了。
核心要点：这五个指标就像医生的五项检查。单看一个指标，可能会误诊。五个指标放在一起看，才能准确判断磁盘的健康状况。下次遇到性能问题，别急着下结论，先把这五个指标拉出来看看。