zram + zswap 混合策略实战指南：LZO/ZSTD 内存压缩与写回机制

CH-01-02-020·约 14 分钟·计算机基础·更新 2026-08-10

主厨老王的厨房操作台（物理内存）总是堆满食材。老王发现常用的食材其实就那几样，于是他引入了两件法宝：手边一个“真空保鲜盒”（zswap），和角落里的一个“压缩储物柜”（zram）。保鲜盒把暂时不用的食材迅速抽真空压扁，取用飞快；可保鲜盒容量有限，快满时老王会把最久没碰的食材转移到储物柜——储物柜虽然在厨房里，但同样能压能存，比下楼跑地下室（磁盘 swap）快得多。这套“先压缩保鲜、满了写回储物柜、实在不行才下地下室”的体系，就是 zram 与 zswap 的混合策略。本文将带你从零认识这套机制，搞懂 LZO 与 ZSTD 两种压缩算法如何配合使用，以及如何在真实项目中配置、调优与排障。

岗位关联

掌握这套混合策略，你能在日常运维中为服务器“挤出”30%-50% 的额外有效内存，是云原生、虚拟化、数据库高并发场景的内存优化利器。

可视化演示
内存压缩原理
压缩算法对比
zram 块设备
zswap 缓存机制
混合策略架构
性能调优实践
故障排查实战
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

通过内存页压缩流程、LZO与ZSTD算法性能对比、以及zram/zswap/swap三种架构选型，展示内存压缩如何以CPU开销换取内存容量提升。

本节配有交互动效（进入视口后自动加载，约 3KB）。

内存页压缩流程冷内存页从RAM进入zram块设备被压缩后存储在物理内存中压缩后数据量减少约50%有效节省内存空间避免磁盘I/O RAM→zram→Cmp(50%) zram将冷页压缩保留在内存中

内存压缩原理

老王的厨房操作台原本只有一张桌子，摆满砧板、盘子和各种食材。过去每当台面放不下，他就只能把整袋食材送到地下室的大冰柜（磁盘 swap）里。可地下室来回一趟要几分钟——换算到计算机世界，就是从纳秒级内存访问退化到毫秒级磁盘 IO，慢了几十万倍。老王不禁思考：能不能不离开厨房就“腾地方”？答案就是把食材压扁、抽真空。

在 Linux 系统中，当物理内存吃紧时，内核的页回收机制（kswapd 等）会把不活跃的页面换出到 swap 设备。传统 swap 是磁盘或 SSD，延迟高达数十到数百微秒，严重时到毫秒级。而 zram 与 zswap 的核心理念是：在换出路径上加入压缩，让页面以压缩形态继续留在内存中，只有万不得已才碰磁盘。

压缩的收益取决于“压缩比”——原始页面大小与压缩后大小的比值。一个典型的 4KB 文本页面压缩后可能只有 1KB，压缩比为 4。所谓“省出的内存”可以这样计算：

这就像老王把萝卜、土豆、白菜装进真空袋，体积缩小一半，操作台立刻宽敞了。不过压缩要花时间——老王还得决定自己是“快速捏扁”还是“慢慢抽真空”，这就引出了 LZO 与 ZSTD 的选型之争。

\displaystyle S_{\text{saved}} = S_{\text{orig}} \times \left(1 - \frac{1}{c}\right)

通俗说：压缩比 c 越高，省下的内存越多；c=2 省一半，c=4 省四分之三。

原始页面大小页面换出前在内存中占用的字节数，Linux 中通常为 4KB
$S_{\text{orig}}$
压缩比原始大小除以压缩后大小的比值，反映压缩算法的“功力”
$c = \frac{S_{\text{orig}}}{S_{\text{comp}}}$
节省内存原始大小与压缩后大小的差值，展开即原始大小乘以括号中的节省比例
$S_{\text{saved}} = S_{\text{orig}} - S_{\text{comp}} = S_{\text{orig}} \times \left(1 - \frac{1}{c}\right)$

压缩算法对比

老王有两种收纳手法：一种叫“快速捏团法”——三秒把手头食材揉成团塞进保鲜盒，速度飞快但丸子比较蓬松、占地方；另一种叫“真空精打包装”——花十几秒抽真空、整形，塞进同样大小的盒子能多装一倍。前者像 LZO，后者像 ZSTD。

