当前Dirty占内存百分比=Dirty值÷MemTotal×100，单位均为kB；需对比vm.dirty_ratio阈值判断风险，而非仅看Dirty绝对值。
怎么看当前 Dirty 占内存百分比
直接用 /proc/meminfo 里的 Dirty: 值除以 MemTotal:，再乘以 100 就是实际脏页占比。注意单位全是 kB，别误当成 MB 算错。
常见错误是只看 Dirty: 数值大小，却没和阈值比——比如 Dirty: 250000（≈244MB）看着不大，但若系统有 4GB 内存、vm.dirty_ratio=10，那阈值就是 400MB，此时已占 61%，离阻塞写入只剩不到 40% 余量。
-
cat /proc/meminfo | grep -E "^(Dirty|Writeback|MemTotal)"—— 一次性抓出关键三行 - 手动计算：假设输出是
Dirty: 327680、MemTotal: 8388608（单位 kB），则比例 =327680 / 8388608 * 100 ≈ 3.9% - 别信
vmstat -sm的 dirty 列——它显示的是页数（page），不是字节数，且默认单位不统一，容易误判
怎么查 dirty 触发阈值
Linux 用两个参数控制刷盘节奏：vm.dirty_background_ratio 是后台开始异步刷的起点，vm.dirty_ratio 是前台写入被阻塞的硬上限。这两个值都是百分比，基于 MemTotal 计算。
它们可能被 _bytes 版本覆盖——只要设置了 vm.dirty_background_bytes 或 vm.dirty_bytes，对应 ratio 就自动归零，此时阈值按绝对字节数生效。
- 查当前生效值：
sysctl vm.dirty_background_ratio vm.dirty_ratio vm.dirty_background_bytes vm.dirty_bytes - 如果
vm.dirty_background_bytes非零，说明用的是字节阈值，此时vm.dirty_background_ratio显示为 0，别被它误导 - SSD 上调高
vm.dirty_ratio不一定更稳——脏页积压太多反而导致突发 flush 拖慢响应，尤其在小内存机器上
为什么 sync 后 Dirty: 还不归零
sync 只是触发内核把脏页加入 writeback 队列，并不等所有页真正落盘。实际写入由 flush 内核线程异步完成，受 vm.dirty_writeback_centisecs（默认 500，即 5 秒唤醒一次）和 I/O 负载影响。
你看到 Writeback: 在涨，就说明 sync 已生效，但磁盘还在忙；如果 Writeback: 长时间不降，可能是磁盘写入瓶颈（如机械盘 + 大量随机小文件）或 ext4 日志模式拖慢提交速度。
-
cat /proc/vmstat | egrep "nr_dirty|nr_writeback"可查更底层计数，比/proc/meminfo少一层缓存延迟 -
watch -n 1 'cat /proc/meminfo | grep -E "^(Dirty|Writeback):"'比vmstat -sm更准，刷新快、单位一致 -
drop_caches=3对脏页无效——它只清 page cache 和 slab，dirty page 必须先写盘才能释放
脏数据异常增长时该盯哪些地方
当 Dirty: 持续逼近 vm.dirty_ratio × MemTotal / 100，说明写入压力大或刷盘跟不上。重点排查是否在高频小文件写、日志轮转、数据库 checkpoint 或 NFS 写回策略不当。
别只盯着 df 看磁盘满不满——脏页卡在内存里，df 显示磁盘空闲，但应用写文件会卡住，表现为 “磁盘没满却写不进去”。
- 用
iotop -o -a看哪些进程在持续发起write系统调用（注意看DISK WRITE列的累计值） - 检查
/proc/sys/vm/dirty_expire_centisecs（默认 3000 = 30 秒）——设太大会让脏页滞留过久，增加丢失风险 - 对容器环境，cgroup v1 的
blkio.weight或 v2 的io.weight可能限制 flush 线程带宽，导致脏页堆积
实际观察时，Dirty: 和 Writeback: 的相对变化比绝对值更重要：前者持续上涨、后者长期低于前者，基本就能断定刷盘路径存在瓶颈。
