Linux zram 实战：3 个 sysfs 指标定位“压缩 swap 不省事“的根因

Linux zram 实战3 个 sysfs 指标定位压缩 swap 不省事的根因【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux凌晨 2 点的告警群跳出一条可用内存 5%但dmesg里没有 OOM应用也没变慢——只是 P99 延迟肉眼可见地爬升。翻出/sys/block/zram0/一查压缩率不到 1.2等于白占 CPU 换不来多少内存。这类装了 zram 却不省心的现场基本都能从内核暴露的三个 sysfs 指标里挖出答案。下面这套排障思路都建立在 Linux 内核的 zram 驱动源码和官方文档之上读完你可以直接在现网设备上复现。30 秒建立心智模型zram 和 zswap、磁盘 swap 不是一回事先把定位说清楚zram 是内核里的压缩内存块设备写入它的页会在内存内被压缩存放读回时解压全程不碰磁盘所以换页延迟从毫秒级掉到微秒级而 zswap 是挂在 page cache/swap 路径前面的压缩缓存层缓存满了照样落盘两者解决的是不同层次的问题甚至可以共存。磁盘 swap 则是最传统的那条路便宜但慢。维度磁盘 swapzramzswap数据存放位置磁盘分区/文件内存压缩后内存压缩缓存溢出落盘换页延迟毫秒级微秒级命中内存时微秒级miss 时回退磁盘CPU 开销几乎为 0压缩/解压常驻介于两者之间典型用途兜底高频换页、容器与嵌入式swap 前置过滤热页机制拆解一个换出的页在 zram 里经历了什么数据流的关键分支就三条重复页走捷径、压不动的页标记 huge、其余进压缩对象池。下面每个子节给一句结论再用源码路径佐证。压缩与存储是两层算法管压缩zsmalloc 管对象池。写入路径zram_bvec把整页交给 zcomp 压缩器压完的结果按大小放进 zsmalloc 对象池池里从 32 字节起按 2 的幂递增到整页所以一个可压缩页往往只占 1~2 个小对象内存利用率由此而来代价是分配器元数据和碎片。源码在 drivers/block/zram/zram_drv.c对象分配器在 mm/zsmalloc.c。重复页零分配压不动的页走标记 回写。全同元素的页比如全零不占任何对象只把表项指向一个共享的 same 对象压缩后比原页还大的页被标成 huge开CONFIG_ZRAM_WRITEBACK后可以丢到backing_dev磁盘上等于 zram 自己退化出了一层磁盘 swap。相关开关和流程见 Documentation/admin-guide/blockdev/zram.rst。zram 压缩率怎么看mm_stat前两个字段自己算。设备没有现成的压缩率属性/sys/block/zramid/mm_stat第一列orig_data_size是原始字节数第二列compr_data_size是压缩后字节数两者一除就是压缩率第三列mem_used_total含 zsmalloc 碎片和元数据才是 zram 真实吃掉的物理内存。字段定义同样在 zram_drv.c 的mm_stat_show里ABI 细节见 Documentation/ABI/testing/sysfs-block-zram。实战一条命令配好 zram再给指标挂上监控先手动跑通一遍完整链路确认指标口径modprobe zram num_devices1 # 加载模块建 /dev/zram0 cat /sys/block/zram0/comp_algorithm # 查看可用算法lzo/lz4/lz4hc/deflate/zstd echo zstd /sys/block/zram0/comp_algorithm # 设备初始化前选定算法 echo 2G /sys/block/zram0/disksize # 压缩前逻辑容量别超过物理内存一半 mkswap /dev/zram0 swapon /dev/zram0 # 启用为 swap cat /sys/block/zram0/mm_stat # 原始大小 压缩后大小 实际占用 上限 峰值 same 压缩页 huge ... cat /sys/block/zram0/io_stat # 读失败 写失败 (内存不足时会非零)生产上建议用 util-linux 的zramctl做幂等管理逻辑一致。监控侧一个 15 行以内的脚本足够#!/bin/bash Z/sys/block/zram0 read -r orig compr used max_used rest $Z/mm_stat ratio$(awk -v o$orig -v c$compr BEGIN{ if (c0) printf %.2f, o/c }) pct$(awk -v u$used -v m$max_used BEGIN{ if (m0) printf %.0f, u*100/m }) echo zram0 ratio$ratio used_pct$pct same$(sed -n s/.* [0-9]* [0-9]* [0-9]* [0-9]* [0-9]* \(.*\) .*/\1/p $Z/mm_stat) [ -n $ratio ] awk -v r$ratio BEGIN{ exit !(r 1.3) } echo ALERT: zram 压缩率过低挂 crontab 每分钟跑一次、stdout 接入告警通道即可想上 Prometheus 的话让 node_exporter 的 textfile collector 消费脚本输出再用 Grafana 画压缩率和mem_used_total的两条趋势线阈值告警跟着 80% 走就行。 踩坑与调优三个真实场景的现象 → 根因 → 处置场景 Adisksize 给大了可用内存反而更紧。现象是 16G 内存的机器配了 4G disksize没怎么换页时 MemAvailable 就比配之前低了 200M。根因是 zram 初始化会按 disksize 预建元数据表zram_drv.c 里zram_meta_alloc按disksize PAGE_SHIFT分配 table官方文档也写明未使用的 zram 大约吃 0.1% 的 disksize 物理内存加上压缩数据本身账很容易算倒。处置echo $((8*1024**3)) /sys/block/zram0/reset不可行时先swapoff再按 1/4~1/2 物理内存重设 disksize或写mem_limit顶住上限。判断标准mm_stat里mem_used_total长期大于compr_data_size的 1.2 倍说明池碎片或预留过大优先降 disksize。场景 B压缩率 1.2CPU 却烧得凶。现象是vmstat里cs/换页计数正常si/so 不低zram 压缩路径在 top 里占 25% 以上 CPU。根因是 workload 里被换出的内存大量不可压缩典型如数据库 buffer pool、已加密数据压不动的页每次换出都要先试压再判 huge白烧 CPUmm_stat的huge_pages列会持续增长坐实这一点。处置swapoff reset 后换 lz4 降 CPU或开CONFIG_ZRAM_MULTI_COMP用recomp_algorithm配 zstd 做二次压缩专收 huge 页再开 writeback 把 incompressible 页甩到backing_dev。判断标准压缩率持续低于 1.3 且压缩相关 CPU 高于 30% 时先查 workload 可压缩性再决定换算法还是回写。场景 C想运行中切算法echo lz4 .../comp_algorithm直接报 -EBUSY。这是官方文档白纸黑字的行为设备初始化之后算法不可更改必须先echo 1 /sys/block/zram0/reset。坑在于 reset 会清掉全部数据并归零 disksize正确顺序是swapoff→reset→ 设comp_algorithm→ 设disksize→mkswap/swapon生产机要挑换页量低的窗口做。判断标准只要设备上有活动 swap 数据任何 comp 参数变更都必须走 reset 流程没有例外。行动项与深入方向disksize 别超过物理内存的 1/2并配mem_limit双保险盯住mm_stat两件事压缩率低于 1.3 查 workload 可压缩性mem_used_total接近mem_limit前 80% 告警真实内存占用看mem_used_total别拿compr_data_size汇报改comp_algorithm前必须 reset这条写进变更手册io_stat里 failed 计数非零时内存已经不够 zram 用了加内存或降 disksize想继续往下挖入口在 Documentation/admin-guide/blockdev/zram.rst 的 idle 页追踪与 recompress 章节以及 drivers/block/zram/ 里各backend_*.c的算法封装selftest 在 tools/testing/selftests/zram/可以直接拿来当回归测试跑。【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考