同步写入卡顿无法通过iostat的%util或await定位，因其阻塞发生在内核vfs层或日志提交阶段，进程处于d状态，而iostat仅统计设备实际处理的i/o，不反映内核路径等待。
同步写入（sync write）导致的性能瓶颈，不能靠 iostat 的 %util 或 await 直接定位——它反映的是设备层负载，而 sync 写入卡在内核 vfs 层或日志提交阶段时，磁盘指标可能正常，但应用线程却卡在 UNINTERRUPTIBLE（D 状态）。
为什么 iostat -x 1 看不到 sync 写入卡顿
同步写入要求数据真正落盘（或至少 journal 提交完成），内核会阻塞调用线程直到完成。此时进程状态是 D（不可中断睡眠），iostat 只统计设备实际处理的 I/O，不体现内核路径上的等待。常见现象包括：
- 应用日志里频繁出现
write() returned -EAGAIN或超时，但iostat显示 %util -
ps aux中大量进程状态为D，且WCHAN列显示__io_wait、ext4_sync_file或jbd2_log_wait_commit - 写入吞吐量远低于磁盘理论带宽，
iotop却看不到高 I/O 进程
用 pidstat -d 1 和 ps 定位 sync 写入阻塞点
重点不是看“谁在读写”，而是看“谁在等写完成”。pidstat -d 默认只统计实际发出的 I/O，需配合状态过滤：
- 运行
pidstat -p ALL -d 1，观察Blk_writ/s低但%CPU高的进程 —— 这类进程很可能在反复重试 sync 写入 - 立即执行
ps -eo pid,comm,wchan:20,state,ppid,%cpu,%mem,etimes --sort=-etimes | head -20，重点关注state=D且wchan含ext4、jbd2、__sb_start_write的进程 - 对可疑 PID 执行
cat /proc/<pid>/stack</pid>，确认栈顶是否为ext4_sync_file、log_wait_commit或generic_file_write_iter
检查 ext4/xfs 日志与挂载选项是否放大 sync 开销
sync 行为受文件系统类型和挂载参数直接影响，同一 workload 在不同配置下延迟可差 10 倍：
- ext4 下，
data=journal模式强制所有写入先写 journal，再写 data block，sync 路径最长；data=ordered（默认）只 journal 元数据，但 sync 仍需等元数据落盘；data=writeback最快，但崩溃后一致性最弱 - xfs 无 data= 选项，但
logbsize（日志块大小）过小（如 16k）会导致频繁日志刷盘，logbufs过少（如 2）会加剧 commit 竞争 - 检查当前挂载：运行
findmnt -t ext4,xfs -o SOURCE,TARGET,FSTYPE,OPTIONS，确认是否含barrier=1（默认开启）、commit=30（影响 sync 时机）等 - 临时验证：对测试目录 remount 加
noatime,nobarrier（仅测试！），观察 sync 延迟是否显著下降
用 perf record -e 'syscalls:sys_enter_fsync' -a sleep 10 抓 sync 热点
直接追踪 fsync/fdatasync 系统调用开销，比看平均延迟更准：
- 运行
perf record -e 'syscalls:sys_enter_fsync' -a -g sleep 10，然后perf report --no-children - 若 top 函数是
ext4_sync_file或xfs_file_fsync，说明瓶颈在文件系统层；若是__x64_sys_fsync→do_fsync→filp_close，则可能是应用层频繁 close + open 导致隐式 sync - 注意：
fsync()调用本身不耗时，耗时在它触发的 journal 提交或 barrier 刷盘；所以 perf 只能定位“谁在调”，不能替代/proc/<pid>/stack</pid>看“卡在哪一行”
真正难的不是发现 sync 写入慢，而是区分它是被慢盘拖累，还是被日志锁、inode 锁或 page cache 回写风暴卡住——这些都得靠 /proc/<pid>/stack</pid> 和 perf 栈回溯交叉验证，而不是盯着 iostat 的数字猜。
