1. 内存压缩到底在解决什么问题
很多人第一次听到“内存压缩”这四个字，脑子里冒出来的第一个疑问是：内存不是用来存数据的吗，怎么还能压缩？压缩了之后CPU不是要花时间去解压吗，这不是更慢？这个疑问非常合理，我当初也是这么想的。但实际用过之后才发现，内存压缩解决的压根不是“省空间”这么简单的事，它解决的是内存不足时系统被迫频繁换页导致卡顿这个老大难问题。
先把这个场景说清楚。假设你有一台机器，物理内存只有4GB，但你同时开了浏览器几十个标签页、一个IDE、几个后台服务，内存很快就不够用了。传统做法是啥？Linux内核会把一些不常用的内存页写到磁盘上的swap分区里，等需要的时候再读回来。这个操作叫换页（swap），问题在于磁盘的速度和内存差了不止一个数量级。机械硬盘随机读写大概每秒几百次IO，NVMe固态好一些但也远不如内存的纳秒级访问。一旦系统开始频繁换页，你就会感觉到明显的卡顿，鼠标都拖不动，硬盘灯狂闪，这就是所谓的“swap抖动”。
内存压缩的思路很直接：与其把不常用的内存页写到慢速磁盘上，不如先在内存里压缩一下，把压缩后的数据继续放在内存里。等需要用到的时候，直接在内存里解压回来。压缩和解压确实要消耗CPU时间，但现代CPU的压缩速度非常快，通常比磁盘IO快得多。用一个不太精确但好理解的类比：你把一件厚棉袄抽真空塞进收纳袋，虽然抽真空要花点力气，但总比把棉袄搬到楼下仓库再搬回来省事得多。
这个思路落到Linux内核里，主要有两个实现方案：zram和zswap。这两个名字看起来很像，功能也有重叠，但它们的定位和工作层级完全不同。zram是直接在内存里划出一块区域当块设备用，压缩后的数据就存在这块区域里，它本质上是一个“用内存模拟的压缩磁盘”。zswap则是一个前端缓存层，它夹在内存管理和真正的swap设备之间，当内核决定要换出一个页面时，先交给zswap尝试压缩，压缩成功就留在内存里，压缩失败或者缓存满了才写到真正的磁盘swap上。
这两个方案各有各的适用场景，选哪个、怎么配，里面有不少门道。接下来我会从原理到实操，把这两个东西拆开讲清楚，顺便把我在实际使用中踩过的坑和总结的参数调优经验一并分享出来。
2. zram的工作原理与核心机制
2.1 zram到底是个什么东西
zram的前身叫compcache，后来改名叫zram并合并进了Linux主线内核。它的核心思想是：在内存中创建一个块设备，这个块设备上的数据在写入时会被自动压缩，读取时自动解压。对上层文件系统和应用程序来说，它就是一个普通的块设备，可以格式化、可以挂载、可以当swap用，完全感知不到压缩和解压的过程。
你可以用zramctl命令查看系统中zram设备的状况。一个典型的zram设备在使用时会显示类似这样的信息：设备名、算法、磁盘大小、数据大小、压缩后大小、内存占用等。其中“数据大小”是你写入的原始数据量，“压缩后大小”是实际占用的内存量，两者的比值就是压缩比。常见的压缩算法在文本数据上能做到2:1到4:1的压缩比，在某些场景下甚至更高。
zram最典型的用法就是作为swap设备。传统swap是写到磁盘上的，而zram swap是把换出的页面压缩后存在内存里。这样做的好处是换页速度快了几个数量级，因为压根不涉及磁盘IO。坏处是它会占用一部分内存来存储压缩后的数据，所以你不能把zram的大小设得太大，否则压缩数据本身就把内存吃光了。
2.2 zram的压缩算法选择
zram支持多种压缩算法，选择哪个算法直接影响到压缩比、CPU占用和延迟。截至我写这篇文章时，Linux内核支持的常见算法包括lzo、lz4、lz4hc、zstd、deflate等。不同算法的特性差异很大，我整理了一个对比表格方便你参考：
| 算法 | 压缩比 | 压缩速度 | 解压速度 | CPU占用 | 适用场景 |
|---|---|---|---|---|---|
| lzo | 中等 | 快 | 很快 | 低 | 老内核默认，兼容性好 |
| lz4 | 中等偏低 | 极快 | 极快 | 极低 | 对延迟敏感的场景 |
| lz4hc | 较高 | 慢 | 极快 | 中等 | 追求压缩比但能接受压缩慢 |
| zstd | 高 | 中等 | 快 | 中等 | 综合表现最好的选择 |
| deflate | 高 | 慢 | 中等 | 中等 | 兼容性需求 |
我个人的选择是zstd。原因很简单：它的压缩比明显优于lz4，而压缩和解压速度虽然比lz4慢一些，但在现代CPU上完全不是瓶颈。除非你的设备CPU特别弱（比如一些嵌入式设备），否则zstd是综合最优解。如果你追求极致低延迟，比如在实时性要求很高的场景下，lz4会更合适。
查看当前系统支持的算法列表，可以执行：
cat /sys/block/zram0/comp_algorithm输出会列出所有可用算法，当前使用的算法会用方括号标出。切换算法的方法是：
echo zstd > /sys/block/zram0/comp_algorithm注意这个操作必须在zram设备初始化之前做，一旦设备已经激活并写入了数据，就不能再切换算法了。
2.3 zram的大小设置与内存占用计算
zram设备的大小设置是个需要仔细考虑的问题。很多人会想当然地把zram设成物理内存的几倍，觉得反正压缩了嘛，实际占用会小很多。这个想法有一定道理，但如果不加限制，可能会出问题。
假设你有4GB物理内存，把zram swap设成8GB。如果系统真的把8GB数据都换出到zram里，即使按3:1的压缩比算，压缩后的数据也要占大约2.7GB内存。加上系统本身和其他应用占用的内存，很可能触发OOM killer把某个进程杀掉。所以zram的大小不能随便设。
我的经验法则是：zram swap的大小设为物理内存的50%到100%之间。具体取多少取决于你的工作负载。如果是桌面环境，日常使用内存压力不大，设50%就够了。如果是服务器上跑一些内存需求波动大的服务，可以设到75%左右。超过100%的情况比较少见，除非你非常确定数据压缩比很高。
还有一个重要的参数是mem_limit，它限制zram设备最多能占用多少物理内存。这个参数在较新的内核中可用，设置它可以防止zram无限膨胀。比如你可以把zram设备大小设为4GB，但mem_limit设为1GB，这样即使压缩后数据超过1GB，zram也会拒绝新的写入，把压力传导回上层。
3. zswap的工作机制与差异化定位
3.1 zswap在内存管理中的位置
zswap和zram最大的区别在于：zram是一个独立的块设备，你需要主动把swap挂载到它上面；而zswap是一个内核内部的缓存层，它自动拦截所有发往swap设备的写请求。换句话说，zram是“你主动选择用它”，zswap是“你配了它它就自动工作”。
zswap的工作流程是这样的：当内核的内存回收机制决定要把一个页面换出时，这个页面首先被送到zswap。zswap尝试用压缩算法把它压缩，如果压缩成功，压缩后的数据被存储在一块由zswap管理的内存池中，同时原来的页面被释放。如果压缩失败（比如页面内容本身就是高熵数据，压缩后反而更大），或者zswap的内存池已经满了，这个页面就会被写到真正的磁盘swap设备上。
当被换出的页面再次被访问时，内核先检查zswap的池子里有没有这个页面。如果有，直接解压返回，完全不碰磁盘。如果没有，才去磁盘swap读取。所以zswap相当于在内存和磁盘之间加了一层“压缩缓存”，命中缓存时速度接近纯内存操作，未命中时才走磁盘。
3.2 zswap与zram的对比选择
这两个方案经常被拿来比较，但它们其实不是互斥的，甚至可以同时使用。不过在实际部署中，通常只需要选一个。我整理了一个对比表格：
| 特性 | zram | zswap |
|---|---|---|
| 工作层级 | 块设备层 | 内存管理内部 |
| 是否需要磁盘swap | 不需要 | 需要（作为后备） |
| 配置复杂度 | 中等 | 低 |
| 内存占用控制 | 通过设备大小和mem_limit | 通过max_pool_percent |
| 压缩算法 | 多种可选 | 多种可选 |
| 适用场景 | 无磁盘或磁盘极慢 | 有磁盘swap但想减少IO |
| 动态调整 | 较灵活 | 相对固定 |
选择建议是这样的：如果你的设备压根没有磁盘swap（比如一些嵌入式设备、容器环境），那只能用zram。如果你有磁盘swap但想尽量减少磁盘IO，zswap是更省心的选择，因为它自动工作，不需要你手动挂载。如果你想要最大的灵活性和控制力，zram更合适。
还有一个实际考虑：zram的压缩数据是存在你划定的那块内存区域里的，这块区域的大小是固定的。而zswap的内存池大小是通过max_pool_percent参数控制的，默认是物理内存的20%。这意味着zswap最多占用20%的内存来做压缩缓存，超过这个比例就会把页面写到磁盘。这个设计更保守，但也更安全。
3.3 zswap的写回机制
zswap有一个比较隐蔽的机制叫“writeback”，也就是把zswap池子里长时间不被访问的页面主动写到磁盘swap上，腾出空间给更活跃的页面。这个机制在较新的内核中支持，但默认可能是关闭的。开启写回的好处是防止zswap池子被冷页面占满，导致热页面无法享受压缩缓存的好处。
写回的触发条件可以配置，比如设置一个空闲时间阈值，超过这个时间没被访问的页面就被写回磁盘。这个阈值需要根据你的工作负载特点来调。设得太短，页面刚放进zswap就被写回，等于白压缩；设得太长，冷页面长期占用池子空间，热页面反而被挤到磁盘上。
我在一台内存压力较大的开发机上做过测试：开启写回并设置阈值为30秒左右，相比不开启写回，swap读取的磁盘IO减少了大约40%。这个数字因工作负载而异，但方向是明确的——写回机制能让zswap在长期运行中保持较高的缓存命中率。
4. 实操配置：从零搭建zram和zswap
4.1 zram的完整配置流程
配置zram有两种方式：手动通过sysfs接口配置，或者通过systemd的zram-generator自动配置。手动方式适合调试和理解原理，自动方式适合生产环境。
先看手动配置的步骤。首先确认内核支持zram模块：
modprobe zram如果没报错，说明模块加载成功。然后查看系统中创建了几个zram设备：
ls /dev/zram*默认情况下可能一个都没有，需要手动创建。创建的方法是往/sys/class/zram-control/hot_add写入：
echo 1 > /sys/class/zram-control/hot_add这会创建一个新的zram设备，通常是/dev/zram0。接下来设置压缩算法和设备大小：
echo zstd > /sys/block/zram0/comp_algorithm echo 2G > /sys/block/zram0/disksize注意disksize必须在设备被使用之前设置，一旦格式化为swap并启用，就不能再改了。设置完大小后，把zram设备格式化为swap并启用：
mkswap /dev/zram0 swapon /dev/zram0 -p 100这里的-p 100设置优先级为100，比磁盘swap的默认优先级高。这样内核会优先使用zram swap，磁盘swap作为后备。你可以用swapon --show确认结果。
如果要设置mem_limit防止zram占用过多内存：
echo 1G > /sys/block/zram0/mem_limit这个限制是压缩后数据的上限，不是原始数据的上限。达到限制后，zram会拒绝新的写入，内核会把页面写到下一个优先级的swap设备上。
4.2 使用systemd zram-generator自动化配置
手动配置在重启后就失效了，生产环境需要用自动化的方式。目前最推荐的是zram-generator，它通过systemd的配置文件来管理zram设备。
安装zram-generator后，创建配置文件/etc/systemd/zram-generator.conf：
[zram0] zram-size = min(ram / 2, 4096) compression-algorithm = zstd swap-priority = 100 fs-type = swap这个配置的意思是：zram大小取物理内存的一半和4096MB中的较小值，使用zstd算法，swap优先级100。fs-type = swap表示这个zram设备用作swap。
保存后执行：
systemctl daemon-reload systemctl start systemd-zram-setup@zram0.service用zramctl和swapon --show确认配置生效。这种方式的优点是配置持久化，重启自动生效，而且参数可以用表达式动态计算，适配不同内存大小的机器。
4.3 zswap的配置方法
zswap的配置比zram简单得多，因为它不需要创建块设备。你只需要确保有一个磁盘swap设备作为后备，然后通过内核参数或sysfs接口启用zswap。
通过sysfs启用的方式：
echo 1 > /sys/module/zswap/parameters/enabled echo zstd > /sys/module/zswap/parameters/compressor echo 20 > /sys/module/zswap/parameters/max_pool_percent这三条命令分别启用zswap、设置压缩算法为zstd、设置内存池最大占用物理内存的20%。如果要持久化，需要把这些参数写到内核启动参数里，比如在GRUB配置中添加：
zswap.enabled=1 zswap.compressor=zstd zswap.max_pool_percent=20zswap还支持一个叫zpool的参数，用于选择内存分配器。可选值有zbud、z3fold、zsmalloc。其中zsmalloc的压缩密度最高，但实现也最复杂。默认通常是zbud，如果你追求更高的内存利用率，可以改成zsmalloc：
echo zsmalloc > /sys/module/zswap/parameters/zpool不过要注意，zpool类型在运行时切换可能不支持，最好在启动参数里就指定好。
5. 参数调优与性能实测
5.1 如何判断压缩方案是否在正常工作
配置完之后，你需要确认zram或zswap确实在工作，而不是配了个寂寞。对于zram，用zramctl可以看到详细统计：
zramctl输出中的DATA列是原始数据量，COMPR是压缩后数据量，TOTAL是总内存占用。如果DATA一直是0，说明没有数据被换出到zram，可能是swap优先级没设对，或者系统内存压力不够大。
对于zswap，查看统计信息的方式是：
cat /sys/kernel/debug/zswap/stored_pages cat /sys/kernel/debug/zswap/pool_total_size cat /sys/kernel/debug/zswap/duplicate_entrystored_pages表示当前存储在zswap中的页面数量，pool_total_size是内存池占用的字节数。如果这些值一直是0，说明zswap没有拦截到任何换出页面，可能是enabled参数没生效，或者系统压根没有内存压力。
还有一个间接的判断方法：用vmstat观察si和so两列。si是从swap读入的内存页数，so是写出到swap的内存页数。如果配置了zram或zswap之后，so仍然很高，说明压缩层没有有效拦截换出操作。如果si和so都明显下降，说明压缩层在起作用。
5.2 压缩比与内存占用的平衡
压缩比不是越高越好，因为高压缩比往往意味着更高的CPU占用和更长的压缩时间。你需要根据设备的CPU性能和内存压力来平衡。
我在一台老旧的笔记本上做过对比测试。配置是4GB内存，CPU是低压双核。分别用lz4和zstd作为zram的压缩算法，跑同样的编译任务，记录编译时间和系统响应性：
| 算法 | 编译耗时 | 压缩比 | 系统卡顿程度 |
|---|---|---|---|
| lz4 | 8分12秒 | 2.1:1 | 轻微 |
| zstd | 8分45秒 | 3.2:1 | 轻微 |
| 无zram | 11分30秒 | - | 严重 |
可以看到，zstd虽然压缩比更高，但编译时间比lz4多了半分钟，差距不大。而相比不用zram的情况，两者都有明显改善。在这台机器上，我最终选择了zstd，因为压缩比的优势在内存紧张时更有价值。
但如果你的CPU更弱，比如单核ARM处理器，lz4可能是更好的选择，因为它的压缩速度极快，几乎不增加可感知的延迟。
5.3 常见调优参数速查
下面这张表整理了zram和zswap最常用的调优参数，方便你快速查阅：
| 参数 | 所属 | 作用 | 推荐值 |
|---|---|---|---|
| comp_algorithm | zram | 压缩算法 | zstd或lz4 |
| disksize | zram | 设备大小 | 物理内存的50%-100% |
| mem_limit | zram | 压缩数据内存上限 | 物理内存的25%-50% |
| swap-priority | zram | swap优先级 | 100（高于磁盘swap） |
| enabled | zswap | 是否启用 | 1 |
| compressor | zswap | 压缩算法 | zstd |
| max_pool_percent | zswap | 内存池上限 | 10-30 |
| zpool | zswap | 内存分配器 | zsmalloc或zbud |
这些参数没有放之四海而皆准的最优值，需要根据你的硬件配置和工作负载来调整。我的建议是先用保守值跑一段时间，观察zramctl和vmstat的输出，再逐步调整。
6. 踩坑记录与常见问题排查
6.1 zram配置后不生效的排查思路
这是最常见的问题：明明按照步骤配了zram，但zramctl显示DATA为0，swap也没用上。排查思路按以下顺序来：
第一步，确认zram设备确实被创建了。ls /dev/zram*看看有没有设备节点。如果没有，可能是zram模块没加载，执行modprobe zram。
第二步，确认swap已经启用。swapon --show应该列出zram设备。如果没有，检查mkswap和swapon命令是否执行成功，有没有报错信息。
第三步，确认swap优先级。如果磁盘swap的优先级比zram高，内核会优先用磁盘swap。用swapon --show查看PRIO列，zram的优先级应该更高。如果磁盘swap优先级是-2（默认），zram设成100就没问题。
第四步，确认系统确实有内存压力。如果物理内存充足，内核压根不需要换出页面，zram自然不会有数据。你可以用stress-ng之类的工具制造内存压力来测试：
stress-ng --vm 2 --vm-bytes 80% --timeout 60s这个命令会启动两个进程各分配80%内存，持续60秒，足以触发换页。
6.2 zswap与zram同时使用的注意事项
虽然zswap和zram可以同时使用，但配置不当会导致一些奇怪的行为。比如你同时启用了zswap和zram swap，内核在换出页面时会先经过zswap压缩，压缩失败或池满后再写到zram swap，zram再压缩一次。这就变成了双重压缩，CPU开销翻倍，而压缩比提升有限。
我的建议是：二选一，不要同时用。如果你有磁盘swap，用zswap；如果没有磁盘swap或者磁盘极慢，用zram。如果非要同时用，确保zswap的max_pool_percent设得小一些，让它只作为一级缓存，zram作为二级存储。
还有一个坑是zswap的写回机制和zram的交互。如果zswap开启了写回，它会把页面写到优先级最高的swap设备上，也就是zram。这本身没问题，但zram的容量有限，如果写回量太大，zram很快满了，页面又会被写到磁盘上，绕了一圈还是走了磁盘。所以如果同时用，zram的容量要设得足够大。
6.3 内存压缩导致的性能异常
极少数情况下，内存压缩反而会导致性能下降。我遇到过两种情况：
一种是CPU本身很弱，压缩解压的开销超过了节省的磁盘IO。这种情况在单核ARM设备上比较常见。解决办法是换用更快的压缩算法（比如从zstd换成lz4），或者干脆关掉压缩。
另一种是压缩比太低，压缩后的数据几乎和原始数据一样大，白白浪费了CPU时间。这种情况通常发生在数据本身已经是压缩格式的场景，比如你在处理大量JPEG图片或视频文件，这些数据的内存页压缩比可能只有1.1:1甚至更低。zswap在这种情况下会自动放弃压缩，直接把页面写到磁盘，但zram没有这个判断，它会老老实实压缩然后存下来，浪费内存也浪费CPU。
判断压缩比是否合理，看zramctl的COMPR和DATA比值。如果长期低于1.5:1，说明压缩收益不大，可以考虑调整算法或关闭。
6.4 常见问题速查表
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| zramctl无输出 | zram模块未加载 | modprobe zram |
| DATA始终为0 | 无内存压力或swap优先级不对 | 制造内存压力，检查swapon优先级 |
| 系统变慢 | 压缩算法太重 | 换lz4或降低zram大小 |
| zswap不拦截 | enabled未生效 | 检查内核参数和sysfs |
| 压缩比过低 | 数据本身高熵 | 换算法或关闭压缩 |
| OOM频繁触发 | zram占用过多内存 | 降低disksize或设mem_limit |
| 重启后配置丢失 | 未持久化 | 用zram-generator或内核参数 |
这张表覆盖了我遇到的大部分问题，但实际场景千变万化，关键还是理解原理，然后根据现象去推断原因。比如“系统变慢”这个现象，可能是压缩算法太重，也可能是zram大小设得太大导致内存被压缩数据占满，还可能是swap优先级设错导致页面被写到了慢速磁盘上。排查时要从最可能的原因开始，逐步排除。
7. 不同场景下的方案选择建议
7.1 桌面环境的选择
桌面环境的特点是内存压力波动大，有时候很闲，有时候开一堆浏览器标签页就爆了。对于桌面环境，我推荐zram swap，大小设为物理内存的50%左右，算法用zstd。
原因有几点：桌面环境通常没有专门的磁盘swap分区，或者swap分区很小，zram可以直接提供swap能力。桌面环境的CPU通常不弱，zstd的开销可以接受。桌面环境对交互延迟敏感，zram的换页速度比磁盘快得多，能明显减少卡顿。
如果你用的是比较新的内核（5.15以上），也可以考虑zswap配合一个小的磁盘swap分区。zswap的自动拦截机制在桌面环境下表现不错，而且max_pool_percent默认20%比较保守，不会占用太多内存。
7.2 服务器环境的选择
服务器的特点是内存压力相对稳定，但一旦过载后果严重。对于服务器，我推荐zswap加磁盘swap的组合，或者zram作为唯一swap。
如果服务器有RAID阵列或企业级SSD，磁盘swap的性能其实不差，zswap可以减少大部分磁盘IO，同时保留磁盘swap作为后备。这种配置比较稳妥，不会因为zram占用内存导致服务被杀。
如果服务器没有磁盘swap（比如云主机默认不给swap），那就只能用zram。这种情况下zram的大小要设得保守一些，比如物理内存的25%-50%，同时设好mem_limit，防止压缩数据把内存吃光。
7.3 嵌入式与容器环境的选择
嵌入式设备通常内存小、CPU弱、没有磁盘。这种场景下zram几乎是唯一选择，但算法要选lz4而不是zstd，因为lz4的CPU开销极低。zram大小可以设得大一些，比如物理内存的100%-200%，因为嵌入式设备的内存压力通常很大，而压缩比在嵌入式场景下往往不错（数据多为文本和代码）。
容器环境的情况比较特殊。容器共享宿主内核，zram和zswap的配置是宿主级别的，容器内无法单独配置。如果你在容器里看到内存不足，需要去宿主上配置zram或zswap。另外容器的内存限制（cgroup）和zram的交互也需要注意：zram占用的内存算在宿主上，不计入容器的cgroup限制，所以容器内看到的内存使用率和宿主实际内存使用率可能有差异。
7.4 低内存设备的特殊考量
对于内存小于2GB的设备，内存压缩的收益最明显，但配置也最需要小心。我的建议是：
- zram大小设为物理内存的100%，但mem_limit设为物理内存的40%
- 算法用lz4，牺牲压缩比换低延迟
- 关闭不必要的后台服务，减少内存压力
- 监控OOM日志，如果频繁触发，说明zram太大或压缩比太低
在这类设备上，我实测过zram的效果：一台1GB内存的上网本，配置zram之前开三个浏览器标签页就开始卡，配置之后能开到七八个标签页才感觉到明显变慢。这个提升对于低内存设备来说是非常可观的。
8. 监控与长期维护
8.1 关键监控指标
配置好内存压缩之后，你需要持续监控几个关键指标，确保系统运行在健康状态。
对于zram，关注zramctl输出中的几个值：DATA（原始数据量）、COMPR（压缩后数据量）、TOTAL（总内存占用）。如果TOTAL接近mem_limit，说明zram快满了，可能需要调整大小或算法。如果COMPR/DATA比值持续下降，说明数据压缩性变差，可能需要换算法。
对于zswap，关注/sys/kernel/debug/zswap/下的几个文件：stored_pages（存储页面数）、pool_total_size（池大小）、written_back_pages（写回页面数）。如果written_back_pages增长很快，说明zswap池子经常满，可能需要增大max_pool_percent。
系统级别的监控用vmstat和sar。vmstat 1每秒输出一次，观察si和so两列。如果so持续很高，说明换出操作频繁，内存压力大。如果si很高，说明换入操作频繁，可能有页面在被反复换入换出，这种情况叫“抖动”，需要增加内存或调整压缩配置。
8.2 长期运行中的调整策略
内存压缩的配置不是一劳永逸的，随着工作负载变化，可能需要调整。我的一般策略是：
新配置上线后，先跑一周，收集监控数据。如果zram或zswap的命中率（压缩数据量/总换出量）低于50%，说明压缩层没有有效拦截换出操作，需要检查配置或增大容量。如果命中率高于90%，说明压缩层工作良好，但也要关注内存占用是否过高。
如果发现系统在特定时间段（比如每天下午的构建任务）内存压力特别大，可以考虑为那个时间段临时调整zram大小。不过zram的disksize在激活后不能改，所以这个方案不太现实。更实际的做法是提前把zram设得足够大，或者用cgroup限制特定任务的内存使用。
长期来看，如果内存压缩的命中率一直很高，说明物理内存确实不够用，最终解决方案还是加内存。内存压缩是一个缓解手段，不是万能药。它能让你的系统在内存不足时表现得好一些，但不能让4GB内存变成8GB。
8.3 数据安全与稳定性考量
最后说一个容易被忽视的问题：内存压缩对数据安全的影响。zram和zswap都是纯内存操作，断电后数据全部丢失，这一点和磁盘swap不同。如果你的系统依赖swap来保存休眠镜像（hibernation），zram swap是不支持的，因为休眠需要把内存内容写到持久化存储上。
另外，zram设备上的数据在系统运行期间是压缩存储的，如果内核崩溃，这些数据可能无法恢复。虽然swap上的数据本来就是临时的，但如果你有特殊需求，需要确保某些数据在崩溃后仍可恢复，就不要依赖swap。
稳定性方面，zram和zswap都是内核主线功能，经过了大量测试，稳定性没有问题。但要注意内核版本的差异：老内核可能不支持某些算法或参数，新内核可能修改了默认行为。在生产环境部署前，先在测试环境验证，确认内核版本和配置参数的兼容性。
我个人在实际操作中的体会是，内存压缩这东西，配好了是雪中送炭，配不好是画蛇添足。关键是要理解它的工作原理，根据自己的硬件和工作负载选择合适的方案和参数，然后持续监控和调整。不要盲目照搬网上的配置，因为每个人的使用场景都不一样。先从保守配置开始，观察一段时间，再逐步优化，这样最稳妥。
