From 62d4a8136aa1ac0c16c9acffb64cbfb61604aba4 Mon Sep 17 00:00:00 2001 From: aiminick <83101338@qq.com> Date: Mon, 31 Dec 2018 22:50:13 +0800 Subject: [PATCH] Update README.md --- README.md | 73 ++++++++++++++++++++++++++++++++----------------------- 1 file changed, 42 insertions(+), 31 deletions(-) diff --git a/README.md b/README.md index 05c4ae5..d244d6f 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,10 @@ [OPENFANS开源社区](http://www.openfans.org) [树莓派爱好者基地](http://rpifans.cn/) 荣誉出品 +---- + # 系统介绍 + 这是为树莓派(Raspberry Pi)**3B/3B+/3A** 所全新构建的: **Debian 9(Stretch)ARM64(Aarch64) 64位系统镜像** @@ -28,6 +31,7 @@ ------- # 关键特征 + ## 更新 1. 系统包更新至Debian稳定主线:2018-12-30 @@ -46,15 +50,15 @@ * **Ext4** - 主流Linux文件系统,经过多年的优化和使用是目前使用**最广泛**的Linux文件系统之一,在大量的企业生产环境中选用,非常的成熟和稳定,支持在线热扩容 +主流Linux文件系统,经过多年的优化和使用是目前使用**最广泛**的Linux文件系统之一,在大量的企业生产环境中选用,非常的成熟和稳定,支持在线热扩容 * **BtrFS** - 新兴的写时复制文件系统,支持更好的数据校验和快照功能,能提高文件系统的时间/空间性能,包括延迟分配,小文件的存储优化,目录索引等,支持在线热扩容 +新兴的写时复制文件系统,支持更好的数据校验和快照功能,能提高文件系统的时间/空间性能,包括延迟分配,小文件的存储优化,目录索引等,支持在线热扩容 * **F2FS** - 专门为 Flash Transition Layer 的 NAND 闪存开发的文件系统,在闪存随机读写性能上有较大提升,对小文件读取也有一定的优化,不支持在线扩容 +专门为 Flash Transition Layer 的 NAND 闪存开发的文件系统,在闪存随机读写性能上有较大提升,对小文件读取也有一定的优化,不支持在线扩容 **考虑到系统的健壮性和稳定,我们推荐使用 Ext4 。** @@ -121,7 +125,7 @@ Docker官方没有提供基于arm的**docker-compose**可运行二进制程序 **docker-compose aarch64** 二进制文件的下载地址:[**点击前往下载**](https://github.com/openfans-community-offical/Debian-Pi-Aarch64/tree/master/docker-compose-aarch64) -目前最新版本:** v1.23.2 +**目前最新版本:** v1.23.2 ##### Docker Machine @@ -179,32 +183,38 @@ AUFS曾是Docker默认的首选存储驱动,它非常的稳定、有很多真 * **zSWAP的好处** - 1. 当内存页将要交换出去时,zSWAP不将其移动到交换设备,而是对其执行压缩,然后存储到系统RAM内动态分配的内存池中,回写到实际交换设备的动作则会延迟,甚至能完全避免,从而显著减少Linux系统用于交换的I/O。对于树莓派这样依托于TF卡的设备,本来I/O就不是很高,减少用于交换的I/O的操作就意味着**提高系统性能**,把I/O用在系统应用程序等更需要的其他调度上去 - 2. 在使用Swap文件/分区的场景下,由于减少了对Swap文件/分区的I/O操作,**可以提升TF的使用寿命** - 3. zSWAP并不虚拟一个块设备,而是hook到普通的Swap代码里,在实际发生写入到磁盘/从磁盘读取的操作前,先利用自己管理的内存进行数据的换出/换入,内存不够用以后再使用传统的Swap文件/分区。所以zSWAP适用于本身已经有交换分区的系统,以及树莓派这样本身内存不大的硬件设备 +```shell +1. 当内存页将要交换出去时,zSWAP不将其移动到交换设备,而是对其执行压缩,然后存储到系统RAM内动态分配的内存池中,回写到实际交换设备的动作则会延迟,甚至能完全避免,从而显著减少Linux系统用于交换的I/O。对于树莓派这样依托于TF卡的设备,本来I/O就不是很高,减少用于交换的I/O的操作就意味着**提高系统性能**,把I/O用在系统应用程序等更需要的其他调度上去 +2. 在使用Swap文件/分区的场景下,由于减少了对Swap文件/分区的I/O操作,**可以提升TF的使用寿命** + +3. zSWAP并不虚拟一个块设备,而是hook到普通的Swap代码里,在实际发生写入到磁盘/从磁盘读取的操作前,先利用自己管理的内存进行数据的换出/换入,内存不够用以后再使用传统的Swap文件/分区。所以zSWAP适用于本身已经有交换分区的系统,以及树莓派这样本身内存不大的硬件设备 +``` * **为什么不使用zRAM** zSWAP同时使用内存和交换分区,并根据实际情况自动调整所占内存的大小,所缓存的数据在系统内存不够用时会自动存入到Swap文件/分区中,大大提高了系统swap交换的效率,更充分的利用了内存空间资源又避免了系统出现内存不够的情况,而zRam完全使用内存来进行操作和存储数据,完全占用内存,一般用在大内存的场景,这对于内存很小的树莓派来说就不合适了。 * **zSWAP在本系统中使用的内存分配器和数据压缩算法** - -**内存分配器zpool框架:** *zsmalloc、zbud、z3fold* - - 1. 现实表明,zsmalloc虽然压缩率高,但是算法复杂,还需要额外的线程负责内存整理,耗费更多的cpu时间; - 2. 而zbud实现简单,以内存page为单位的存储又不会产生内存碎片,但是压缩率低,最高只有2倍,不满小内存系统的实际需求; - 3. 因此,索尼开发了z3fold内存分配器,和zbud的实现完全一致,只是每个page可以存储3个compressed page,**最高压缩率有 *3* 倍**,逼近zsmalloc的4倍,该技术在xperia xzp的中使用,使4GB的手机获得超过4GB内存的体验; - -我们在系统中选用了 **z3fold** 算法,在系统 /boot/cmdline.txt 中可以看到配置: ```shell - zswap.enabled=1 zswap.zpool=z3fold zswap.compressor=lz4 zswap.max_pool_percent=25 -``` -**压缩算法:** +内存分配器zpool框架: smalloc、zbud、z3fold + +1. 现实表明,zsmalloc虽然压缩率高,但是算法复杂,还需要额外的线程负责内存整理,耗费更多的cpu时间; + +2. 而zbud实现简单,以内存page为单位的存储又不会产生内存碎片,但是压缩率低,最高只有2倍,不满小内存系统的实际需求; + +3. 因此,索尼开发了z3fold内存分配器,和zbud的实现完全一致,只是每个page可以存储3个compressed page,**最高压缩率有 *3* 倍**,逼近zsmalloc的4倍,该技术在xperia xzp的中使用,使4GB的手机获得超过4GB内存的体验; + +我们在系统中选用了 **z3fold** 算法,在系统 /boot/cmdline.txt 中可以看到配置: + +zswap.enabled=1 zswap.zpool=z3fold zswap.compressor=lz4 zswap.max_pool_percent=25 + +压缩算法: Linux有很多压缩算法:lz,lzo,xz,gzip,lzma... -我们这里采用了拥有**极高压缩速度**和较高压缩率的 **lz4** ,lz4 相对于其他压缩算法而言,压缩率不是最高的,但速度确是最快的,在已采用 z3fold 算法的情况下,结合树莓派本身的性能特点和实际的测试,在拥有不错的压缩率的情况下,速度对于树莓派来说才是最重要的(考虑到本身CPU性能开销和内存大小的情况)。 +我们这里采用了拥有极高压缩速度和较高压缩率的lz4 ,lz4相对于其他压缩算法而言,压缩率不是最高的,但速度确是最快的,在已采用 z3fold 算法的情况下,结合树莓派本身的性能特点和实际的测试,在拥有不错的压缩率的情况下,速度对于树莓派来说才是最重要的(考虑到本身CPU性能开销和内存大小的情况)。 +``` ### KVM 虚拟化支持 @@ -311,7 +321,9 @@ VideoCore 是一个由Alphamosaic Ltd开发并且现在被Broadcom拥有的低 截图!! -#