脏页堆积导致写入卡顿但iostat显示磁盘正常，说明问题在内核页缓存回写调度或存储栈上层阻塞，需通过/proc/meminfo、回写线程stack、/proc/diskstats及iotop等深入定位根因。
脏页堆积引发写入卡顿，但 iostat 显示各磁盘 I/O 利用率（%util、await、r/s、w/s）都正常——这说明问题不在设备层吞吐瓶颈，而在内核页缓存回写调度或存储栈上层阻塞。关键要跳出“看 iostat 找忙盘”的惯性，转向内存子系统和块层队列行为分析。
确认脏页规模和回写压力
先验证是否真由脏页驱动：运行 cat /proc/meminfo | grep -E "Dirty|Writeback|Bounce"，重点关注：
-
Dirty：当前未写回的脏页大小（KB），持续 > 10% 的可用内存（
MemFree + Cached + SReclaimable）就属异常 - Writeback：正在被 pdflush/kswapd 写出的页数，若长期 > 0 且 Dirty 不降，说明回写线程卡住
-
DirtyRatio / DirtyBackgroundRatio（查
/proc/sys/vm/dirty_*）：若 Dirty 接近 DirtyRatio（默认 20%），内核会同步阻塞 write() 系统调用，直接导致应用卡顿
检查回写线程状态和阻塞点
脏页不落盘，往往不是磁盘慢，而是回写路径被阻塞：
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 用
ps aux | grep "[k]worker.*writeback"或pgrep -f "kworker.*writeback"找出回写工作线程 PID - 对 PID 执行
cat /proc/$PID/stack，看是否卡在：
`blk_mq_get_tag` → `sbitmap_queue_wait`（块层 tag 耗尽，常因 NVMe 多队列或 SCSI 中断风暴）
`ext4_writepages` → `ext4_io_submit` → `submit_bio`（文件系统层提交 BIO 卡住）
`wait_on_page_writeback`（等待某页写回完成，可能该页所属 inode 正被锁住） - 同时执行
cat /proc/diskstats，对比各设备的 in_flight 字段（第10列）：若某盘 in_flight 持续 > 0 但 iostat 无 I/O，说明请求卡在队列里没下发，而非设备处理慢
定位具体阻塞设备或路径
iostat “不忙”可能是采样粒度太粗或统计口径偏差，需更底层观测：
- 用
iotop -o -a（-o 只显示有 I/O 的进程，-a 累计 I/O）看哪些进程在持续 submit bio，尤其是kswapd、ksmd、pdflush或业务进程自身 - 启用 block trace：
echo 1 > /sys/block/$DEV/queue/iostats（确保开启），再用cat /sys/block/$DEV/stat查看更细粒度：第9列（# of reads merged）、第13列（# of writes merged）突增，说明 bio 合并失败，常因文件系统碎片或块层限流；第10列（# of I/Os currently in progress）高而第11列（time in queue）低，说明请求在队列中等待调度 - 若使用 LVM 或 mdadm，检查底层物理盘：
lvs -o +stripes,stripesize或mdadm -D /dev/mdX，条带配置不合理（如 stripe size 过小）会导致大量小写无法合并，触发高频脏页回写
临时缓解与根因收敛
应急可降低脏页触发阈值，避免同步阻塞：
-
echo 5 > /proc/sys/vm/dirty_ratio（激进，慎用） -
echo 2 > /proc/sys/vm/dirty_background_ratio（让后台回写更早启动） -
echo 1000 > /proc/sys/vm/dirty_expire_centisecs（缩短脏页存活时间）
但根本解决需结合 stack 和 iostats 定位到具体模块：是 ext4 journal 阻塞？NVMe 控制器中断丢失？还是 cgroup blkio 限流导致队列积压？找到 stack 中最深的非通用函数（如 nvme_queue_rq、dm_table_presuspend_targets），即为根因所在模块。