Linux 内核在 zram 和 zswap 中都支持配置压缩算法。LZO（Lempel-Ziv-Oberhumer）是经典算法，以极快的压缩/解压速度和低 CPU 开销著称；ZSTD（Zstandard）由 Meta 开源，压缩率远优于 LZO（通常高 10%-30%），解压速度也相当可观，但压缩时更耗 CPU。

选择算法的本质是在“压缩率收益”与“CPU 时间成本”之间做权衡。换出路径上的总时间开销可建模为：

想象老王在饭点高峰忙得脚不沾地，他肯定选三秒捏团法；等夜深人静、CPU 空闲，他才有空慢慢抽真空。同理，CPU 核多、有余量的服务器适合 ZSTD，而 IO 频繁、CPU 紧张的边缘设备则优先 LZO。

\displaystyle T_{\text{total}} = T_{\text{comp}} + T_{\text{mem}}

压缩耗时CPU 把页面压成压缩形态的时间，LZO 约为 ZSTD 的 1/5 到 1/8
$T_{\text{comp}}$
内存访问耗时压缩后数据写入内存池的时间，两种算法几乎一致
$T_{\text{mem}}$
总开销换出一个页面消耗的总时间，决定了系统的换页吞吐上限
$T_{\text{total}} = T_{\text{comp}} + T_{\text{mem}}$

zram 块设备

老王的压缩储物柜摆在厨房角落，看起来跟普通柜子一样，但被施了“压缩魔法”——同样体积的柜子，能装下三倍多的食材。这个柜子其实还在厨房里（内存中），并非地下室。

zram 是 Linux 内核提供的一种内存块设备：加载后呈现为 /dev/zram0 这样的块设备，可被格式化为 swap 设备。向 zram 写入数据时，内核自动用所选算法（lzo 或 zstd）压缩；读取时自动解压。它本质是一片由压缩页管理器（zsmalloc）承载的内存区域。

配置 zram 的关键参数是 disksize——名义容量。假设系统内存 16GB，设置 disksize=4GB，若实际平均压缩比为 3，那么它最多能装下约 12GB 的未压缩数据。有效容量公式为：

储物柜的“魔法扩容”不是免费的——压缩魔法会耗费老王的体力（CPU）。而且柜子塞得越满，厨房里剩余的活动空间（可用内存）就越少，所以 disksize 很有讲究，通常推荐设为物理内存的 25%-50%。

\displaystyle C_{\text{effective}} = C_{\text{disksize}} \times \bar{r}

名义容量zram 创建时指定的 disksize，例如 4GB，决定压缩存储的最大内存占用
$C_{\text{disksize}}$
平均压缩比实际负载的平均压缩程度，文本型负载可达 3-4，二进制数据可能只有 1.5
$\bar{r}$
有效容量名义上能容纳的原始页面总量，等于名义容量乘以平均压缩比
$C_{\text{effective}} = C_{\text{disksize}} \times \bar{r}$

zswap 缓存机制

真空保鲜盒放在操作台右手边，老王处理食材时可以迅速压一盒放旁边。但保鲜盒容量固定（默认为内存的 20%），盒子快见底时，老王得把盒底压箱底、最久没碰的食材转移到储物柜。

zswap 是 Linux swap 子系统前的一道压缩缓存层：内核要换出一个页面时，先把它压缩存入 zswap 的压缩池。池中页面按 LRU（最近最少使用）排列。当池占用达到上限或内存回收压力增大，zswap 启动 writeback：从池尾取出页面，写入后端 swap 设备（backend）。如果后端配置为 zram，写回的数据仍留在内存里。

writeback 何时触发？可以抽象成一个水位阈值模型：

保鲜盒的“满了就转移”策略保证了手边总有余量装新食材。写回到 zram 而非直接下地下室，正是这套混合策略的精髓——老王宁可多花点力气在厨房内腾挪，也不愿意为一样不常用的食材跑一趟地下室。

\displaystyle T_{\text{writeback}} = \alpha \times P_{\max} \times M_{\text{ram}}

