Swap

内存吃紧时，冷页面常被送去慢速磁盘；zram 则用压缩的内存替代这一步，用小部分 CPU 换取可观的内存空间。 内存里的压缩块设备 zram 是一块驻留在内存里的块设备,它不跟磁盘对话,而是先在内存里把换出的页压缩、保存起来。内核把一页换给它时,页先被压缩、留在内存中,于是内存方面的减压方式并不是「把页挪去磁盘」,而是「让这一页变小」。因为设备本身挂在内存上,读写它的速度远比磁盘后备 swap 快;可它的容量同样受制约——既取决于当前这页有多可压缩,也取决于你愿意拿多少真实内存去换这块 swap。 压缩就是这笔交易 「压缩」就是这笔交易赚头所在,也是「一台小机型显得能装下比物理内存更多内容」的根源。一页值不值得压要看内容:全零页、文本和有结构的数据都缩得不错,而图片、压缩包这类已经被压缩过的对象几乎缩不动。站在工程视角看,zram 等于把暂时闲置的 CPU 换算成「看似更多」的内存;当初工作负责多半是可压缩的、又特别想避开真实磁盘换页的延迟时,这笔交易才划算。 适合服务器与低端设备 它最合身的地方是那些内存不多、换页压力又不过度的机器:小 VPS、容器宿主机,以及手机、路由器这类如今要把袖珍机器安排得明明白白的角色。反过来,内存本来就充裕、或者本来就要换到冷冷盘上的服务器,同一笔钱买一张真实磁盘往往能装下更多,因此未必轮到 zram。实用的判断方法是盯住压缩率和 swap 使用量:当驻留数据始终很小、又够可压缩、且 CPU 相对空闲,才是让 zram 出场的时刻。 坏掉的样子 最常见的失望是压缩比根本没有到来。照片、视频、加密缓冲和已经压过的归档几乎压不动，mm_stat 里 orig_data_size 只比 compr_data_size 大一点，交换空间却照样被占满。内存池和元数据照样吃掉真实内存，腾出来的余量几乎为零，杀手来得和没开压缩交换一样快。压缩比是数据的属性，不是设备的属性，容量只能按实测值去估。 选错算法是死在处理器上，不是死在容量上。重型算法放在小内存虚拟机或旧手机上，每次换出都要烧大量周期，回收线程转个不停，系统态占用随压力一起涨，交换还没满，长尾延迟先垮了。交互型机器先选 lzo-rle、lz4 或低档 zstd 这类快速算法，换算法前一定要在真实负载下看占用和延迟。 同时打开 zswap 和压缩交换等于把同一页压两遍，白白浪费处理器。zswap 自己先留一块压缩池，再把已经压过的页交给压缩设备，后者几乎找不到可省的空间。两条路径一起烧处理器，交换看似用了不少，有效容量却没涨多少。一条交换路径只留一层压缩：要么把压缩设备当交换，要么让 zswap 走在磁盘交换前面，不要双开。 ...