大文件并发写入导致磁盘瓶颈的典型表现是系统响应变慢、iowait飙升（如top中wa>60%）、写入延迟激增但cpu使用率低；排查需分四步：先用iostat -dx 1 5看%util≥95%、await远大于svctm、avgqu-sz>10及高w/s+wkb/s确认写饱和；再用iotop -op或pidstat -d 2 5定位高io进程；接着用lsof -p pid或ls -l /proc/pid/fd/查其写入的具体文件路径，重点关注/tmp、/var/log、/data等目录；最后结合avgrq-sz判断顺序写（>64kb）或伪随机写（4–16kb），并检查dirty_ratio参数是否引发写放大。
大文件并发写入时出现磁盘瓶颈，典型表现是系统响应变慢、iowait 飙高（比如 top 中 wa > 60%）、应用写入延迟激增，但 CPU 使用率并不高。排查重点不是“有没有写”，而是“谁在写、怎么写、写到哪、设备扛不扛得住”。下面分四步直击关键。
看整体磁盘压力：用 iostat 定性是否真饱和
执行 iostat -dx 1 5，重点关注这几列：
- %util ≥ 95%：设备几乎持续忙于处理请求（注意：SSD/云盘下该值参考性下降，需结合 avgqu-sz 和 await）
- await 远大于 svctm（例如 await=80ms，svctm=0.15ms）：说明请求大量排队，不是磁盘处理慢，而是压得太满
- avgqu-sz 持续 > 10（机械盘队列深度通常为 32，NVMe 可达数百）：队列已堆积，是排队瓶颈的强信号
- w/s 高 + wkB/s 高：确认是写密集型负载，而非读或混合
定位写入主力进程：用 pidstat 或 iotop 锁定源头
若环境有 iotop，直接运行：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
-
iotop -oP：只显示正在 IO 的进程（-o），且以进程为单位（-P），避免线程干扰 - 关注 DISK WRITE 列，排序后看前 2–3 名是否为你的业务进程（如 java、python、mysqld）
若容器或精简系统无 iotop，用 pidstat：
-
pidstat -d 2 5：每 2 秒采样一次，输出各进程的读写 KB/s - 配合
ps -p PID -o comm=,cmd=快速确认进程用途
查它在写什么文件：从进程找具体路径
拿到高 IO 进程 PID 后，查它打开的写入文件：
-
lsof -p PID | awk '$4 ~ /[0-9]+[uw]/ && $5 ~ /REG/ {print $9, $4}' | head -10：列出该进程打开的普通文件及其读写模式（w=写，u=读写） -
ls -l /proc/PID/fd/ | grep -E '->.*\.log|->.*data|->/tmp'：快速过滤日志、数据、临时目录类路径 - 特别注意：/tmp、/var/log、/data、挂载点子目录——大文件写入常集中在这几处
判断写入模式与优化方向：顺序 or 随机？缓存是否被拖垮？
继续用 iostat 看请求特征：
iostat -x 1 3 | awk '/sda/ {print "rq-size:", $10, "await:", $11}'- avgrq-sz > 64KB → 大块顺序写（如 tar 归档、数据库 bulk insert），瓶颈大概率在带宽或后端存储吞吐
- avgrq-sz ≈ 4KB–16KB → 实际是大量小写合并成大文件（如日志轮转、分片上传），本质仍是随机写压力，寻址开销大
- 再看
cat /proc/sys/vm/dirty_ratio和dirty_background_ratio：若业务突发写入远超 dirty_background_ratio（默认 10%），内核会主动刷脏页，造成写放大——此时降低 dirty_ratio 反而可能加剧抖动，应优先控制应用写节奏
