Linux服务器磁盘IO故障排查实战：从iostat诊断到内核参数调优

服务器磁盘IO瓶颈为什么难定位

Linux服务器运维中，磁盘IO故障是最常见也最容易误判的问题。CPU飙高可能是IO等待导致，应用响应慢可能是磁盘写入阻塞引发，甚至内核恐慌（Kernel Panic）也可能与存储栈异常有关。磁盘IO故障排查的核心在于区分：是设备性能不足、是队列深度配置不当、还是文件系统损坏。

IO瓶颈的典型表现：load average高但CPU使用率低，%iowait持续超过20%，应用日志中出现大量timeout，dmesg中报存储链路重试。遇到这些现象，先别急着换硬件，90%的IO问题可以通过诊断和调优解决。

iostat核心指标解读与现场取证

iostat是磁盘IO诊断的起点，但很多人只看%util就下结论，这是不够的。需要关注的完整指标集：

# 每秒采样一次，输出5次
iostat -dx 1 5

# 输出字段含义
# Device   - 设备名
# rrqm/s   - 每秒合并的读请求数
# wrqm/s   - 每秒合并的写请求数
# r/s      - 每秒完成的读IOPS
# w/s      - 每秒完成的写IOPS
# rkB/s    - 每秒读吞吐量
# wkB/s    - 每秒写吞吐量
# await    - 平均IO等待时间(ms)，包含排队时间+服务时间
# r_await  - 读请求平均等待时间
# w_await  - 写请求平均等待时间
# svctm    - 平均IO服务时间(ms)
# %util   - 设备利用率百分比

关键判断逻辑：

实操取证实例：

# 1. 快速查看哪个进程在疯狂写盘
iotop -oP
# 找到占用IO最高的进程后，确认其文件描述符
ls -l /proc/<PID>/fd | grep -i deleted

# 2. 确认具体文件被频繁读写
perf record -e block:block_rq_issue -ag sleep 10
perf report

# 3. 检查设备是否有过载重试
dmesg | grep -i "reset\|error\|retry\|abort" | tail -20

SATA SSD与NVMe的IO队列差异分析

SATA SSD和NVMe SSD的IO队列模型完全不同，排查思路也不同：

SATA SSD走AHCI控制器，NCQ（Native Command Queuing）最大队列深度32，单队列串行处理。当并发IO请求超过32时，多余请求在内核队列中排队等待，await值会线性增长。

NVMe SSD支持多队列（通常64个提交队列+1个完成队列），每队列深度65535，理论上并行处理能力是SATA的数千倍。NVMe的await不应超过1ms，如果持续超过2ms，大概率是PCIe通道带宽饱和或CPU NUMA亲和性不对。

检查NVMe队列配置：

# 查看NVMe设备信息
nvme list

# 查看队列深度配置
cat /sys/block/nvme0n1/queue/nr_requests

# 查看当前IO调度器
cat /sys/block/nvme0n1/queue/scheduler
# NVMe应显示 [none] 或 [noop]
# 如果显示 mq-deadline，手动切换
echo none > /sys/block/nvme0n1/queue/scheduler

NUMA亲和性检查——NVMe设备挂载在特定NUMA节点上，跨节点访问增加延迟：

# 查看NVMe设备的NUMA节点
cat /sys/class/nvme/nvme0/device/numa_node

# 查看进程当前运行在哪个NUMA节点
numactl -p <PID>

# 绑定进程到NVMe所在NUMA节点
numactl --cpunodebind=0 --membind=0 <your_command>

内核IO调度器选型与调优

Linux内核提供多种IO调度器，不同场景选错调度器性能差距可达3倍以上：

# 查看当前调度器
cat /sys/block/sda/queue/scheduler

# 可用调度器及适用场景：
# mq-deadline - SATA SSD/HDD，保证请求延迟上限
# bfq        - HDD桌面/交互式场景，带宽公平分配
# kyber      - NVMe SSD，快速路径低延迟
# none       - NVMe SSD，无调度开销，纯硬件队列

生产环境推荐配置：

# SATA SSD - mq-deadline
echo mq-deadline > /sys/block/sda/queue/scheduler

# NVMe SSD - none
echo none > /sys/block/nvme0n1/queue/scheduler

# HDD + 混合负载 - bfq
echo bfq > /sys/block/sdb/queue/scheduler

关键内核参数调优：

# /etc/sysctl.conf 或 sysctl -w

# 增大读预读量（适合顺序读场景）
echo 2048 > /sys/block/sda/queue/read_ahead_kb

# 调整脏页回写比例（减少写IO突发）
vm.dirty_ratio = 20
vm.dirty_background_ratio = 10

# 减少脏页回写间隔（更平滑地写入）
vm.dirty_writeback_centisecs = 500

# 对NVMe设备增大队列深度
echo 1024 > /sys/block/nvme0n1/queue/nr_requests

脏页参数说明：dirty_background_ratio是后台回写触发的脏页占比，dirty_ratio是阻塞写入触发的脏页占比。数据库场景建议降低这两个值，避免大批量脏页回写造成IO尖峰：

# 数据库场景推荐值
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

文件系统层面的IO诊断

磁盘IO问题不一定出在块设备层，文件系统配置错误同样会导致性能断崖：

