Linux内存压缩技术：ZRAM与ZSWAP原理、选型与性能调优指南

1. 项目概述：为什么我们需要内存压缩？

在Linux服务器上跑着跑着，突然发现free -m命令里的available内存越来越少，swap开始频繁读写，系统响应慢得像蜗牛。这场景，搞过运维或者开发的朋友应该都不陌生。传统上，我们可能会选择加物理内存，或者优化应用代码，但成本高、周期长。有没有一种更“软”的、立竿见影的办法，能在内存紧张时，像给行李箱加压一样，把里面不常用的东西“挤一挤”，腾出空间给更紧急的任务用？这就是内存压缩技术要解决的核心问题。

简单来说，Linux内核的内存压缩，就是在物理内存（RAM）不足时，不是简单粗暴地把整个内存页（Page）交换（Swap）到速度慢几个数量级的磁盘上，而是尝试在内存内部，对某些页的内容进行压缩，用CPU的计算时间换取宝贵的内存空间。它像一个高效的内存“整理师”，目标是延迟甚至避免触发昂贵的磁盘I/O操作，从而在内存压力下保持系统的响应速度。这项技术对于数据库服务器、虚拟化环境、嵌入式设备以及任何内存资源受限但性能要求高的场景都至关重要。今天，我们就来深入聊聊Linux内核里几种主流的内存压缩技术，它们是怎么工作的，各自适合什么场景，以及在实际操作中怎么用、怎么调。

2. 内存压缩的核心原理与前置知识

在深入具体技术之前，我们需要统一几个关键概念，这能帮你更好地理解后续所有压缩策略的出发点和权衡。

2.1 内存管理的基石：页（Page）与页帧（Page Frame）

Linux内核管理内存的基本单位是“页”（Page），通常大小为4KB（x86_64架构常见值，也可能是2MB的大页）。每一个物理内存单元被称为一个“页帧”（Page Frame），用来存放一个页的内容。当系统内存紧张时，内核的页面回收机制（Page Reclaim）会被激活，它的任务就是找到一些“可以牺牲”的页，把它们占用的页帧释放出来。

2.2 匿名页与文件页：谁更适合被压缩？

内存中的页主要分两类：

• 匿名页（Anonymous Page）：没有后备存储设备（如磁盘文件）关联的页。例如，你的程序用malloc()或new在堆上分配的内存，或者栈内存。这类页一旦被换出，只能去交换分区（Swap Space）。
• 文件页（File Page / Page Cache）：是磁盘文件内容在内存中的缓存。例如，你读取一个文件，它的内容就会被缓存在这里。这类页有磁盘上的源文件作为“后备”，回收时如果内容是干净的（未被修改），直接丢弃即可；如果是脏的（被修改过），则需要写回磁盘。

从压缩的角度看，匿名页是更重要的目标。因为交换匿名页到磁盘（Swap Out/In）的性能代价极高，涉及慢速的磁盘I/O。如果能压缩它们，就避免了这次I/O。文件页本身有磁盘备份，回收压力相对小，但压缩它们也能更快地释放内存。

2.3 压缩的收益与代价：CPU与内存的博弈

内存压缩的本质是一种“时空转换”。它用CPU时间（压缩/解压缩计算）和少量的额外内存（存储压缩后的数据），来换取更多的可用内存空间。

• 收益：减少或避免磁盘Swap I/O，极大提升系统在内存压力下的响应能力。
• 代价：消耗CPU周期。如果压缩算法太重，或者压缩率太低，可能得不偿失。

因此，一个理想的内存压缩方案需要在压缩速度、压缩率和CPU占用之间取得精妙的平衡。这也引出了内核中不同的压缩实现。

3. ZSWAP：前端交换缓存压缩器

ZSWAP是较早被引入主流内核（3.11版本左右）的压缩技术，它的定位非常巧妙：作为Swap子系统的一个“前端缓存”。

3.1 ZSWAP 的工作原理

你可以把ZSWAP想象成Swap分区在内存中的一个“压缩代理”或“缓冲层”。其工作流程如下：

1. 当内核需要交换出一个匿名页到磁盘时，它首先会把这个页交给ZSWAP。
2. ZSWAP调用指定的压缩算法（如LZO、LZ4、ZSTD）尝试压缩该页。
3. 压缩成功且有意义：如果压缩后的大小小于原始页大小的某个阈值（例如，对于4KB页，压缩到3KB以下），ZSWAP会将压缩后的数据存储在一块专门预留的压缩存储池（ZPOOL）中。这个存储池位于内存中，但管理方式类似一个缓存。然后，内核会认为该页已经被“换出”了，并释放其原来的页帧。但实际上，数据还在内存里，只是被压缩了。
4. 压缩失败或意义不大：如果压缩率太低（比如只压到3.8KB），ZSWAP会认为这次压缩不划算，于是回退到传统路径，直接将这个页写入真正的磁盘Swap分区。
5. 读取（换入）时：当应用程序再次访问这个已被“换出”的页时，如果它在ZSWAP缓存中，内核会从ZPOOL中取出压缩的数据，解压后填充到一个新的页帧中，然后交给CPU。这个过程完全在内存中完成，速度远快于从磁盘Swap分区读取。