最大池比例模块参数 zswap.max_pool_percent，默认 20%，即 zswap 最多占用物理内存的 20%
$P_{\max} = 20\%$
触发系数通常取 1（池满触发），内核也会根据内存回收压力动态调整，可视为一个围绕 1 浮动的系数
$\alpha \approx 1$
物理内存总量系统 RAM 的大小，决定了池的绝对上限
$M_{\text{ram}}$
写回阈值池中压缩数据占用量达到该字节数时，zswap 开始按 LRU 写回
$T_{\text{writeback}} = \alpha \times P_{\max} \times M_{\text{ram}}$

混合策略架构

现在老王把三条通道全打通了：操作台（内存）放不下，先压进保鲜盒（zswap）；保鲜盒满了，把旧食材转移到储物柜（zram）；万一储物柜也满了，而食材还在源源不断运来，才不得不走下地下室（磁盘）。

实际操作中，zram 作为后端 swap 是通过配置完成的——将 zram 格式化为 swap 后，Linux 会自动将 zswap 的 writeback 目标指向它（zswap 的后端就是系统当前使用的 swap 设备）。混合策略的完整数据流：内存 → zswap 压缩池 → zram → 磁盘。每一次被 zswap 或 zram 拦截，都避免了一次磁盘 IO。

从延迟角度看，三段路径代价差异极大，可以用分段函数表示：

这个三级接力让绝大多数换页动作都在厨房内完成。统计显示，在内存适中的负载下，zswap+zram 混合策略可以避免 90% 以上的磁盘换页——老王一天下楼跑地下室跑不到两回，厨房整体运转效率自然大幅提升。

\displaystyle L_{\text{swapout}} = \begin{cases} L_{\text{zswap}} & \text{命中缓存} \\ L_{\text{zswap}} + L_{\text{zram}} & \text{写回 zram} \\ L_{\text{zswap}} + L_{\text{zram}} + L_{\text{disk}} & \text{回退磁盘} \end{cases}

命中缓存页面在 zswap 池内完成换出，仅有压缩与内存写入，约微秒级
$L_{\text{zswap}}$
写回 zram页面先被 zswap 解压丢弃，再由 zram 压缩存储，多一次 CPU 往返
$L_{\text{zswap}} + L_{\text{zram}}$
回退磁盘最坏场景走真实磁盘 IO，延迟从微秒级跳到毫秒级
$L_{\text{zswap}} + L_{\text{zram}} + L_{\text{disk}}$

性能调优实践

老王经过一段时间摸索，总结出经营厨房的调优心得：高峰期用什么收纳法、给保鲜盒留多大容量、储物柜塞多满，都要根据客流动态调整。

在生产环境中，调优主要围绕四个旋钮：压缩算法（zswap.compressor / zram_comp_algorithm）、zram 的 disksize、zswap 的 max_pool_percent、以及是否启用 zswap.enabled。调优顺序建议：先定算法，再定容量，最后通过监控数据迭代。

如何判断一个调优动作值不值？可以把“节省的内存”和“多花的 CPU”放在一个比值里：

老王的原则是“省心省力两相宜”：CPU 富余的云主机大胆用 ZSTD + 大池上限；CPU 紧张的边缘网关老老实实 LZO + 小池；至于 disksize，永远记住那句口诀——柜子再大也是厨房里的，别把厨房塞成储物间。

\displaystyle \text{ROI} = \frac{\Delta M_{\text{effective}}}{\Delta C_{\text{CPU}}}

有效内存增量调优后额外获得的可使用内存量，比如从 LZO 切到 ZSTD 多省了 5% 内存
$\Delta M_{\text{effective}}$
CPU 成本增量随之增加的压缩/解压 CPU 占用比例
$\Delta C_{\text{CPU}}$
收益比大于 1 说明划算，小于 1 说明得不偿失，应回退配置
$\text{ROI} = \frac{\Delta M_{\text{effective}}}{\Delta C_{\text{CPU}}}$

故障排查实战

