应用频繁落盘导致I/O瓶颈的本质是进程主动发起大量同步写、日志刷盘或小块随机写堆积；表现为%wa升高、%util持续打满、await拉长，而CPU使用率偏低；排查需先通过top看%wa和loadavg定性，再用iostat -x 2锁定高写磁盘，iotop -o定位狂写进程，最后用lsof和strace追踪其写文件及fsync行为。
应用频繁落盘导致 I/O 瓶颈，本质是进程主动发起大量同步写（如 write() + fsync()）、日志刷盘、或小块随机写堆积所致。这类问题 CPU 使用率往往不高，但系统响应明显卡顿，%wa 升高、磁盘 %util 持续打满、await 显著拉长。排查要从“确认落盘行为”入手，而非仅看资源占用。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
看 %wa 和 loadavg 快速定性是否为落盘阻塞
运行 top，重点关注右上角：
- 若 %wa > 30% 且 %idle 较高（比如 id > 50%），说明 CPU 空闲但大量进程卡在等磁盘返回，高度疑似同步落盘阻塞；
- 同时观察 load average：若 1 分钟值远高于 CPU 核心数（如 4 核机器 load=12），但 %us+%sy 总和不足 30%，基本可锁定是 I/O 队列积压，不是 CPU 过载。
用 iostat -x 2 锁定“被猛写的磁盘”
执行 iostat -x 2（需已安装 sysstat），重点盯三列：
- %util ≥ 90%：该设备已饱和，无法再承接更多请求；
- await > 50ms（尤其对 SSD）：请求排队严重，不只是忙，更是慢；
- w/s 异常高 + wkB/s 相对不高：典型的小块写风暴（如每秒几千次 4KB 写），常见于日志轮转、数据库 WAL 刷盘、或应用未批量写入。
用 iotop -o 找出“真正在狂写”的进程
运行 sudo iotop -o（只显示有实际 I/O 的进程）：
- 按 DISK WRITE 排序（按 P 键），找写速率持续 >1MB/s 或 IO% 占比超 30% 的进程；
- 特别留意 IO> 列数值高的进程——它表示该进程等待 I/O 的时间占比，>70% 说明几乎全程在等磁盘；
- 常见嫌疑对象：Java 应用（logback/log4j 日志同步刷盘）、MySQL（innodb_flush_log_at_trx_commit=1）、Elasticsearch（translog flush）、或自研服务中未加缓冲的 fsync() 调用。
用 lsof 和 strace 追踪落盘源头
拿到可疑进程 PID 后，进一步确认它在写什么、怎么写：
- lsof -p PID | grep "REG.*w"：列出该进程所有以写模式打开的普通文件，重点关注日志路径、数据库事务日志、临时文件；
- sudo strace -e trace=write,fsync,fdatasync -p PID -s 64 2>&1 | head -20：实时抓取它的写系统调用，看是否高频调用 fsync() 或每次只写几十字节就刷盘；
- 若发现大量 write(…, “\n”, 1) + fsync() 组合，基本就是应用层日志配置不当或业务逻辑强制落盘导致。
