linux服务器读写性能怎么看
想查linux服务器的读写性能，最直接的办法是跑一遍iostat看await和util两个指标，再用fio或者dd实测一次读写速度，两个结果交叉对比就能定位瓶颈。这活儿我干过几百次，今天就手把手教你把这几条命令用明白。
linux服务器读写性能检测：五大常用命令实测
iostat：最基础的读写性能体检工具
iostat是sysstat包里的命令,几乎每个linux发行版都自带，它的核心输出有三列你得盯紧：await（平均IO等待时间）、svctm（IO服务时间）、util（设备忙碌百分比）。
安装方式：
# Ubuntu/Debian系 apt install sysstat -y # CentOS/RHEL系 yum install sysstat -y
跑一次看整体：
iostat -x 1 5
这个命令每秒刷新一次,连续输出5次。-x参数展开所有设备明细，你会看到每个磁盘的读写性能状态。
iotop：盯着单个进程吃掉的IO
iostat看的是磁盘整体,你要想知道哪个进程在疯狂读写，就得靠iotop：
iotop -o -P
-o参数只显示正在做IO操作的进程，-P把线程合并成进程展示，这个命令适合排查”服务器读写性能突然下降是被谁拖垮的”这类问题。
pidstat：按进程精确统计IO
pidstat是sysstat包另一个利器,直接按PID统计：
pidstat -d 1
输出里能看到每个进程每秒的KB读写量,定位问题进程比iotop更省眼睛。
hdparm：只测纯硬盘读取速度
测物理硬盘的纯读取极限，hdparm是元老级命令：
hdparm -Tt /dev/sda
-T测缓存读取速度，-t测缓冲读取速度，不过hdparm测的是裸设备读速度，不经过文件系统，跟实际文件读写性能有差距，这个数据只能做参考。
怎么看这些命令的结果
业内专家指出,综合使用这几个工具的效果远好于单独依赖任何一个，我总结了一套判断逻辑：
- util超过80%：磁盘差不多满负荷了，想再加读写性能只能换硬件
- await比svctm高出一大截：大概率是排队等IO，说明并发请求太多
- util不高但await很高：磁盘本身没问题，可能是文件系统或者锁的问题
- 随机读写性能远远低于顺序读写：这是机械硬盘的物理特性，别优化错了方向
linux磁盘io读写速度慢，怎么快速定位瓶颈
第一步：确认瓶颈在IO还是CPU
这个顺序不能乱,先用top看CPU的wa占比：
top -b -n 1 | head -5
wa列超过30%就说明系统在花大把时间等磁盘IO，读写性能确实拉胯，wa不高但应用还是卡，那问题大概率出在应用层或网络层。
第二步：用iostat的await指标判断瓶颈类型
iostat -x 1这组数据看三个关键值：
| 指标 | 正常范围（SSD） | 正常范围（机械盘） | 含义 |
|---|---|---|---|
| rrqm/s | 低 | 低 | 每秒合并的读请求数 |
| wrqm/s | 低 | 低 | 每秒合并的写请求数 |
| await | <10ms | <20ms | IO请求平均等待时间 |
| util | <80% | <60% | 设备忙碌占比 |
await超过200ms甚至500ms，那基本可以断定磁盘IO负载已经爆了。
第三步：用fio做压力测试拿到准确读写性能极限
fio是业界公认的linux服务器读写性能测试标杆工具，比dd精确得多，安装：
yum install fio -y # CentOS系 apt install fio -y # Ubuntu系
测顺序读：
fio --name=seqread --rw=read --bs=128k --size=1G --numjobs=1 --iodepth=32 --direct=1
测随机写：
fio --name=randwrite --rw=randwrite --bs=4k --size=1G --numjobs=1 --iodepth=32 --direct=1
–direct=1一定要加，它绕过文件系统缓存，测的是磁盘真实性能，如果把缓存算进去，数据会虚高，排查问题的时候容易被误导。
第四步：判断随机读写还是顺序读写是重点
不同业务场景对读写性能的侧重点完全不同：
- 数据库场景：随机读写性能更重要，尤其是4k小文件的随机写
- 日志采集场景：顺序写性能是瓶颈，追求的是持续吞吐
- 视频点播场景：顺序读性能决定体验，带宽和IO要一起看
- 混合负载场景：用fio直接跑混合读写比瞎猜靠谱
linux服务器io性能测试工具对比：dd、fio、iostat一篇文章讲透
dd命令：简单粗暴但数据不够精确
dd大概是接触最多的读写测试命令：
dd if=/dev/zero of=testfile bs=1G count=1 oflag=direct
结果里的传输速度就是顺序写性能，但dd有个大问题：它测的是顺序、大块、单线程，真实业务很少这么跑，所以dd的结果只能作为参考，不能作为磁盘读写性能的最终结论。
fio命令：专业压测，模拟真实业务读写模型
fio可以用配置文件模拟出接近真实业务的负载模型,举个例子，模拟MySQL的redo log写入：
[mysql-redo] rw=write bs=4k direct=1 iodepth=1 size=1G numjobs=8 runtime=60
fio的优势在于灵活控制队列深度、块大小、并发数，ioengine还能选libaio或者sync模式，模拟不同的IO调度行为。
iostat命令：监工角色，持续观察跑业务时的读写表现
fio测完理论知识,iostat负责实际业务运行时持续观察：
iostat -x /dev/sda 1 10
这种组合拳打下来,linux服务器的读写性能到底怎么样，心里就有底了，记住一句话：fio告诉你盘能干多快，iostat告诉你盘目前过得好不好，dd用来做快速粗略判断。
工具选择速查表
| 场景 | 推荐工具 | 看什么指标 |
|---|---|---|
| 刚拿到一台服务器，快速验证 | dd | 传输速度 |
| 给数据库做IO性能评估 | fio | IOPS、延迟、95分位延迟 |
| 线上服务卡顿，现场排查 | iostat + iotop | await、util、进程IO占用 |
| 对比两块盘性能差异 | fio，全套参数跑一遍 | 随机/顺序读写分别对比 |
| 写技术方案需要量化数据 | fio + iostat | 多维度数据交叉引用 |
linux服务器读写性能监控与调优实操
用iostat持续监控，设置告警阈值
监控linux服务器读写性能不能靠肉眼盯,得写成脚本：
while true; do
iostat -x 1 3 | grep -v "^$" | awk '/sd[a-z]/ {print strftime("%Y-%m-%d %H:%M:%S"), $1, "await:", $10, "util:", $12}'
sleep 5
done
util超过80%持续30秒以上就该考虑优化了，无论SSD还是HDD。
根据读写性能瓶颈做针对性调优
观察一段时间后发现瓶颈所在,按下面的思路处理：
- 磁盘IOPS不够（随机读写场景）：换SSD存量升级，或者把热点数据放到内存（Redis/PageCache）
- 吞吐量不够（顺序读写场景）：检查RAID组策略，多数情况RAID10比RAID5性能好
- 单盘延迟高：确认是不是HDD快满了，机械盘剩10%空间后性能断崖下跌
- IO调度器配置不合适：SSD建议用none或mq-deadline，HDD建议用bfq或mq-deadline
- 文件系统挂载参数没优化：noatime挂载，降低写放大对IO的影响
vim /etc/fstab # 修改挂载参数示例 /dev/sdb1 /data ext4 defaults,noatime,nodiratime 0 0
改完记得mount -o remount /data生效。
队列深度和并发数的设置技巧
fio测出来的峰值性能不代表业务真能吃满,队列深度（iodepth）设置很重要，SSD通常建议16到32，HDD建议8到16，太深会导致延迟飙升，太浅发挥不出硬件实力。
很多linux服务器读写性能问题不是硬件不行,是应用层并发模型和磁盘不匹配，数据库连接池、消息队列批量消费、日志异步写入，这些令牌桶、批量任务的并发数设置都会直接影响底层IO的堆积程度。
影响读写性能的隐藏因素排查
文件系统选择对读写性能的影响
ext4、xfs、btrfs各有擅长。XFS配大文件顺序读写性能更好，ext4胜在稳定成熟，如果要做快照，btrfs或有特殊需求，考虑走ZFS，这层选错了，性能怎么调都白搭。
内核IO调度器参数调整
查看当前调度器：
cat /sys/block/sda/queue/scheduler
临时切换（重启失效）：
echo none > /sys/block/sda/queue/scheduler
永久生效用udev规则或grub参数,SSD用none跳过调度，HDD保留deadline或bfq。
注意检查磁盘健康状态
磁盘硬件有问题,读写性能也会明显下降，跟负载高是两回事：
smartctl -a /dev/sda dmesg | grep -i "I/O error"
Reallocated_Sector_Ct数值不为0，这盘已经在退化路上了，性能下降是迟早的事。
linux服务器读写性能常见问题解答
iostat里await和svctm的区别是什么
await是IO请求从进入到完成的总时间,包括排队时间，svctm是设备真正处理IO所花的时间。两者差距大，说明IO请求都在排队等处理，本质是并发请求超过磁盘处理能力。
为什么dd测出来速度很快但线上业务就是卡
dd测的是顺序单线程大块IO,业务跑的是随机多线程小块IO，况且dd默认会占缓存，数据根本没落盘。跑dd务必加oflag=direct绕过缓存，或者用fio做随机读写测试，才能反映真实的linux服务器读写性能。
用fio测IOPS，random读的IOPS低是不是盘不行
不一定,IOPS和队列深度、块大小强相关。4k随机读用iodepth=1和iodepth=64测出来的IOPS差好几倍，先确认自己的并发模型，再对标测试参数，业务并发低去追高IOPS本身就是个误区。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/790905.html
