盘响应变慢怎么分层排查
单盘响应变慢会拖慢整个阵列：同一卷的请求会在最慢的成员盘上排队，最终表现为应用端的延迟抖动。排查要按层收集证据：先看盘侧 SMART 属性与自测结果，再看链路计数与卡侧错误统计，然后核对系统侧逐盘利用率与等待，最后才回到应用层。跳过中间层直接怀疑应用，通常只是把时间花在错误的地方。
基本信息
| 适用平台 | Linux 系统侧用 iostat、dmesg，盘侧用 smartctl，卡侧用 storcli |
|---|---|
| 关键属性 | 188 命令超时、197 待映射扇区、5 已重映射扇区 |
| 链路信号 | 卡侧超时与复位计数、SAS PHY 错误计数 |
| 系统信号 | 逐盘利用率、平均等待与队列长度 |
| 权限要求 | 读取盘与卡信息需要 root |
典型使用场景
- 业务延迟抖动：应用层找不到原因时，先确认是否存在单盘拖尾
- 虚拟化环境排查：确认宿主机磁盘视图与阵列状态，再进入虚拟机层
- 重建期间性能下降：判断是正常负载上升还是成员盘异常
- 巡检发现慢盘：属性或计数异常时提前隔离观察并准备替换
- 故障后复盘：用留存的历史数据还原慢盘的恶化过程
分层证据收集
分层证据收集
smartctl -A /dev/sdb | grep -E "188|199| 5 " # 盘侧超时与扇区相关属性
iostat -x 5 | grep -E "sd[b-h]" # 系统侧逐盘利用率与等待
storcli /c0/e252/s4 show all | grep -i -E "error|timeout" # 卡侧盘级错误与超时
for p in /sys/class/sas_phy/*; do grep -H . $p/invalid_dword_count; done 2>/dev/null | head # 链路层错误
dmesg -T | grep -i -E "sdb|timeout" | tail -20 # 内核侧超时与重试记录分层证据与含义
| 层级 | 观察对象 | 指向问题 |
|---|---|---|
| 盘 | 属性 188、197、5 的变化 | 盘面介质或固件侧异常 |
| 链路 | PHY 错误与 CRC 类计数 | 线缆、连接器或背板 |
| 阵列卡 | 盘级超时与复位计数 | 卡到盘的传输稳定性 |
| 系统 | 逐盘利用率与队列 | 单盘拖尾导致整体变慢 |
慢盘与坏盘是两种处理方式：慢盘先隔离观察并准备备件，坏盘按故障流程立即更换。
只盯平均延迟会把问题掩盖掉：阵列的平均值正常，但单块盘的等待时间可能已经远高于同伴。