3.2 ZSWAP 的核心组件与配置

ZSWAP的配置主要涉及两个部分：压缩算法和存储池（ZPOOL）。

• 压缩算法：通过内核参数zswap.compressor指定。常见选择有：
  • lzo/lzo-rle：速度极快，压缩率一般。是低延迟场景的默认选择。
  • lz4：在速度和压缩率之间取得了很好的平衡，是目前非常流行的选择。
  • zstd：压缩率更高，但速度比LZ4慢一些。如果CPU较强且追求更高内存节省，可以考虑。
  • deflate：压缩率高，但速度慢，通常不推荐用于动态内存压缩。
• 存储池（ZPOOL）：通过zswap.zpool指定，用于管理压缩后的数据。主流选择是zsmalloc，它是一个为小对象（压缩后的内存页通常很小）分配内存的高效分配器，能减少内存碎片。

启用与配置示例：通常，ZSWAP可以通过内核引导参数启用。在GRUB配置（/etc/default/grub）的GRUB_CMDLINE_LINUX行中添加：

GRUB_CMDLINE_LINUX="... zswap.enabled=1 zswap.compressor=lz4 zswap.zpool=zsmalloc ..."

然后更新GRUB并重启。运行时也可以通过sysfs动态调整（如果内核编译时支持）：

echo 1 > /sys/module/zswap/parameters/enabled echo lz4 > /sys/module/zswap/parameters/compressor

3.3 ZSWAP 的优缺点与适用场景

优点：

• 非侵入式：它只拦截即将发生Swap的页，对没有内存压力的系统完全没有影响。
• 显著降低Swap I/O：将大部分频繁访问的“热交换页”留在内存压缩缓存中，极大提升响应速度。
• 配置灵活：算法和存储池可配，适应不同硬件和需求。

缺点：

• 缓存容量有限：ZPOOL的大小有限（最大通常不超过物理内存的50%）。当缓存满了之后，会根据算法（如LRU）淘汰旧数据，这些被淘汰的压缩数据如果还没被换出到磁盘，就需要走传统Swap路径。
• 只针对匿名页：主要优化匿名页的换出，对文件页缓存（Page Cache）的回收没有直接帮助。

适用场景：内存压力中等，Swap I/O开始出现的服务器、桌面系统。它是改善交互体验、避免系统突然卡死的有效“安全垫”。

实操心得：在数据库服务器上，我曾遇到因偶发查询导致内存骤增，触发Swap后性能雪崩的情况。启用ZSWAP（使用lz4）后，同样的内存压力下，监控显示Swap写入量下降了90%以上，系统性能曲线变得平滑许多。建议生产环境都考虑启用，成本极低，收益明显。

4. ZRAM：基于内存的虚拟块设备压缩

如果说ZSWAP是Swap的“缓存”，那ZRAM则更为激进和彻底。它直接创建一个基于内存的、可压缩的虚拟块设备，并将整个Swap分区放到这个内存设备上。

4.1 ZRAM 的工作原理

1. 创建虚拟设备：内核模块初始化时，在内存中划出一块区域，抽象成一个块设备，如/dev/zram0。
2. 配置为Swap设备：使用mkswap和swapon命令，将这个ZRAM设备格式化为Swap分区并启用。
3. 透明压缩/解压缩：当有页需要交换时，内核像写入普通磁盘Swap一样，将数据写入/dev/zram0。但在写入过程中，ZRAM驱动会透明地压缩这些数据，然后存储在内存中。读取时，再透明地解压。对内核的Swap子系统来说，它只是在操作一个“速度极快的块设备”，而不知道底层发生了压缩。

4.2 ZRAM 的配置与管理

ZRAM的配置核心是决定虚拟设备的大小和使用的压缩算法。

配置示例：现代Linux发行版（如Ubuntu 20.04+, Fedora, 部分Android系统）通常默认启用ZRAM。手动配置也很简单：

# 1. 加载zram模块（通常已自动加载） sudo modprobe zram # 2. 确定ZRAM设备数量和一个设备的大小。例如，分配一个大小为4GB的ZRAM设备。 # 注意：这个大小是“未压缩”的虚拟大小，实际占用内存取决于压缩率。 echo 4G > /sys/block/zram0/disksize # 3. 选择压缩算法 echo lz4 > /sys/block/zram0/comp_algorithm # 4. 将其初始化为交换分区并启用 sudo mkswap /dev/zram0 sudo swapon /dev/zram0 -p 100 # 设置较高优先级，使其优先于磁盘Swap被使用

