按路径逐层验证
存储路径像一条流水线：应用发请求、主机栈排队、驱动与多路径选路、网络或链路传输、控制器处理、介质完成。查找瓶颈要顺着这条路走，观察每一层是「忙碌」还是「等待」。一个常见的误判是把忙碌当瓶颈：上游设备显示高利用率，其实是在等下游响应。真正的位置通常在队列持续增长的那一层。
基本信息
| 排查顺序 | 应用与主机资源 → 主机块层与队列 → 驱动与多路径 → 承载网络 → 控制器 → 介质与池 |
|---|---|
| 各层要点 | 主机看 CPU 与队列、块层看等待时间、网络看重传与丢包、控制器看缓存与负载、介质看服务时间 |
| 判读原则 | 队列持续增长说明下游服务能力不足；利用率高但等待时间长要分层确认 |
| 必要前提 | 各采集点时间对齐、口径一致，否则跨层关联会得出错误因果 |
| 变更纪律 | 一次只改一层，改后复测，避免同时调整导致无法归因 |
| 常见盲点 | 虚拟化层超配、同宿其他负载、快照与重建等后台任务 |
典型使用场景
- 业务变慢的第一次定位，需要快速缩小问题范围时
- 阵列界面显示一切正常但业务侧仍慢，需要向上游找原因时
- 网络存储环境延迟偏高，判断瓶颈在承载网络还是介质侧
- 虚拟化平台中多台虚拟机同时变慢，排查共享层瓶颈时
- 调整参数后性能未改善，回头确认真正的瓶颈是否被找对
分层采集入口
分层采集入口
# 主机层：CPU、内存与运行队列
vmstat 1 10; top -b -n1 | head -20
# 块层：各设备的等待时间、队列与利用率
iostat -x 1 30
# 网络层：丢包、重传与错误计数
sar -n DEV 1 10
ethtool -S eth0 | grep -Ei 'drop|err|crc'
# 路径与控制器状态
multipath -ll | grep -E 'active|failed'
# 阵列侧缓存、控制器负载与介质服务时间，字段名以厂商文档为准层次与瓶颈信号
| 层次 | 观察点 | 典型瓶颈信号 |
|---|---|---|
| 主机与块层 | 等待时间、队列深度 | 等待时间持续升高而下游空闲 |
| 驱动与多路径 | 路径状态与切换次数 | 路径反复切换导致 IO 抖动 |
| 承载网络 | 丢包、重传、带宽占用 | 重传率上升，有效带宽下降 |
| 控制器 | 缓存利用率、控制器负载 | 缓存写满与降级策略触发 |
| 介质与池 | 平均服务时间、错误计数 | 服务时间整体上移或个别盘异常 |
「设备利用率 100%」既可能是瓶颈，也可能只是被下游拖住。区分的办法是同时看等待时间与下游指标：等待时间长且下游明显忙碌，才是真正堵在那里。
在多路径、虚拟化与网络存储叠加的环境里，同一现象可能由四五个层次共同造成。排查时保留每一层的原始数据，不要在结论未定时顺手改参数，否则现场证据会被自己的变更抹掉。