linux磁盘性能评估核心是await（平均i/o耗时），hdd超15ms、sata ssd超2ms、nvme超0.5ms需警惕；%util持续>80%且await高表明i/o瓶颈；r/s、w/s反映随机iops，rkb/s、wkb/s反映吞吐，单位需区分mb/s与mib/s；应结合iostat -dx、iotop -o及fio测试定位真实瓶颈。
Linux 文件系统性能评估，核心是看 I/O 延迟是否可控、吞吐是否稳定，而不是单纯追求峰值数字。真实业务中，低延迟比高吞吐更影响用户体验，尤其在数据库、API 服务等场景。
盯住这几个关键指标
别被“MB/s”或“IOPS”数字带偏，先确认实际瓶颈在哪：
- await（平均等待时间）：iostat 输出里最该盯的字段。HDD 超 15ms、SATA SSD 超 2ms、NVMe 超 0.5ms 就值得查；若 await 远大于 svctm，说明请求在队列排队，不是磁盘慢，是并发压太狠
- %util：持续 >80% 且伴随高 await，基本可判定为 I/O 瓶颈源头；但 %util 接近 100% 不等于磁盘坏，可能是调度器或队列深度限制了并发能力
- r/s 和 w/s：对应随机读写 IOPS，4K 随机读写比 1M 顺序写更能反映数据库类负载的真实压力
- rkB/s 和 wkB/s：对应吞吐量，注意单位是 MB/s（十进制）还是 MiB/s（二进制），差约 7%，报告时需统一
用对工具，测出真实性能
绕过缓存、控制变量，才能测出磁盘本身能力：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
-
dd 测基础吞吐：适合快速摸底，但只反映单线程顺序性能
写入：dd if=/dev/zero of=testfile bs=1M count=1024 oflag=direct
读取：dd if=testfile of=/dev/null bs=1M iflag=direct -
fio 测真实负载：必须用，支持随机/顺序、不同块大小、多队列深度
例如测 4K 随机读：fio -name=randread -filename=/dev/sdb -rw=randread -bs=4k -iodepth=64 -direct=1 -runtime=60 -group_reporting -
iostat 实时监控：
iostat -dx 2每 2 秒刷新，重点关注 await、%util、r/s、w/s；搭配iotop -o可快速定位哪个进程在猛刷磁盘
延迟高？先查调度器和队列
很多“慢”其实不是磁盘问题，而是内核调度策略没对上硬件特性：
- NVMe 盘优先用 noop 或 mq-deadline；传统 HDD 可试 deadline 或 bfq
- 查当前调度器：
cat /sys/block/sda/queue/scheduler，括号里带 [ ] 的是当前生效的 - 临时切换：
echo mq-deadline > /sys/block/sda/queue/scheduler（需 root） - 队列深度不够会卡并发：SSD 可设
echo 128 > /sys/block/sda/device/queue_depth；NVMe 还可调/sys/block/nvme0n1/queue/nr_requests
挂载参数直接影响延迟表现
文件系统不是装完就完事，几个挂载选项能明显压低延迟：
-
ext4：加
noatime,nodiratime,barrier=0,data=writeback（仅限非关键数据环境）；commit=30可降低日志刷盘频率 -
XFS：推荐
nobarrier,logbsize=256k，大日志块提升元数据写入效率 - 所有类型都建议避免默认的
atime更新，它会在每次读文件时写磁盘，对小文件密集型负载伤害很大
