在 Linux 系统的内存管理实践中，Zswap 和 Zram 是两个常被混淆的概念。许多技术讨论将它们视为可以相互替代的方案，实际上二者在内核中的角色截然不同，这种误解往往导致配置选择失误。本文将从实现机制出发，拆解性能表现上的真实差异，并给出面向桌面、服务器及虚拟化场景的可操作参数建议。
架构层面的根本差异
理解 Zswap 与 Zram 的第一步，是认清它们在内核存储层次中的位置。Zswap 并非一个独立的交换目标，而是一个介于物理内存与实际交换设备之间的压缩缓存层。当内核需要将页面换出时，Zswap 首先尝试将页面压缩并存入其位于内存中的压缩池；如果压缩池满或达到预设阈值，才会将冷数据回写到后端的磁盘交换设备。这种设计本质上是用 CPU 周期换取潜在的磁盘 I/O 减少，尤其在读取延迟远高于内存解压缩延迟的场景下效果显著。
Zram 则完全不同，它是一个基于内存的压缩块设备，本质上把 RAM 本身作为交换空间。与传统 swap 分区或 swap 文件的区别在于，存入 Zram 的数据始终以压缩形态保留在内存中，没有任何磁盘后端作为溢出目标。这意味着理论上可以实现零磁盘交换写入，但代价是压缩数据完全占用物理内存，且所有压缩解压操作都由 CPU 实时完成。
从使用模式来看，如果系统已有独立的 swap 分区或 swap 文件，启用 Zswap 可以在不改变现有存储布局的前提下获得压缩缓存收益；而启用 Zram 则需要显式创建新的交换设备并配置其大小策略。
性能表现的真实面貌
关于两种方案的性能，业界存在若干流行观点需要逐一审视。首先是 “Zswap 会写回磁盘，所以没有意义” 的说法。从设计来看，Zswap 确实会在压缩池达到 max_pool_percent 设定上限后将冷页面驱逐到后端 swap 设备，但这一行为本身就是其价值所在 —— 它充当了内存与磁盘之间的缓冲层，将热数据保留在压缩内存中，只在必要时才下刷磁盘。对于使用机械硬盘或低速 SSD 作为 swap 设备的系统，这种异步写回机制可以显著降低交换操作的尾延迟。
其次是 “Zram 永远比 Zswap 更好” 的判断。这种结论忽略了一个关键前提：Zram 的性能优势建立在充足的 CPU 算力与可接受的压缩开销之上。当压缩池被填满时，Zram 必须进行页面驱逐，由于没有磁盘后端，被驱逐的页面只能直接丢弃，这可能导致需要再次换入时产生缺页异常。相反，Zswap 在池满时可以回写到磁盘，为系统提供更稳健的降级路径。因此，在 CPU 资源有限或工作负载对压缩开销敏感的场景下，Zswap 往往比 Zram 表现更可预测。
从压缩算法角度，现代内核默认使用 LZ4 作为 Zswap 的压缩器，其特点是解压速度极快、CPU 开销低，压缩比大约在 2:1 到 3:1 之间。对于追求更高压缩率的用户，ZSTD 算法提供了更好的压缩比但相应增加 CPU 负担。实际测试表明，在桌面级工作负载下，两种算法的用户体验差异通常小于预期，因为瓶颈往往在磁盘 I/O 而非 CPU。
面向场景的参数配置
掌握以下关键参数，可以帮助工程师根据具体场景做出合理取舍。
Zswap 可调参数
max_pool_percent 控制压缩池可占用的最大内存比例，默认值通常为 20%。对于桌面环境，建议将值设为 10% 到 15%，在保留内存用于活跃进程的同时为压缩缓存留出空间；如果工作负载频繁触发交换，可上调至 25% 但需监控可用内存。参数通过 sysfs 路径 /sys/module/zswap/parameters/max_pool_percent 动态调整。
accept_threshold_percent 是另一个实用参数，用于实现压缩池满后的迟滞行为。当池达到 max_pool_percent 设定的大小后，Zswap 会拒绝新页面进入，直到可用空间降至 accept_threshold_percent 以下。默认值为 100，即无迟滞。将此值设为 70 到 80 可以避免频繁的页面驱逐与重新入池，提升系统在持续内存压力下的稳定性。操作方式为 echo 数值 > /sys/module/zswap/parameters/accept_threshold_percent。
compressor 参数允许在 lz4、lzo、zstd 等算法之间切换。桌面或轻量服务器场景推荐保持默认的 lz4；如果系统运行在多核服务器且 CPU 空闲率较高，可尝试切换到 zstd 以获得更高压缩比，减少内存压力。切换后已有页面不会重新压缩，新进入的页面才会使用新算法。
Zram 可调参数
disksize 定义 Zram 设备的总容量，单位为字节。通常设置为物理内存的 50% 到 100%，具体取决于是否需要与传统 swap 共用。在内存资源紧张且 CPU 充裕的环境中，可设置为物理内存的 100% 以获得最大压缩内存空间。
算法选择 通过 cat /sys/block/zram0/comp_algorithm 查看可用算法后写入 /sys/block/zram0/comp_algorithm 进行切换。对于一般桌面负载，lz4 提供了最佳的综合性能；若是内存极度紧张且可以容忍更高的 CPU 占用，zstd 是更优选择。
常见组合与误区澄清
部分用户尝试同时启用 Zswap 与 Zram，理论上可行但实践中并不常见。最常见的配置是仅启用 Zswap 作为现有 swap 设备的缓存层，这种方式对系统改动最小且能够覆盖大多数桌面和轻量服务器场景。Zram 更适合内存预算极其紧张、CPU 有余量且希望完全消除磁盘交换的场景，例如某些嵌入式系统或运行在资源受限虚拟机的测试环境。
需要澄清的另一个误区是 “关闭 swap 可以避免使用 Zswap 或 Zram”。实际上，即使禁用了磁盘 swap，Zram 仍可以作为独立的交换设备使用，而 Zswap 的设计初衷就是与磁盘 swap 协同工作，二者的启用状态互不强制依赖。
选型决策清单
以下决策路径可作为实际部署的参考：对于使用机械硬盘或低写入寿命 SSD 的桌面用户，Zswap 是首选方案，它可以在不明显增加 CPU 负担的前提下显著降低磁盘交换的频率并延长 SSD 寿命；对于拥有多核 CPU、内存压力持续且磁盘 I/O 已成为瓶颈的服务器工作负载，Zram 可以提供更激进的压缩能力，但需要持续监控 CPU 使用率以确保不会影响核心业务进程；对于虚拟化场景中的.overcommitted 客户机，Zswap 可以有效降低对宿主机 I/O 资源的竞争，而 Zram 则适用于对延迟极度敏感且宿主机磁盘资源稀缺的场景。
理解 Zswap 与 Zram 的技术差异与适用边界，是做出正确配置决策的前提。两者并非简单的优劣之分，而是针对不同资源约束与性能目标的工程选项。合理运用这些参数，能够在有限硬件资源下最大化系统的响应速度与稳定性。