为了让配置永久生效，你需要借助系统服务（如systemd的zram-swap.service）或在启动脚本中完成上述步骤。

4.3 ZRAM vs ZSWAP：核心差异与选择

这是一个常见的困惑点，理解它们的区别对正确选型至关重要。

简单选择指南：

• 追求简单、通用：对于大多数桌面和服务器，ZRAM是更直接、更彻底的选择。它用内存模拟了一个高速Swap盘，能完全避免慢速磁盘I/O，只要你的压缩率大于1（通常都能达到2-3倍），你就用更少的内存空间承载了更大的虚拟交换空间。
• 需要精细控制：如果你的系统Swap行为非常特殊，或者你想将压缩严格作为磁盘Swap的加速缓存，并且希望内存压力极小时零开销，可以考虑ZSWAP。
• 可以组合使用吗？技术上可以，但通常不推荐。这相当于在内存Swap上又加了一层内存缓存，增加了复杂度，管理收益不明确。主流做法是二选一。

注意事项：ZRAM分配的disksize是一个“虚拟大小”。如果你设置了8GB，不代表立刻占用8GB内存。实际占用内存取决于存入数据的压缩率。但你需要确保，在极端情况下（压缩率很低），系统仍有足够内存运行。一般建议ZRAM大小为物理内存的50%-100%。对于内存小于4GB的设备，甚至可以设置到物理内存的2倍。

5. 内存压缩（MGLRU）与主动压缩策略

前面讲的ZSWAP和ZRAM，都是在内存页即将被换出（回收）时进行的“被动”压缩。内核中还有更“主动”的压缩策略，其代表就是与多代LRU（MGLRU）页面回收框架结合的内存压缩。

5.1 MGLRU 框架简介

传统的LRU链表在面临大规模、复杂的工作负载时（如数据库、容器混部），扫描效率和准确性会下降。MGLRU是社区推出的新一代页面回收框架，它将页按“代”分类，并更智能地跟踪页的访问热度。从内核6.1版本开始逐渐成为默认选项。

5.2 主动压缩的工作机制

在使能了特定编译选项或通过参数开启后，内核可以在页面回收的扫描阶段就进行压缩，而不是等到决定换出时。其逻辑是：

1. 内核的kswapd或直接回收线程开始扫描LRU链表寻找可回收页。
2. 对于扫描到的、被认为“近期可能不会访问”的匿名页，回收器会尝试直接压缩它。
3. 压缩成功后，该页被标记为“压缩页”，其内容被移动到一块专用的压缩内存池中，原页帧立即释放。
4. 当应用程序再次访问这个页时，触发“解压缺页异常”，内核从压缩池中解压数据，恢复到新的页帧中。

这个过程发生在页面被正式换出到Swap设备之前，是一种更早、更积极的内存释放手段。它甚至可以与ZSWAP协同工作：主动压缩的页，如果后来需要被换出，可以直接成为ZSWAP缓存中的压缩条目，避免了重复压缩。

5.3 配置与监控

主动压缩通常不是通过一个简单的开关控制，而是与内核的页面回收参数深度集成。相关参数可能包括：

• vm.zone_reclaim_mode：在某些NUMA架构下影响回收策略。
• MGLRU相关的/sys/kernel/mm/lru_gen/下的参数。

启用主动压缩通常需要内核在编译时开启CONFIG_COMPACTION和与透明巨页、MGLRU相关的选项。对于主流发行版的内核，可能默认就包含这些能力，但默认策略可能偏保守。

监控压缩效果：可以查看/proc/vmstat文件中的相关计数器：

• compact_migrate_scanned,compact_free_scanned：内存规整扫描的页数。
• pgmajfault：主要缺页异常数（可能涉及磁盘I/O）。在启用压缩后，观察此数值的增长是否变缓，可以间接说明压缩避免了部分Swap。

实操心得：主动压缩策略更像是一把“手术刀”，它在内存子系统更深的层面动手术。对于普通用户，ZRAM/ZSWAP已经能解决90%的问题。主动压缩更适合那些需要极致内存利用率、工作集巨大且访问模式复杂的特定场景，比如超大规模虚拟化主机或内存价格极高的硬件环境。调整这些参数需要深厚的系统知识，且效果因负载而异，建议在测试环境中充分验证。

6. 性能调优、监控与常见问题排查

选择了合适的技术，如何让它发挥最佳效果？如何知道它是否在正常工作？

6.1 压缩算法选型基准测试

不要盲目相信“默认”或“口碑”。在你的实际硬件和工作负载上做一个小测试很有必要。

简易测试方法：