厨房系统也有闹脾气的时候：保鲜盒密封条老化（zswap 压缩异常）、储物柜门变形卡住（zram 写回缓慢）、甚至地下室的旧冰柜突然跳闸（磁盘 swap 故障）。老王必须学会快速诊断。

常见的故障场景有：系统无缘无故卡死、CPU 飙升、内存明明还有却频繁 swap。排查时先用 free -h 查看 Swap 与 zram 的使用；再用 zramctl 查看压缩算法与数据量；深入一点看 /sys/kernel/debug/zswap 中的 pool 大小与写回次数。

一个必须盯住的危险信号是 zram 即将写满。当 zram 中已压缩数据量逼近 disksize，新页面会被迫回退到磁盘，性能断崖式下跌。判定条件为：

老王每天收工前会扫一眼仪表盘：保鲜盒装到几成、储物柜还剩多少空位、今天下地下室几次。对应到系统上，就是 zswap pool 水位、zram mm_stat、以及 /proc/vmstat 中的 pswpin/pswpout——三个指标在手，厨房尽在掌握。

\displaystyle U_{\text{zram}} \geq C_{\text{disksize}} \Rightarrow \text{回退磁盘}

zram 已用量通过 /sys/block/zram0/mm_stat 中的 mem_used_total 读取，单位字节
$U_{\text{zram}}$
名义容量创建 zram 时设置的 disksize，这是压缩数据的内存占用上限
$C_{\text{disksize}}$
回退信号当已用量≥名义容量，zram 无法再接新页面，后续换页只能写磁盘
$U_{\text{zram}} \geq C_{\text{disksize}}$

AI 应用场景

云原生节点内存超卖

阶段：资源池化与容器调度优化

解决的问题：K8s 节点上大量 Pod 的内存申请远超物理内存，传统做法是减少 Pod 数量或购买昂贵的大内存机型。通过 zswap+zram 混合策略，把换页数据压缩在内存中，避免磁盘 swap 导致的 Pod 延迟抖动，让同一节点承载更多 Pod。

具体案例：某电商平台大促集群，8 核 16G 节点能够稳定运行原先需要 24G 内存的工作负载，Pod 调度密度提升约 50%，P99 延迟无劣化。

高并发中间件内存兜底

阶段：服务性能保障与容量规划

解决的问题：Redis、MQ 等中间件在流量尖峰时内存瞬时打满，触发磁盘 swap 会带来数十毫秒的延迟尖刺。混合策略确保尖峰时冷内存页被压缩收纳，避免磁盘 IO。

具体案例：某支付网关的 Redis 集群在瞬时流量高峰下，通过 zswap+zram 将 swapin 延迟从 15ms 降至 0.3ms。

嵌入式与移动端内存优化

阶段：端侧资源受限优化

解决的问题：手机、路由器、工控机内存小，多任务切换频繁。zram 作为 swap 能显著提升后台应用驻留能力，减少杀进程概率。

具体案例：某品牌路由器使用 zram（128MB）后，并发连接数提升 30%，后台管理界面响应明显加快。

Python 演示

python53 行

#!/usr/bin/env python3# -*- coding: utf-8 -*-"""zram/zswap 混合策略模拟器"""import zlibimport time PAGE_SIZE = 4096 def make_pages(num=64, pattern="text"):    """生成模拟内存页面"""    pages = []    for i in range(num):        if pattern == "text":            data = (f"page-{i}-" + "x" * (PAGE_SIZE - 16)).encode()        else:            data = bytes([i % 256]) * PAGE_SIZE        pages.append(data)    return pages def compress_lzo(data):    """模拟 LZO: level=1 快速压缩"""    return zlib.compress(data, level=1) def compress_zstd(data):    """模拟 ZSTD: level=9 高压缩率"""    return zlib.compress(data, level=9) def simulate(pages, algo):    total_orig = sum(len(p) for p in pages)    total_comp = 0    t0 = time.time()    for p in pages:        if algo == "lzo":            c = compress_lzo(p)        else:            c = compress_zstd(p)        total_comp += len(c)    elapsed = time.time() - t0    ratio = total_orig / total_comp if total_comp else 0    return total_orig, total_comp, ratio, elapsed def main():    print("=== zram/zswap 压缩策略模拟 ===")    pages = make_pages(200, pattern="text")    for algo in ("lzo", "zstd"):        orig, comp, ratio, elapsed = simulate(pages, algo)        save = (1 - 1 / ratio) * 100 if ratio > 1 else 0        print(f"{algo:6s}: orig={orig:>9d}B comp={comp:>9d}B "              f"ratio={ratio:>5.2f} save={save:>5.1f}% cost={elapsed:.4f}s")    print("提示: 压缩比越高越省内存, 耗时越长越耗CPU") if __name__ == "__main__":    main()

