kswapd0 长期处于 D 状态并频繁触发 vmpressure，主因是 I/O 阻塞（如慢速 swap 设备、dirty page 未刷盘或文件系统元数据阻塞），vmpressure 仅为内存回收压力的信号而非原因；需通过栈追踪、iostat 和 /proc/swaps 综合诊断。

为什么 kswapd0 会卡在 D 状态且持续触发 vmpressure？

kswapd0 是内核的异步内存回收线程，D 状态（uninterruptible sleep）本身正常，但长期卡住说明它正在等待 I/O 完成——通常是 swap 设备写入慢或阻塞。此时 vmpressure 事件频繁上报，不是原因而是信号：内核检测到页面回收压力陡增，已开始向用户态（如 systemd、low-memory-killer）广播内存紧张信号。

常见诱因包括：

• swap 分区位于高延迟设备（如机械盘、USB 盘、网络块设备）
• swap 被禁用但 vm.swappiness=100 或类似配置仍驱使内核积极换出匿名页
• 存在大量 dirty page 未刷盘，kswapd0 在 wait_event() 中等 writeback 完成
• ext4/xfs 文件系统在日志提交或元数据更新时阻塞页回收路径

vmpressure 事件是否真的代表该杀进程？

不一定。Linux 的 vmpressure 是分等级的信号（low/medium/critical），仅 critical 才暗示 OOM 风险临近。很多容器运行时或 systemd 服务会监听 medium 就提前释放缓存或降级服务，造成误判。

验证方法：

• 查实时压力等级：cat /proc/vmstat | grep -i vmpressure
• 看当前状态：cat /sys/fs/cgroup/memory/memory.vmpressure（cgroup v1）或使用 systemctl show --property=MemoryPressure（systemd v249+）
• 注意：若 vmpressure 持续为 medium 但 MemAvailable > 500MB，大概率是回收路径被阻塞，而非真缺内存

如何快速判断是不是 swap I/O 卡死？

直接看 kswapd0 的栈和 I/O 等待目标：

• 获取线程栈：cat /proc/$(pgrep kswapd0)/stack，若末尾是 __swap_writepage、submit_bio 或 wait_on_page_writeback，基本锁定 swap 写入阻塞
• 检查 swap 设备状态：swapon --show=NAME,TYPE,SIZE,USED,PRIORITY，再用 iostat -x 1 观察对应设备的 %util 和 await
• 确认 swap 是否启用：若 free -h 显示 Swap: 全为 0，但 /proc/swaps 非空，可能是 swa

  

  p 分区已 disable 但未 umount，残留脏页无法回收

典型错误配置：vm.swappiness=200（超出合法范围 0–100），会导致内核行为异常，部分版本会静默截断为 100，但某些补丁分支可能引发回收逻辑紊乱。

临时缓解与根治建议

临时手段只能绕过阻塞点，不能替代诊断：

• 紧急停用低效 swap：swapoff /dev/sdXN（确保 Free + Buffers + Cached > 当前 SwapUsed，否则触发 OOM Kill）
• 降低回收激进度：sysctl vm.swappiness=10（避免过度换出）
• 加速脏页落盘：sysctl vm.dirty_ratio=20 && sysctl vm.dirty_background_ratio=10（防止脏页堆积拖慢 kswapd0）

根治必须定位 I/O 瓶颈：如果是 NVMe 盘却出现高 await，检查是否启用了 nomerges 或驱动 bug；如果是 LVM 上的 swap，确认 lvconvert --repair 无元数据损坏；容器环境则需检查是否绑定了慢速 host swap 而非使用 memory cgroup 限流。

最容易被忽略的一点：即使你没配 swap，kswapd0 仍会活跃——它负责所有 page reclaim，包括 slab、page cache 和匿名页。D 状态卡住，往往不是 swap 本身的问题，而是底层块层或文件系统在某次 writeback 中死锁或响应超时。