Linux磁盘读写慢需四步排查：先用iostat确认硬盘负载，再用iotop定位高IO进程，接着用lsof和strace分析具体读写文件及系统调用，最后检查IO调度器匹配性与硬盘健康状态。
Linux磁盘读写慢，不能只盯着“换硬盘”或“加内存”，得先理清IO路径上的关键节点：是不是硬盘真忙？谁在猛写？写的是什么？调度策略配对了吗？硬件本身还健康吗？下面四步层层递进，帮你把问题从表象挖到根上。
确认硬盘是否真的处于高负载
别凭感觉判断“慢”，先看数据。运行 iostat -x 1，重点关注三列：
- %util：持续接近或超过95%，说明磁盘基本满负荷运转；
- await：平均每次I/O请求等待时间，超过20ms就值得警惕，超50ms大概率存在瓶颈；
- r/s 和 w/s：每秒读/写请求数，结合设备类型看是否合理（比如机械盘随机写超100 IOPS就已吃紧）。
如果 %util 很低但 await 很高，可能是队列堆积或调度策略不匹配；如果 %util 高且 r/w 频繁，就要往下查是哪个进程在驱动这些IO。
定位高IO消耗的进程
用 iotop -o（只显示正在做IO的进程），按I/O%列排序，一眼就能揪出“IO大户”。重点关注：
- 进程名是否合理（如 mysqld、rsync、java 应用、日志轮转脚本）；
- 读写速率（B/s）是否异常（例如一个后台脚本持续写入200MB/s）；
- 是否处于 D 状态（不可中断睡眠），这往往意味着它卡在底层IO上，需结合栈信息进一步分析。
确认PID后，别急着kill，先保留现场：记录时间点、命令行（ps -fp PID）、打开文件（下一步要用）。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
分析进程到底在读写哪些文件
拿到PID，执行 lsof -p PID | grep -E "(REG|DIR)"，筛选出普通文件和目录。重点看：
- 大日志文件（如 /var/log/messages、应用自定义log）是否被反复truncate或追加；
- 数据库数据文件（如 /var/lib/mysql/xxx.ibd）或WAL日志（如 pg_wal/）是否持续刷写；
- 临时文件（/tmp、/var/tmp）是否被频繁创建删除，可能暴露应用设计缺陷。
再配合 strace -p PID -e trace=write,open,fsync 短时抓取系统调用，能看清是写小块还是大块、是否频繁fsync——这对后续调优（如调整innodb_flush_log_at_trx_commit或禁用atime）直接有用。
检查并优化IO调度与硬件状态
这一步分两线并行：
-
调度器是否匹配硬件：
运行 cat /sys/block/sda/queue/scheduler，括号里标出当前生效算法。原则很明确：
– SSD/RAID/NVMe → 选 noop 或 kyber（较新内核）；
– 机械盘跑数据库 → 选 deadline；
– 多用户共享服务器（如Web+FTP）→ 可试 cfq 或现代替代 bfq。
临时切换：echo deadline > /sys/block/sda/queue/scheduler；永久生效需改GRUB参数 elevator=deadline 并更新配置。 -
硬盘本身是否可靠：
用 smartctl -a /dev/sda 查看Reallocated_Sector_Ct、Pending_Sector等关键SMART值；
用 badblocks -v /dev/sda1（需卸载）扫描坏道；
若发现大量重映射扇区或读取超时，备份后换盘是唯一稳妥方案。
顺手还可调两个实用参数：
– 提高预读量（适合顺序读大文件）：echo 8192 > /sys/block/sda/queue/read_ahead_kb；
– 增大队列深度（提升并发吞吐）：echo 512 > /sys/block/sda/queue/nr_requests。