目的：用 Python 标准库模拟 zram/zswap 中 LZO 与 ZSTD 两种压缩算法的权衡——以 zlib level=1 模拟 LZO 的速度优先，以 level=9 模拟 ZSTD 的压缩率优先，运行后直接对比两者的“省内存百分比”与“耗时”。

import zlib用 Python 标准库的压缩模块模拟内核中的 LZO/ZSTD 算法
PAGE_SIZE = 4096与 Linux 内存页大小一致的 4KB，模拟真实换页单元
data = (f"page-{i}-" + "x" * (PAGE_SIZE - 16)).encode()构造一页可压缩文本，类似内核中的文本/缓存页
return zlib.compress(data, level=1)level=1 模拟 LZO 的“快速捏团”风格，速度优先
return zlib.compress(data, level=9)level=9 模拟 ZSTD 的“真空打包”风格，压缩率优先
ratio = total_orig / total_comp计算整体压缩比，即原始总量除以压缩后总量
save = (1 - 1 / ratio) * 100换算成节省内存百分比，与正文中的公式呼应

常见误区

误区“zram 和 zswap 都要做内存压缩，我只需要选一个装上就行了，两个都配会冲突吧？”

正解它们不是对立而是互补。zswap 是 swap 子系统前的压缩缓存层，zram 是一个内存压缩块设备，可以作为 zswap 的后端设备。混合使用时，zswap 先压缩缓存，满了之后写回到 zram，形成两级压缩，让大部分换页操作留在内存内。就像保鲜盒和储物柜配合使用，而不是互相替代。

为何常见：因为网上教程常常单独介绍其中一个，容易让人误以为它们是同类替代品。

误区“ZSTD 压缩率比 LZO 高，不管什么场景我都用 zstd，省内存更多不是更好吗？”

正解压缩/解压要消耗 CPU。在 CPU 紧张或换页频繁的场景，LZO 的速度优势能避免 CPU 成为新瓶颈。ZSTD 压缩率虽高，但压缩耗时可能是 LZO 的 5~8 倍。要像主厨一样看客流：高峰时段用快速收纳，空闲时段再精细打包。

为何常见：人们容易只盯着“省内存”这一个指标，忽略 CPU 开销这个隐性成本。

误区“zram 既然是压缩的，我把 disksize 设成内存的 2 倍，岂不是能压更多数据？”

正解zram 本身占用的就是物理内存。disksize 只是“名义容量”，实际内存占用取决于压缩后的数据量。设太大意味着 zram 里的数据越来越多，一旦内存不够反而加剧回收压力，甚至触发 OOM。合理姿势：disksize 通常设为物理内存的 25%-50%。

为何常见：zram 看起来像一个独立块设备，让人容易忘记它消耗的是同一块物理内存。

误区“配好 zram 和 zswap，swap 速度就快如内存，不用再管了。”

正解混合策略只是把磁盘 IO 尽量推迟，内存总量仍是硬约束。当内存真实不足，zswap 和 zram 都塞满时，页面仍会写回磁盘，系统还是会卡。需要持续监控 SwapFree、zswap pool 水位、CPU 压缩开销，并结合实际负载调优。

为何常见：看到“内存压缩”就误以为内存容量翻倍，忽略了物理上限。

面试题

Q1. zram 是什么类型的设备？

单选题 · easy

A.磁盘块设备
B.内存压缩块设备← 正确答案
C.网络块设备
D.字符设备

答案：B。zram 是 Linux 内核中的内存压缩块设备，数据写入时压缩、读取时解压，本质是占用物理内存的块设备。就像厨房里的压缩储物柜。

