大文件连续读写导致总线饱和本质是I/O请求在SATA/NVMe总线或RAID控制器堆积，表现为命令卡死、SSH延迟、%util≥95%、avgqu-sz>4（SSD）或>2（HDD）、await>50ms且CPU内存正常；需按“确认总线瓶颈→锁定高吞吐进程→分析数据流向→验证硬件通路”四步排查。
大文件连续读写导致总线饱和，本质是磁盘 I/O 请求在底层传输通路（如 SATA、NVMe 总线或 RAID 控制器）上堆积，引发系统级延迟——表现为 命令卡死、SSH 响应极慢、iostat 中 %util 接近 100% 且 avgqu-sz 持续高位、await 显著升高，但 CPU 和内存使用率可能正常。排查需从“确认总线瓶颈 → 锁定高吞吐进程 → 分析数据流向 → 验证硬件通路”四步展开。
第一步：确认是否为总线级饱和而非普通 IO 瓶颈
仅看 %util 不够，要结合队列深度和响应时间交叉验证：
- 运行 iostat -dx 1，重点观察三项：
• %util ≥ 95%：磁盘设备层已满负荷；
• avgqu-sz > 4（SSD）或 > 2（HDD）：I/O 队列持续积压，说明请求发出去了但没被及时处理；
• await > 50ms 且随负载上升而陡增：不是磁盘慢，是通路堵——总线或控制器成为瓶颈。 - 对比 dstat -d -r -n 1 输出：
若 rMB/s + wMB/s 接近磁盘标称带宽上限（如 SATA III 理论 600MB/s，实测持续 > 500MB/s），同时 read/s + write/s（IOPS）并不高，说明是大块顺序读写占满带宽，而非小 IO 扰乱队列。
第二步：定位发起大块读写的进程
iotop 能看到速率，但要识别“大文件连续读写”，需关注吞吐量和访问模式：
- 执行 sudo iotop -o -P（-P 按进程非线程聚合）：
• 重点看 DISK READ/WRITE 列数值是否稳定在几十甚至上百 MB/s（非瞬时峰值）；
• 若某进程如 dd、rsync、mysqld、tar 或备份脚本长期维持 80+ MB/s 写入，即为嫌疑对象。 - 进一步确认其操作的文件类型：
• lsof -p PID | grep REG | head -5 查看打开的普通文件；
• 若输出中出现 /backup/full_20261009.img、/var/lib/mysql/ibdata1、/data/archive.tar.gz 等大文件路径，基本坐实。
第三步：检查数据路径是否经过共享总线或瓶颈控制器
大文件吞吐受限于最弱一环，常见瓶颈点包括 SATA 多盘共用通道、NVMe 共享 PCIe 通道、RAID 卡缓存耗尽或降级：
- 查磁盘拓扑：
• lshw -class disk -short 或 lsblk -t 观察 ROTA（旋转盘）、SCHED（IO 调度器）、ALIGNMENT；
• 对 NVMe 盘，运行 lspci | grep -i nvme 看是否多盘挂同一 PCIe Root Port（带宽共享）。 - 查 RAID/控制器状态：
• 若用硬件 RAID：megacli -AdpAllInfo -aALL（LSI）或 storcli /c0 show（Broadcom）看 Controller Memory Usage、Battery/Capacitor Status、Current Cache Policy；
• 缓存关闭或电容故障会导致所有写入直落盘，瞬间打满总线。
第四步：验证与临时缓解
确认后快速验证是否总线饱和所致，而非应用逻辑问题：
- 暂停可疑进程：
• kill -STOP PID（安全暂停，不丢数据），观察 iostat 中 avgqu-sz 是否快速回落、await 是否回归 5–10ms；
• 若立即缓解，说明该进程确实是总线压力源。 - 降低单次 IO 大小（治标）：
• 对 dd 类操作，加 bs=1M（而非 64M）可减少单次占用时间，缓解突发拥塞；
• 对 rsync，加 --bwlimit=50000（单位 KB/s）限速。 - 检查内核日志是否有通路告警：
• dmesg -T | grep -i "timeout\|reset\|link down\|nvme.*busy"，出现 "nvme 0000:01:00.0: I/O 34567 timeout" 是典型总线或固件问题。