# 检查文件系统挂载选项
mount | grep /data

# XFS推荐挂载选项（数据库场景）
mount -o noatime,nodiratime,logbufs=8,logbsize=256k,allocsize=64m /dev/sda1 /data

# Ext4推荐挂载选项
mount -o noatime,nodiratime,data=writeback,barrier=0 /dev/sdb1 /data
# 注意：barrier=0 在断电时可能丢数据，仅限有UPS保护的环境

文件系统碎片化检查：

# XFS碎片化检查
xfs_db -c frag -r /dev/sda1

# XFS在线碎片整理（需卸载或只读模式效果更好）
xfs_fsr /dev/sda1

# Ext4碎片化检查
e4defrag -c /data

inode耗尽是一个容易被忽略的问题——磁盘空间充足但无法写入新文件：

# 检查inode使用率
df -i

# 如果inode使用率接近100%，需要删除大量小文件
# 找出占用inode最多的目录
find /data -xdev -printf '%h\n' | sort | uniq -c | sort -rn | head -20

RAID阵列与多路径故障排查

生产服务器通常使用RAID卡（如MegaRAID、HBA330），RAID卡缓存策略直接影响IO性能：

# MegaRAID查看缓存策略
storcli /c0 show

# 关键字段
# DiskCachePolicy : Enabled（磁盘自带缓存开启）
# AccessPolicy    : Read/Write
# CurrentCacheLevel : WriteBack（写缓存开启，性能优先）

# 修改缓存策略为WriteBack（提升写性能）
storcli /c0 /v0 set wbcache

# 修改缓存策略为WriteThrough（数据安全优先）
storcli /c0 /v0 set wtcache

RAID卡BBU（电池备份单元）故障会导致缓存策略自动降级为WriteThrough，性能可能下降50%以上：

# 检查BBU状态
storcli /c0 /bbu show

# 如果BBU状态为Failed，临时禁用BBU强制使用WriteBack
storcli /c0 /bbu set forcedwb

# 然后尽快更换BBU电池

多路径（Multipath）环境下的路径切换也会导致IO抖动：

# 查看多路径状态
multipath -ll

# 检查是否有路径故障
# 正常：2条路径都是active
mpath1 (3600507...) dm-0 size=500G
├─ [active][ready] /dev/sda
└─ [active][ready] /dev/sdb

# 异常：1条路径故障
mpath1 (3600507...) dm-0 size=500G
├─ [active][ready] /dev/sda
└─ [failed][faulty] /dev/sdb

# 恢复故障路径
multipath -r

实战案例：MySQL服务器IO抖动排查全过程

某MySQL主库在业务高峰期出现间歇性IO抖动，await从2ms跳到200ms，持续30秒后恢复，每10-15分钟发作一次。

排查步骤：

# 步骤1：确认IO抖动时间点
curl http://prometheus:9090/api/v1/query?query=rate(node_disk_io_time_seconds_total[1m])

# 步骤2：检查是否脏页回写触发
watch -n1 "cat /proc/meminfo | grep -i dirty"
# 发现抖动前Dirty pages从2GB急速增长到15GB

# 步骤3：确认脏页回写参数
sysctl vm.dirty_ratio vm.dirty_background_ratio
# vm.dirty_ratio = 30
# vm.dirty_background_ratio = 15
# 问题：dirty_background_ratio=15意味着内存15%脏页才开始后台回写
# 触发时已积压大量脏页，回写风暴造成IO阻塞

# 步骤4：调优参数
sysctl -w vm.dirty_background_ratio=3
sysctl -w vm.dirty_ratio=8
sysctl -w vm.dirty_writeback_centisecs=300

# 步骤5：观察抖动是否消除
# 调整后脏页更早更平滑地回写，IO抖动消失

根因分析：MySQL的InnoDB Buffer Pool大量刷脏页时，内核的脏页回写机制积压到高水位才触发，瞬间大量IO请求涌入块设备造成队列阻塞。将后台回写阈值降低后，脏页更均匀地分散写入，IO尖峰消失。

IO监控告警体系搭建

生产环境需要持续监控磁盘IO指标，Prometheus + node_exporter是标准方案：

# node_exporter已内置磁盘IO指标
# 关键指标
# node_disk_io_time_seconds_total   - IO时间
# node_disk_read_time_seconds_total - 读时间
# node_disk_write_time_seconds_total- 写时间
# node_disk_io_now                  - 当前在途IO数

推荐告警规则：

groups:
  - name: disk_io_alerts
    rules:
      - alert: DiskIOAwaitHigh
        expr: rate(node_disk_read_time_seconds_total[5m]) / rate(node_disk_reads_completed_total[5m]) > 0.05
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "磁盘IO等待时间超过50ms"

      - alert: DiskIOUtilHigh
        expr: rate(node_disk_io_time_seconds_total[5m]) > 0.9
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "磁盘利用率持续超过90%"

以上方案从iostat指标解读、调度器选型、内核参数调优、文件系统配置、RAID故障诊断到监控告警，覆盖了Linux服务器磁盘IO故障排查的完整链路。

原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/linux-fu-wu-qi-ci-pan-io-gu-zhang-pai-cha-shi-zhan-cong/