Q2. zswap 的 writeback 功能的作用是？

单选题 · easy

A.删除压缩缓存
B.把压缩池中的数据写回后端 swap 设备← 正确答案
C.把数据写到网络磁盘
D.增加内存频率

答案：B。zswap 池满后，需要按 LRU 把旧页面取出来写入真正的 swap 设备（backend），这个过程叫 writeback。如果后端配 zram，写回仍在内存中完成。

Q3. LZO 相比 ZSTD 的优点是？

单选题 · easy

A.压缩率更高
B.解压更安全
C.压缩/解压速度更快← 正确答案
D.支持硬件加速

答案：C。LZO 以速度见长，CPU 开销小；ZSTD 压缩率更高但压缩更耗 CPU。就像忙时用快速捏团法，闲时才用真空打包。

Q4. 当一个 4KB 页面被压缩到 1KB 存入 zram，压缩比是多少？

单选题 · mid

A.0.25
B.4.0← 正确答案
C.3.0
D.0.75

答案：B。压缩比 = 原始大小 / 压缩后大小 = 4KB / 1KB = 4。节省内存 = 原始大小 × (1 - 1/4) = 3KB，即节省约 75% 的空间。

Q5. 以下哪些属于 zswap 的典型可配置参数？

多选题 · mid

A.zswap.max_pool_percent← 正确答案
B.zswap.compressor← 正确答案
C.zswap.writeback
D.zram.disksize

答案：AB。zswap 的常用模块参数包括 max_pool_percent（池大小上限）和 compressor（选择压缩算法）。writeback 是 zswap 的内置行为而非参数，zram.disksize 则属于 zram 的参数，因此 C、D 不选。

Q6. 将 zram 作为 zswap 后端时，writeback 的页面会写到哪里？

单选题 · mid

A.磁盘
B.网络
C.zram 压缩块设备← 正确答案
D.直接被丢弃

答案：C。后端 swap 设备是 /dev/zram0 时，zswap 写回的压缩页面会进入 zram，仍然留在内存中，从而避免写磁盘。这正是混合策略的核心价值。

Q7. 关于 zram 作为 swap 设备，以下描述正确的是？

多选题 · hard

A.需要先 mkswap 格式化← 正确答案
B.重启后数据不丢失
C.实际内存占用等于压缩后数据量← 正确答案
D.没有额外 CPU 开销

答案：AC。zram 启用流程是配置 disksize → mkswap → swapon，A 正确。zram 是内存块设备，重启后数据丢失，B 错误。实际内存占用是 mem_used_total 即压缩后数据总量，C 正确。压缩和解压都要消耗 CPU，D 错误。

Q8. 下面哪个命令可以看到 zram 当前使用的压缩算法？

单选题 · easy

A.lsblk
B.cat /sys/block/zram0/comp_algorithm← 正确答案
C.free -h
D.df -h

答案：B。/sys/block/zram0/comp_algorithm 会列出该 zram 设备支持的压缩算法，并用方括号标记当前算法。zramctl 命令也能显示 Comp algo 列。

Q9. 以下哪些做法能降低 zswap 写回磁盘的概率？

多选题 · mid

A.增大 zswap.max_pool_percent← 正确答案
B.使用 zram 作为 backend← 正确答案
C.减少物理内存
D.使用更高压缩率的 zstd← 正确答案

答案：ABD。增大 max_pool_percent 让 zswap 缓存更多压缩页；用 zram 作 backend 使写回仍留在内存；用 zstd 压缩率更高，同样内存能存更多数据——三者都能减少落盘。减少物理内存会加剧内存压力，反而增加写回概率，故不选 C。

Q10. 内存严重不足时，页面换出路径的正确顺序是？

单选题 · hard

A.内存 → zram → zswap → 磁盘
B.内存 → zswap → zram → 磁盘← 正确答案
C.磁盘 → zram → zswap → 内存
D.zswap → 内存 → 磁盘 → zram

答案：B。换页路径是：内存页面先被压缩进 zswap 缓存；zswap 池满后按 LRU 写回 zram；zram 写满后再落磁盘。顺序相当于厨房食材从操作台进保鲜盒、再进储物柜、最后下地下室。