KSM是否在起作用及是否为真凶，可通过grep -H '' /sys/kernel/mm/ksm/pages_*查看pages_shared、pages_sharing和pages_to_scan：若pages_sharing远高于pages_shared（如10倍以上），说明KSM扫描活跃但合并效率低，极可能引发宿主机周期性卡顿。
怎么看KSM是否在起作用，以及它是不是真凶
KSM（Kernel Samepage Merging）是内核级内存去重机制，对KVM超分环境很关键，但它本身会吃CPU、锁页表、触发软中断——当它过度活跃时，宿主机就会周期性卡顿，表现和“磁盘IO高”或“CPU sys高”高度相似。别急着关KSM，先确认它是不是真在干活：grep -H '' /sys/kernel/mm/ksm/pages_* 这条命令能一次性看到所有KSM状态页。重点关注三个值：pages_shared（已合并页数）、pages_sharing（当前共享页数）、pages_to_scan（每轮扫描页数）。如果pages_sharing远高于pages_shared（比如10倍以上），说明KSM正在疯狂扫描但合并效率极低，大概率已在拖慢系统。
为什么KSM会让宿主机卡顿，而不是只影响虚拟机
KSM运行在宿主机内核态，扫描和合并操作需要遍历所有匿名页、加锁、调用try_to_merge_two_pages，这个过程会：
- 持续占用一个CPU核心（mpstat -P ALL 1里能看到某个核%sys持续偏高）
- 触发大量softirq（cat /proc/softirqs | grep -i 'SCHED\|TIMER'可验证）
- 阻塞其他内存管理路径，比如balloon回收或页面分配，导致vmstat中pgmajfault突增
- 更隐蔽的是：KSM扫描期间会临时禁用页面迁移，干扰NUMA本地性，让原本跑得顺的虚拟机突然掉性能
怎么临时停用KSM验证是否为根因
停KSM不是直接改配置文件，而是运行时开关，且必须分两步：
- 先停止扫描：echo 0 > /sys/kernel/mm/ksm/run（这步立刻生效，pages_sharing会快速归零）
- 再释放已合并页：echo 0 > /sys/kernel/mm/ksm/merge_across_nodes（可选，但建议做，避免残留影响）
停完观察5分钟：vmstat 1 5看cs（上下文切换）和in（中断）是否回落；top看%sy是否从20%+降到5%以内。如果卡顿消失，基本锁定KSM。注意：不要长期关闭，它对内存超分仍有价值，重点是调参而非禁用。
调低KSM扫描强度比完全关闭更稳妥
真正的问题往往不是KSM存在，而是它太“勤快”。默认/sys/kernel/mm/ksm/pages_to_scan是100，/sys/kernel/mm/ksm/sleep_millisecs是20，意味着每20ms扫100页——对8核宿主机来说，这相当于每秒主动制造500次内核调度压力。建议改为：
- echo 10 > /sys/kernel/mm/ksm/pages_to_scan（每次只扫10页）
- echo 100 > /sys/kernel/mm/ksm/sleep_millisecs（间隔拉长到100ms）
- 同时确保/sys/kernel/mm/ksm/merge_across_nodes为0（避免跨NUMA节点合并，减少延迟）
这些值不需重启，立即生效。调完后用watch -n 1 'grep -H "" /sys/kernel/mm/ksm/pages_*'盯几分钟，确认pages_sharing缓慢上升但不再剧烈抖动。
真正难的不是发现KSM在作祟，而是它和内存气球、NUMA绑定、QEMU版本特性耦合太深——比如某些4.19内核+QEMU 5.2组合下，KSM与virtio-balloon争抢页面锁会导致D状态进程堆积。这种时候ps aux | awk ' ~ /D/'比任何指标都管用。
