报错是这么冒出来的。一台 2 核 4G 的轻量服务器按教程装了 zram-tools，swapon 显示 2G 的 zram0，但 SwapCached 一直是零，kswapd 和压缩线程 CPU 反而占到三成。
中间走过弯路，把「vm.swappiness 还是默认值，内核更愿意丢页缓存而不是压缩换出」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。zram 是把内存压缩后当作块设备，swap 统计里看不到实际换出量。还有一种是压缩算法用的 lzo 在高负载下比 lz4 更耗 CPU。
还有一种情况，zram 容量按内存一半设置，业务内存吃紧时压缩比很低，收益有限。
动手时先确认 zram 的容量与压缩算法
zramctl && cat /sys/block/zram0/comp_algorithm随后换成压缩更快的算法
echo lz4 > /sys/block/zram0/comp_algorithm接着让内核更积极使用 swap，减少无效回收
sysctl -w vm.swappiness=100剩下的就是看压缩比与真实节省量
cat /sys/block/zram0/mm_stat && free -m别只看报错消失，验证要多做一步。zramctl 显示 DATA 与 MEM 的压缩比在 2 以上，系统可用内存比开启前多出几百 M，kswapd 和压缩线程的 CPU 占比回落到一成以内。
这里还有个坑。zram 不是免费的内存，压缩和解压都要占 CPU，小机器上优先怀疑业务本身的内存开销；swappiness 调到 100 只适合纯 zram 场景。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。