zram 压缩内存 Swap 实战指南4GB 服务器加了内存压缩层之后不再卡死【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux凌晨两点一台 4GB 内存的服务器 iowait 持续爬到 60% 以上free -h里 Swap 被占用了一大截接口响应从 80ms 涨到 3 秒。元凶是磁盘 swap页面被换出后躺在慢速介质上应用一旦触碰这些页面就得等磁盘 I/O。Linux 内核里的 zram 就是把一部分物理内存做成压缩块设备当 swap 用——数据先在内存里压缩存储避免落盘swap 的读写延迟能比 NVMe 再低 1~2 个数量级。这篇文章从一次真实的卡顿排查讲起把启用、看指标、调参数一次讲透。先看现场swap 一启用系统为什么就卡排查这类问题先确认三件事swap 到底用了多少、磁盘是不是在疯狂换页、有没有进程被 OOM killer 干掉。swapon --show # 当前启用的 swap 及优先级 free -h # 内存与 swap 总量 iostat -x 1 5 # 观察 %iowait 和磁盘 util三个信号同时出现——Swap used 持续增长、%iowait高、应用 P99 延迟飙升——基本可以判定系统不是内存不够而是换出的页面太慢。此时加一块 zram 作为高优先级 swap比扩容内存或加 SSD 都更直接。zram 的核心思路一句话用 CPU 换 I/O。后面启用时你会看到它的每一个配置项都围绕这一点。快速启用三条命令把内存配成 zram 压缩 swapzram 设备由内核模块创建默认 1 个/dev/zram0。整套流程只有四步注意算法必须在设置 disksize 之前选设备初始化后算法就改不了了。加载模块若发行版的 zram-generator 已建好设备可跳过modprobe zram num_devices1选算法、设容量、建 swapecho lz4 /sys/block/zram0/comp_algorithm # 可选值见 cat 同一文件 echo 2G /sys/block/zram0/disksize # 解压后数据的上限非预占内存 mkswap /dev/zram0 swapon -p 100 /dev/zram0 # 优先级越高越先使用验证swapon --show里出现zram0且 PRIORITY 高于磁盘 swapfree -h里 Swap 总量变大即可。两个容易踩的坑disksize是可存放的解压数据上限不是实际占用的内存实际占用由mem_used_total决定swapon -p的数字越大越优先磁盘 swap 默认 0zram 给 100 就保证了先压内存、后落盘。驱动实现位于 drivers/block/zram/每个算法一个backend_*.c更完整的官方操作序列在 Documentation/admin-guide/blockdev/zram.rst 里有逐步说明。如何查看 zram 压缩率读懂 mm_stat 指标内核并不直接给你compression_ratio这类现成文件原始数据都在/sys/block/zram0/mm_stat一行里五个字段含义如下字段含义怎么用orig_data_size已换入数据的解压后总大小压缩率分子compr_data_size压缩后实际存储的总大小压缩率分母mem_used_totalzram 当前实际占用内存看真实开销mem_limit允许 zram 使用的内存上限0不限防止它吃光内存时设置mem_used_max历史峰值占用评估容量是否够压缩率 orig_data_size / compr_data_size真正省下来的内存约等于orig_data_size - mem_used_total。一行 awk 就能持续出数awk {printf 压缩率 %.2f | 内存节省 %.1f MB | 占用 %.1f MB\n, \ $1/$2, ($1-$3)/1048576, $3/1048576} /sys/block/zram0/mm_stat经验值文本型、代码型页面的压缩率通常能到 2.0 以上长期低于 1.3 说明换入的数据可压缩性差这时候 zram 的收益就只剩快没有省了。完整的 sysfs 属性含compact、reset、io_stat等在 Documentation/ABI/testing/sysfs-block-zram 里有逐条说明。看明白这行数据之后你就能判断卡到底是算法选错了还是数据本身压不动——这正好引出下一节的原理。为什么换算法后 CPU 会飙升zram 的压缩原理zram 的工作路径很直白页面被换出时驱动分配一个 slot把整页交给后端压缩器压缩再把压缩结果存进内存读回来时原路解压缩。所以每次 swap 读写都伴随一次 CPU 上的压缩/解压这就是用 CPU 换 I/O的全部含义——压缩越强的算法CPU 花得越多换来的是更少的内存占用。各算法的定位可以这样记lz4最快压缩率一般约 1.8~2.0xCPU 开销最小默认首选lz4hclz4 的慢速高压缩版速度掉不少但压缩率更高lzo速度介于两者之间属于中庸选项zstd压缩率最高可调 level还支持预训练字典参数CPU 开销也最大。如果你把算法从 lz4 换成 zstd 后发现 top 里 CPU 明显上涨先别慌只要软中断/CPU 占比在可接受范围比如单核占用 30%这笔账通常还是划算的——省下的磁盘等待远比多花几个点的 CPU 值钱。真正该警惕的是压缩率没涨多少、CPU 却涨了很多说明数据压不动算法选错了方向。复盘压缩率低、disksize 打满、想换算法分别怎么办用一周之后三个问题最常出现处理方式都写在下面。问题一压缩率只有 1.1 左右。先确认数据构成——随机数据、已经压缩过的文件图片、视频、日志包基本压不动换 zstd 也救不回来。这种情况更该做的是排查应用本身为什么吃了这么多内存而不是硬上更高压缩率算法反过来数据是代码段、堆对象这类才值得换 zstd。问题二swap 写满、报 disksize 不够。disksize满了只会让换出失败、退回普通 OOM 流程不会损坏数据。扩容和换算法共用一套流程因为设备初始化后算法和 disksize 都锁死必须先 resetswapoff /dev/zram0 echo 1 /sys/block/zram0/reset echo zstd /sys/block/zram0/comp_algorithm echo 4G /sys/block/zram0/disksize mkswap /dev/zram0 swapon -p 100 /dev/zram0问题三内存占用碎片化或想重新压缩旧数据。写1到compact触发内存整理若启用了recomp_algorithm写1到recompress可以让存量页面用新算法重压一遍。另外建议把mm_stat定期采进监控系统盯两个告警mem_used_max接近物理内存的 50%说明该扩disksize或给mem_limit设上限orig/compr持续低于 1.3说明该回头看数据而不是调参数。最后把配置口径收敛成一句算法看场景追速度用 lz4、追容量用 zstddisksize设物理内存的 50%~100%优先级高于磁盘 swap之后定期用mm_stat复核压缩率与峰值占用。zram 不会凭空变出内存它做的事情是让换页这件事从磁盘的毫秒级拉回内存的微秒级——这正是它值得出现在每台内存紧张的服务器上的原因。【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考