# 安装测试工具（如未安装） # Ubuntu/Debian: sudo apt install zstd lz4 lzop # CentOS/RHEL: sudo yum install zstd lz4 lzop # 创建一个测试文件（内容越接近真实内存数据越好，比如随机数据） dd if=/dev/urandom of=./test.data bs=1M count=100 # 测试压缩速度、解压速度和压缩率 for algo in lzo lz4 zstd gzip; do echo -n "Testing $algo: " # 注意：此命令仅测试用户态工具性能，与内核实现有差异，但趋势可参考 time -p (sh -c "cat test.data | ${algo} -c > /dev/null" 2>&1 | grep real) # 查看压缩率 cat test.data | $algo -c | wc -c done rm test.data

观察输出，在“压缩时间”和“压缩后大小”之间做权衡。对于内存压缩，压缩/解压速度的权重通常高于压缩率，因为延迟是首要敌人。

6.2 关键监控指标

1. ZSWAP监控：

   cat /sys/kernel/debug/zswap/stored_pages # 当前存储在zswap中的页数 cat /sys/kernel/debug/zswap/pool_total_size # zpool当前总占用内存（字节） cat /proc/vmstat | grep -E “(zswap|swp)”

   关注stored_pages的增长情况。如果它一直很高，说明ZSWAP在持续发挥作用。如果zswap_writeback计数器增长很快，说明压缩缓存淘汰频繁，可能缓存大小不足。

2. ZRAM监控：

   cat /sys/block/zram0/mm_stat

   这个文件输出多行数据，其中：

   • compr_data_size：压缩后数据实际占用的内存大小。
   • orig_data_size：原始未压缩数据的大小。
   • mem_used_total：ZRAM设备总内存消耗（包括元数据）。 计算实际压缩率：orig_data_size / compr_data_size。通常维持在2-3倍是比较健康的状态。

3. 系统级监控：

   • vmstat 1：查看si（swap in）和so（swap out）列。启用ZRAM后，这两个值应该长期为0或极低，因为交换发生在内存内部。如果还有值，说明ZRAM空间用尽，触发了磁盘Swap。
   • sar -B 1：查看页统计和Swap活动。
   • free -h：结合available列判断内存压力。

6.3 常见问题与排查技巧

问题1：启用了ZRAM/ZSWAP，但系统依旧很卡，磁盘灯狂闪。

• 排查：检查vmstat的si/so，如果很高，说明内存压力巨大，ZRAM空间已被填满，系统在向磁盘Swap换页。
• 解决：
  • 增加ZRAM的disksize（如果还有空闲内存）。
  • 检查是否有内存泄漏的进程（top或smem）。
  • 考虑增加物理内存，或者优化应用程序内存使用。
  • 对于ZSWAP，检查/sys/kernel/debug/zswap/下的reject_*计数器，如果reject_compress_poor很多，说明压缩率太低，可以尝试换压缩算法（如从lzo换到lz4或zstd）。

问题2：系统CPU使用率变高，怀疑是压缩导致的。

• 排查：使用top或pidstat查看系统态CPU使用率（%sy或%system）。使用perf工具采样内核函数，查看zram_compress、zram_decompress或压缩算法相关函数是否出现在热点中。
• 解决：
  • 切换到更轻量的压缩算法，如从zstd换到lz4甚至lzo。
  • 评估是否过度压缩。如果内存压力并不大，ZRAM/ZSWAP的活跃度本应很低。高CPU可能是由其他原因引起。

问题3：ZRAM设备无法创建或初始化失败。

• 排查：检查内核是否支持CONFIG_ZRAM。查看dmesg | grep zram日志。
• 解决：
  • 确保zram内核模块已加载（lsmod | grep zram）。
  • 检查/sys/block/下是否有zram0设备节点。
  • 确保设置的disksize值格式正确（如4G）。

问题4：想禁用ZRAM或ZSWAP。

• ZRAM：

  sudo swapoff /dev/zram0 sudo rmmod zram # 如果确认不再需要

• ZSWAP：

  echo 0 > /sys/module/zswap/parameters/enabled

  或者修改内核引导参数，移除zswap.enabled=1。

内存压缩技术是Linux内核应对内存资源紧张的一件利器，它巧妙地在CPU和内存之间进行权衡。对于今天的多核处理器，用一点富余的CPU算力来避免致命的磁盘I/O等待，是一笔非常划算的买卖。从我个人的经验来看，在绝大多数场景下，启用ZRAM并配合lz4算法，是性价比最高、最省心的选择，它能将Swap的性能损耗从“灾难级”降为“可接受级”。当然，具体选择还需结合你的实际负载、硬件配置和性能监控数据来定。希望这篇深入的分析，能帮助你在下次面对内存压力时，多一份从容和把握。