.. _zram_zswap_zcache: =========================================== ``zram`` vs ``zswap`` vs ``zcache`` =========================================== 在 Ask Ubuntu 有一个辨析 ``zram`` vs ``zswap`` vs ``zcache`` 的文章: `zram vs zswap vs zcache Ultimate guide: when to use which one `_ : 概述 ============ - :ref:`zram` : 不需要在磁盘设备(HDD/SDD)上有交换设备，直接在内存中构建压缩块设备，可以作为常规文件系统，也可以提供内存页交换功能 - :ref:`zswap` : 需要结合磁盘设备(HDD/SDD)的交换设备文件，通过拦截交换到磁盘的内存页进行内存池压缩来加速内存换页性能 - zcache: 针对文件系统页缓存的加速，用以提高文件系统性能 对比 ====== ZRAM ------ ZRAM使用: - ZRAM 在内存中创建块设备 - 当数据写入ZRAM数据块块时候，数据压缩 - 当ZRAM作为交换设备时，ZRAM比其他交换设备优先级更高: 被换出的页面优先发送到ZRAM设备(你可以理解为内存到内存)，直到ZRAM满了以后才会使用其他任何交换设备 ZRAM优点: - 独立于其他(物理)交换设备 - 当没有交换分区时候可以使用ZRAM来扩展可用内存: 你可以理解为ZRAM是内存中的一个天然压缩分区，所有进入这个内存区域的数据都会得到压缩，所以相对于普通内存区域可以存储更多内存数据 ZRAM缺点: - 会影响其他交换设备(HDD/SSD)使用: ZRAM是一个独立的交换设备，一旦满了以后，任何需要换出的新页面都会直接发送到下一个交换设备，这就导致: - 存在LRU(最近最少使用)反转的可能性: 最近交换的数据将进入慢速磁盘，而很久以前交换出的非活动页面将保留在快速ZRAM中(也就是因为ZRAM存满了以后，内存交换数据就会直接存到磁盘交换文件中，而不是将ZRAM中冷数据换到磁盘，热数据放到ZRAM) - 由于发送到磁盘交换的数据没有压缩，会导致从磁盘来回的数据消耗大量带宽 ZRAM状态: - ZRAM已经合并到内核主线3.14 - 一旦在系统中启用ZRAM，就需要一些用户空间配置来设置交换设备并使用它们 ZSWAP ------ ZSWAP使用: - ``frontswap`` 系统hooks尝试换出页面，并使用zswap作为HDD/SSD交换设备的回写缓存(你可以理解为物理磁盘配置了一个巨大的缓存，所有写磁盘会经过这个缓存) - zswap会尝试压缩页面，但如果是可压缩性较差的数据，则直接写入磁盘；如果数据被压缩，则存储在zswap的内存池中 - 当RAM中压缩页面总数超过一定大小时将页面换出内存，则最近最少使用(LRU)压缩页面将被写入磁盘(因为不太可能很快用到) ZSWAP优点: - 非常高效地使用RAM和基于磁盘的交换: 通过减少所需的写入和读取次数(数据被压缩并保存在RAM中)以及由于数据处于压缩形式而减少这些I/O操作的带宽，最大限度地减少磁盘I/O ZSWAP缺点: - zswap是基于磁盘的交换系统的增强，所以它依赖硬盘上的交换分区(实际上就是磁盘交换分区的缓存，类似于以前硬件RAID卡上的缓存) ZSWAP状态: - ZSWAP已经合并到内核主线3.11 ZCACHE ------- ZCACHE使用: - ``zcache`` 相当于超级内存系统(Transcendent memory system)的后端: 这种超级内存系统提供了类似RAM的内存，通过使用 ``put`` 和 ``get`` 调用一次只能访问一个页(这与一次只能访问一个字节的普通内存不同) - ``frontswap`` 和 ``cleancache`` 系统hook分别尝试交换和回收文件系统页面缓存，并将它们发送到超级内存后端 - 当 ``zcache`` 用作后端时，数据被压缩并存储在RAM中 - 当 ``zcache`` 存满后，压缩页面将被驱逐到交换区(另一个后端是 ``RAMster`` ，它在联网计算机之间共享RAM池) - 仅使用 ``frontswap`` 前端和 ``zcache`` 后端的工作方式和 ``zswap`` 相似 (实际上 ``zswap`` 是 ``zcache`` 的简化子集) ZCACHE优点: - 为交换和文件系统缓存提供压缩缓存 ZCACHE缺点: - 仍然没有进入内核主线，因为 ``zcache`` 非常复杂并且还在开发 我的思考 ============= 在生产环境中，应用日志是我们分析系统排查故障的基础，但是日志打印也会影响应用性能，所以我们倾向于采用快速的SSD作为日志存储(但是成本较高)，而 ``zram`` 给我们带来一个特定应用环境的解决方案: - 极端性能压榨需要比SSD更快的日志存储，并且很多日志会通过 :ref:`log_systems` 采集，所以不需要在本地长期存储。如果能够控制日志生成和采集的平衡，那么采用 ``zram`` 可以实现用一定的内存空间换取 **性能提升** 并节约本地磁盘存储(内存的读写寿命要比Flash机制的SSD存储高很多) - 如果内存价格便宜，我们可以为每个服务器多配置几百G的内存作为高性能存储的替代，专用于要求高性能同时不要求数据可靠性的场合: 既然日志最终是需要汇流到 :ref:`log_systems` 进行数据挖掘、 :ref:`machine_learning` ，那么类似 ``zram`` 的场景非常适合这种 **日志无盘化** - 服务器应该 :strike:`采用多网卡机构，离线日志、冷数据备份、控制台需要走和业务分流的通道` 采用QoS控制，对网络数据提供优先级不同的服务，确保业务数据优先，日志和管控数据降低级别(但不会出现阻塞)。这是一种计数难度极大的架构方案，如果开发和维护成本很高，那么或许传统的多网卡分离结构也是可以考虑的(简单粗暴但有效)` .. note:: - ``zcache`` 虽然具备先进的功能，但是没有得到广泛支持，开发也出现停滞，并且在内核 3.11 中删除，所以如果要使用会比较困难，而且结果可能也不必 ``zswap`` 好多少 - 对于桌面电脑，由于内存不足，常常需要使用swap交换分区，此时使用 ``zswap`` 可以通过内存压缩(相当于增加了一级缓存)提升性能 - 对于服务器环境，如果有充足内存(没有完全分配完)，则可以利用部分内存来实现 ``zram`` ，提供一种高性能(较小容量)日志暂存系统，对于提升系统性能会有比较大的帮助( ⚠️ 需要配套的 :ref:`log_systems` ) 参考 ======= - `zram vs zswap vs zcache Ultimate guide: when to use which one `_ - `Zram, Zcache, and Zswap: Which One Is the Best For You? `_ 提供了一些压缩算法性能对比测试，可以参考