目录
零基础学习 Linux 磁盘监控并快速应用到性能测试工作中,关键在于 理解核心指标、掌握关键工具、识别瓶颈模式、关联性能影响。磁盘 I/O 往往是性能瓶颈的重灾区,尤其在数据库、日志写入、文件服务等场景。下面是一个聚焦磁盘 I/O 监控的详细学习路径:
核心目标:
- 理解磁盘 I/O 核心指标: 掌握 IOPS、吞吐量、延迟、利用率等概念及其相互关系。
- 掌握核心监控命令: 熟练使用
iostat
,iotop
,vmstat
,df
,du
。 - 识别磁盘瓶颈模式: 能判断 I/O 过载、高延迟、设备饱和、文件系统问题等。
- 定位高 I/O 进程/文件: 找出是哪个进程或文件在疯狂读写。
- 整合到性能测试流程: 在压测过程中实时监控磁盘,并在报告中分析 I/O 使用情况及其对性能的影响。
学习内容与快速应用路径
第一阶段:理解磁盘 I/O 核心概念 (0.5天)
核心指标:
IOPS
(Input/Output Operations Per Second): 每秒完成的读写操作次数。 衡量磁盘处理小文件或随机读写的能力(如数据库操作)。SSD 远高于 HDD。吞吐量/带宽 (Throughput)
: 每秒读写的数据量 (MB/s 或 GB/s)。 衡量磁盘处理大文件或顺序读写的能力(如视频流、备份)。受接口速度(SATA, SAS, NVMe)和磁盘本身限制。延迟/响应时间 (Latency)
: 一个 I/O 操作从发起到完成所花费的时间 (ms)。 直接影响用户体验和应用响应速度。越低越好。高延迟是性能问题的直接信号!利用率 (Utilization - %util)
: 磁盘设备处理 I/O 请求的时间百分比。 表示磁盘的繁忙程度。持续接近 100% 表示磁盘饱和,成为瓶颈。队列长度 (Queue Length - avgqu-sz)
: 平均等待处理的 I/O 请求数量。 队列越长,延迟越高。持续 > 1 可能表示磁盘跟不上请求速度。等待时间 (Wait Time - await)
: 平均每个 I/O 请求的等待时间 (ms)。 包含在队列中排队的时间和在磁盘上处理的时间。await
高是性能差的直接体现。服务时间 (Service Time - svctm)
: 磁盘处理一个 I/O 请求所需的实际时间 (ms)。 衡量磁盘本身的物理性能。svctm
高通常表示磁盘慢(如 HDD)或设备本身问题。(注意:现代 Linux 内核中svctm
计算可能不准确,await
更可靠)读写比例
: 读操作 (r/s
,rMB/s
) 和写操作 (w/s
,wMB/s
) 的比例。对优化策略(缓存、RAID 级别)有指导意义。
相互关系:
- Little’s Law (排队论):
平均队列长度 (avgqu-sz) ≈ 平均 IOPS (r/s + w/s) * 平均等待时间 (await)
。理解这个关系有助于分析瓶颈:队列长 (avgqu-sz
高) 要么是请求太多 (IOPS 高),要么是磁盘处理慢 (await
高)。 %util
高 +await
高: 磁盘饱和,是严重瓶颈。%util
低 +await
高: 可能应用程序问题(如大量小随机 I/O 对 HDD 不友好),或者队列配置问题,或者监控采样间隔内突发高 I/O。%util
高 +await
低: 磁盘能高效处理请求(通常是 SSD 或良好优化的顺序 I/O)。%util
接近 100%: 磁盘已达到其最大能力,无法处理更多请求,成为系统瓶颈。
- Little’s Law (排队论):
块设备 vs 文件系统:
- 块设备 (
/dev/sda
,/dev/nvme0n1
): 物理磁盘或逻辑卷(LVM, RAID)。监控工具(如iostat
)主要看这个层面。 - 文件系统 (
/
,/data
): 建立在块设备之上(如 ext4, xfs, btrfs)。监控工具(如df
,du
)看空间使用,性能受底层块设备和自身实现影响。
- 块设备 (
第二阶段:掌握核心监控命令与指标 (1-2天)
目标:熟练使用命令获取数据,理解每个关键指标的含义和健康阈值。
iostat
命令 (磁盘 I/O 监控的瑞士军刀):- 安装: 通常包含在
sysstat
包 (yum install sysstat
/apt install sysstat
)。 - 命令:
iostat [选项] [间隔秒数] [次数]
- 最常用组合:
iostat -dx 1
-d
: 只显示磁盘统计信息。-x
: 显示扩展统计信息(包含关键指标%util
,await
,avgqu-sz
,svctm
,r/s
,w/s
,rMB/s
,wMB/s
)。1
: 每秒刷新一次。
- 查看 CPU 的 I/O Wait (
%wa
):iostat -c 1
- 以 MB/s 显示吞吐量:
iostat -dxm 1
- 最常用组合:
- 输出解读 (
iostat -dx 1
部分):Device r/s w/s rMB/s wMB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util sda 10.00 50.00 0.10 1.00 0.00 5.00 0.00 9.09 1.00 5.00 0.25 10.00 20.00 1.50 90.00 nvme0n1 500.00 200.00 50.00 20.00 0.00 0.00 0.00 0.00 0.10 0.20 0.05 100.00 100.00 0.10 7.00
Device
: 块设备名 (如/dev/sda
,/dev/nvme0n1
)。r/s
,w/s
: 每秒读/写请求数 (IOPS)。rMB/s
,wMB/s
: 每秒读/写数据量 (吞吐量)。%util
: 设备利用率百分比。最关键指标! 持续 > 60-70% 需关注,接近 100% 是严重瓶颈。r_await
,w_await
: 读/写请求的平均响应时间 (ms)。核心指标! 通常期望 < 10ms (SSD) / < 20ms (高速 HDD) / < 50ms (普通 HDD)。> 100ms 通常很糟糕。aqu-sz
(avgqu-sz): 平均队列长度。 持续 > 1 表示可能有排队。rareq-sz
,wareq-sz
: 读/写请求的平均大小 (KB)。有助于判断 I/O 模式(小随机 vs 大顺序)。svctm
: 平均服务时间 (ms)。现代系统仅供参考,await
更可靠。rrqm/s
,wrqm/s
,%rrqm
,%wrqm
: 每秒合并的读/写请求数及其百分比。合并是内核优化,越高越好(尤其对机械盘)。
- 健康阈值 (经验值):
%util
: < 70% 较安全。持续 > 80-90% 表示接近饱和。100% 是绝对瓶颈。await
(r_await
/w_await
): SSD: 期望 < 1-5ms, 警告 > 10ms。HDD: 期望 < 10-20ms, 警告 > 30-50ms。通用警报线:> 100ms。avgqu-sz
: 持续 > 1-2 需要关注,尤其伴随高await
或高%util
。svctm
: 应远小于await
。如果接近await
,表示排队时间很短或没有。
- 快速应用:
- 压测时持续运行
iostat -dx 1
。 - 核心关注:
- 目标磁盘(如数据库所在
/dev/sdb
)的%util
是否持续很高(>80%)? r_await
/w_await
是否超过阈值(如 >20ms)?avgqu-sz
是否持续 > 0?是否在增长?r/s
/w/s
(IOPS) 和rMB/s
/wMB/s
(吞吐) 的峰值是多少?读写比例如何?- 对比不同磁盘(SSD vs HDD)的性能差异。
- 目标磁盘(如数据库所在
- 压测时持续运行
- 安装: 通常包含在
iotop
命令 (找出高 I/O 进程):- 命令:
iotop
(动态刷新)。通常需要 root 权限 (sudo iotop
)。 - 作用: 类似
top
,但实时显示哪些进程正在进行磁盘 I/O 及其消耗量。定位“元凶”的利器! - 输出解读:
- 顶部:总磁盘读/写速度。
- 进程列表:关键列:
DISK READ
,DISK WRITE
: 进程当前的磁盘读/写速度 (KB/s)。SWAPIN
,IO
:IO
列表示进程当前等待 I/O 所占用的时间百分比(类似%wa
但针对进程)。SWAPIN
是交换相关的。PRIO
: I/O 优先级。USER
,PID
,COMMAND
: 进程信息。
- 交互操作:
- 按
o
: 只显示有实际 I/O 活动的进程。 - 按
r
: 反转排序。 - 按
p
: 按 PID 排序。 - 按
a
: 显示累积 I/O(从启动开始的总量),按a
切回实时。
- 按
- 快速应用:
- 当
iostat
显示某磁盘%util
高或await
高时,立刻运行sudo iotop -o
。 - 按
DISK READ
或DISK WRITE
排序 (左右箭头
切换列,r
反转)。 - 找出读写最频繁的前几个进程。记录 PID 和命令。
- 观察这些进程的
IO
列(等待 I/O 时间),如果很高,表示该进程被 I/O 阻塞。
- 当
- 命令:
vmstat
命令 (系统级 I/O 概览):- 命令:
vmstat 1
(每秒刷新)。 - 输出解读 (
io
部分):procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 2 0 500000 100000 800000 0 0 1000 500 200 500 10 5 70 15 0
bi
(Blocks In): 每秒从块设备读入的数据量 (blocks/s, 通常 1 block=512B 或 1KB)。 可换算为 KB/s (bi * 512 / 1024 ≈ KB/s)。bo
(Blocks Out): 每秒写入块设备的数据量 (blocks/s)。 换算同上。wa
(I/O Wait): CPU 等待 I/O 的时间百分比。 是系统级 I/O 瓶颈的重要信号!如果wa
高,说明有进程在等 I/O,导致 CPU 空闲。结合iostat
分析。
- 快速应用: 运行
vmstat 1
,关注wa
和b
(处于不可中断睡眠/等 I/O 的进程数) 列。 如果wa
持续 > 5-10% 或b
列较高,说明存在 I/O 瓶颈,需要进一步用iostat
和iotop
定位。
- 命令:
df
/du
命令 (监控磁盘空间):df
(Disk Free): 查看文件系统的磁盘空间使用情况。- 命令:
df -h
(-h
人类可读格式) - 输出: 显示每个挂载点的总容量、已用、可用空间及使用百分比。
- 快速应用: 压测前、中、后务必检查! 确保目标文件系统(如数据库目录、日志目录)有足够空间 (
Avail
)。空间耗尽 (Use%
=100%) 会导致严重错误(无法写入、数据库崩溃)。关注Use% > 80%
的告警。
- 命令:
du
(Disk Usage): 估算文件和目录占用的磁盘空间。- 命令:
du -sh [目录路径]
(-s
总大小,-h
人类可读)。du -h --max-depth=1 [目录路径]
查看一级子目录大小。 - 快速应用: 当
df
发现某个挂载点空间不足时,用du
深入该目录下找出占用空间最大的子目录或文件(如大日志文件、临时文件)。
- 命令:
第三阶段:识别磁盘问题与瓶颈 (核心技能)
磁盘饱和/过载:
- 现象:
iostat -dx 1
显示%util
持续接近 100%。await
(r_await
/w_await
) 显著升高 (e.g., > 50ms 甚至 > 100ms)。avgqu-sz
(队列长度) 持续较高 (e.g., > 5-10)。vmstat
显示wa
(I/O Wait) 持续较高 (e.g., > 10-20%),b
(阻塞进程) 可能也高。- 应用响应慢,超时增多,TPS 下降或无法提升。
- 原因: 磁盘本身的物理性能达到极限(HDD 尤其明显)。请求速率 (IOPS) 或数据量 (吞吐) 超过了磁盘的处理能力。
- 快速诊断:
iostat -dx 1
是黄金标准(看%util
,await
,avgqu-sz
)。vmstat 1
看wa
,b
。 - 性能测试关联: TPS 达到瓶颈无法提升,RT 飙升,错误率(超时)上升,且
%util
100% 是铁证。
- 现象:
高延迟 (High Latency):
- 现象:
iostat
显示await
持续较高,但%util
可能不高(尤其对 HDD 的随机小 I/O)或很高。- 用户感觉应用“卡顿”,响应时间不稳定。
- 原因:
- 磁盘慢: HDD 处理随机 I/O 天然延迟高。
- 队列堆积: 即使
%util
不高,瞬时高并发 I/O 也可能导致队列堆积 (avgqu-sz
短暂升高) 从而拉高await
。 - 文件系统/配置问题: 文件系统碎片(ext4 较少)、journal 日志写入策略、RAID 重建、LVM 配置不当。
- 底层存储问题: SAN/NAS 网络延迟、存储控制器过载、SSD 磨损或过热降速。
- 快速诊断:
iostat -dx 1
看await
。iotop
看哪些进程IO
等待高。结合磁盘类型(SSD/HDD)和 I/O 模式(rareq-sz
/wareq-sz
,小=随机)判断。 - 性能测试关联: RT 中位数、P90、P99 延迟高且不稳定。 即使平均 TPS 还行,用户体验差。
- 现象:
空间耗尽:
- 现象:
df -h
显示目标文件系统Use%
=100%,Avail
=0。- 应用日志报错 “No space left on device”, “Disk full”。
- 数据库崩溃或进入只读模式。
- 无法创建新文件或写入数据。
- 原因: 日志文件未轮转、临时文件堆积、备份文件过大、监控不到位。
- 快速诊断:
df -h
一目了然。du -sh /*
或逐级深入du
查找大文件。 - 性能测试关联: 测试直接失败! 是严重事故。必须监控空间。
- 现象:
进程级 I/O 风暴:
- 现象:
iostat
显示某个磁盘突然 I/O 暴增。vmstat
的wa
飙升。 - 原因: 某个进程异常(如 bug 导致疯狂写日志、全表扫描、索引重建、大批量导出/导入)。
- 快速诊断:
sudo iotop -o
立刻揪出罪魁祸首! 按读写速度排序。
- 现象:
第四阶段:整合到性能测试工作流程 (快速应用落地)
测试前准备:
- 安装工具:
sysstat
(iostat
,sar
),iotop
。 - 空间检查:
df -h
确保目标文件系统(数据库、日志、被测应用数据目录)有充足空间(> 30% 空闲或符合预期增长)。 - 基线测量: 系统空闲时运行
iostat -dx 1 5
,vmstat 1 5
, 记录基线 I/O 情况。记录df -h
。
- 安装工具:
压测中实时监控 (开多个终端/tmux):
- 窗口 1:
iostat -dx 1
- 紧盯目标磁盘的%util
,await
(r_await
/w_await
),avgqu-sz
。%util
100% 或await
> 阈值是红灯! - 窗口 2:
vmstat 1
- 关注wa
(I/O Wait) 和b
(阻塞进程数)。wa
> 5-10% 是系统级警报。 - 窗口 3:
sudo iotop -o
- 按DISK READ
或DISK WRITE
排序。 随时准备抓取高 I/O 进程。关注进程的IO
列(等待 I/O 时间)。 - 窗口 4 (可选):
df -h
- 定期运行(如每 5 分钟)检查空间使用率,特别是日志增长快的目录。 - 核心关注:
- 当目标磁盘
%util
持续 > 90% 时,记录时间戳,并关联此时 TPS 是否停滞/下降?RT 是否飙升?错误(超时)是否增多? - 当
await
持续 > 50ms (HDD) 或 > 10ms (SSD) 时,记录时间戳和具体值。 - 当
vmstat
的wa
> 10% 时,记录时间戳。 - 当
iotop
发现某个进程 I/O 异常高时,记录其 PID、命令名和读写速度。 - 当
df
发现空间Use% > 90%
时,立即告警并记录!
- 当目标磁盘
- 窗口 1:
测试后分析与报告:
- 收集数据: 保存
iostat
,vmstat
输出,iotop
截图 (高 I/O 时),df -h
结果,sar -b
/sar -d
历史数据 (sar -b -f /var/log/sa/saXX
查看块设备 I/O)。 - 分析关键点:
- 峰值负载:
%util
max,await
max (r/w),avgqu-sz
max (来自iostat
/sar
)。 - 系统 I/O Wait:
wa
max (来自vmstat
/sar -u
)。 - 吞吐与 IOPS:
r/s
max,w/s
max,rMB/s
max,wMB/s
max。 - 空间使用: 压测前后空间变化,是否接近耗尽。
- Top 进程: 哪些进程产生了最高的 I/O (
iotop
/pidstat -d
)。 - 瓶颈类型判断: 是饱和 (
%util
100%)?高延迟 (await
高)?空间问题?特定进程引起?
- 峰值负载:
- 报告撰写:
- 清晰描述磁盘 I/O 监控结果: 列出关键指标峰值 (
%util max
,await max
,wa max
,rMB/s max
,wMB/s max
, 空间使用率变化)。 - 展示关联性图表/描述: 将
%util
接近 100% 的时间点、await
飙升的时间点、wa
高的时间点 与 性能测试工具记录的 RT 上升点、TPS 下降点/平台点、错误率(超时)上升点 精确对应起来。 - 指出问题与瓶颈:
- 如:“当数据库盘
/dev/sdb
的%util
持续 99% 且w_await
达到 150ms 时,TPS 从 1000 跌至 300,订单提交 RT 从 50ms 升至 2000ms,判断为磁盘 I/O 饱和导致写入瓶颈”。 - 或:“日志盘
/dev/sdc
的w_await
持续在 80ms (iostat
),尽管%util
仅 40%,vmstat
显示wa
达 15%,结合iotop
发现logger_service
进程大量写小日志文件,判断为 HDD 随机写入性能不足导致高延迟”。 - 或:“压测 2 小时后,应用日志目录
/var/log/app
空间使用率达到 100% (df -h
),导致应用崩溃,测试中断”。
- 如:“当数据库盘
- 给出建议:
- 饱和/性能不足:升级磁盘(HDD -> SSD, NVMe)、优化 RAID 级别(RAID 10 for perf)、增加磁盘数量分散 I/O、使用缓存(应用层、文件系统 pagecache)、优化应用 I/O 模式(批量写入、异步 I/O)。
- 高延迟:针对 HDD 优化减少随机 I/O(调整日志策略、优化数据库索引)、检查文件系统配置(journal 模式)、检查底层存储健康(SMART 状态)和配置(队列深度)。
- 空间问题:实施日志轮转和清理策略、监控磁盘空间并设置告警、清理临时文件、扩容存储。
- 特定进程:优化该进程的 I/O 行为(如避免全表扫描、优化日志级别和输出量)。
- 清晰描述磁盘 I/O 监控结果: 列出关键指标峰值 (
- 收集数据: 保存
快速应用到工作中的关键策略
- 工具三板斧: 掌握
iostat -dx 1
(看设备性能),sudo iotop -o
(找进程),df -h
(看空间) 这三个命令足矣覆盖绝大部分磁盘监控需求。vmstat 1
看wa
作为系统级辅助。 - 指标黄金三角: 死死盯住
%util
(繁忙程度),await
(响应延迟),空间使用率
。%util
100% 或await
异常高是立即需要关注的严重信号。空间满则是致命错误。 - 关联分析: 磁盘指标必须与性能测试结果关联! 当
%util
100% 时,TPS 是否暴跌?RT 是否飙升?当await
高时,用户操作是否卡顿?这种关联性是证明磁盘 I/O 是性能瓶颈的核心证据。vmstat
的wa
高是系统级佐证。 - 区分随机与顺序: 理解你的应用 I/O 模式(
iostat
的rareq-sz
/wareq-sz
)。小尺寸(e.g., < 32KB)通常是随机 I/O,对 HDD 极其不友好。大尺寸(e.g., > 128KB)通常是顺序 I/O,HDD 也能较好处理。 - SSD vs HDD: 牢记 SSD 和 HDD 的性能特性差异(IOPS、延迟)。对 HDD 上的随机 I/O 密集型应用要特别警惕。
- 空间监控是底线: 压测前中后务必检查磁盘空间! 空间耗尽会导致测试完全失败,且可能损坏数据。
- 动手实践:
- 用
dd
测试顺序读写性能:dd if=/dev/zero of=./testfile bs=1G count=1 oflag=direct
(写),dd if=./testfile of=/dev/null bs=1G
(读)。观察iostat
。 - 用
fio
(更专业) 模拟不同 I/O 模式(随机读/写,顺序读/写,混合)。观察指标变化。 - 制造空间不足:
fallocate -l 10G bigfile
快速创建大文件填满空间。观察应用和系统反应。
- 用
总结: 零基础快速掌握 Linux 磁盘监控的核心就是 监控设备忙闲 (iostat %util
), 关注响应延迟 (iostat await
), 严防空间耗尽 (df -h
), 揪出高 I/O 元凶 (iotop
),并将这些指标的变化 精准关联 到 TPS、RT 和错误率上。通过几次实际的性能测试,结合这个流程进行分析,你就能快速将磁盘 I/O 监控技能应用到工作中,有效识别和定位存储层的性能瓶颈,为优化提供明确方向。祝你成功!