BTRFS - Performance

备注：本文翻译自：IBM Research Report - BTRFS

没有商定的测试文件系统性能的标准。虽然有NFS和CIFS的行业基准，他们仅仅覆盖现场看到的一小部分的工作量。在一天结束时，对用户来说最重要的是他特殊应用的性能。检查哪个文件系统时最好的匹配一个特殊的使用例子的唯一现实的方法时去尝试几种文件系统，看看哪一种工作的最好。

因为我们不能覆盖所有的用例，我们选择了一种常见的基准，去展示BTRFS与同期的比较。在写的时候，主要Linux文件系统，除了BTRFS，是XFS,EXT4。这些很显然是很成熟的系统，并且我们不希望去更好的执行数量级（啥意思这是）。我们的贡献是支持新功能的文件系统，比如快照和数据校验，在最大负载之下提供合理的性能。

两种存储配置被选择：一个硬盘和一个SSD。

（一）硬盘

所有在单个插槽上运行的硬盘测试3.2 Ghz四核x86处理器，单个SATA驱动器上具有8 Gb内存，带有6gb / s链路。

第一个测试时一个Linux kernel make，从干净的源文件树开始。收集了一个块跟踪，从命令 make -j8 开始。这个启动了8个并行线程编译和链接gcc。表1比较了在三种文件系统之间的吞吐量， seek count and IOps。EXT4的吞吐量略高于BTRFS和XFS，平均吞吐量不到两倍。所有文件系统保持每秒大约相同的搜索量，BTRFS的平均搜索更少一些。BTRFS运行初期的飙升很大可能是因为处理在不同块组之间反弹的初始写入时写入位。一旦额外的块组被分配去处理元数据加载，一切顺利。每秒的IO操作有点紧密，但是EXT4再次获胜。编译时间都在几秒之内。内核编译测试往往有点元数据密集，对于一个拥有强负载的应用这是一个很好的基准。整体情况是文件系统通常都是平价的。

表1：内核编译，所有文件系统展示类似的性能

FFSB测试尝试去模仿一个邮件服务器。它在1000目录下创建了500000文件，尺寸从1KB到1MB不等，加权到32KB或者更小不等。一旦它创建文件，他消费300秒去创建，删除或者读取整个文件，都是以4KB的块大小尺寸。读取的权重高于创建，创建高于删除以尝试表示邮件服务器的工作方式。测试可以被修改去使用任意数量的线程，更简单地，我们使用一个线程。FFSB测量吞吐量和每秒的交易量。看表2

表2：在FFSB邮件服务运行期间的吞吐量。XFS使用最少的带宽，EXT4使用最多，BTRFS处于中间。

表3：FFSB中的每秒交易量。BTRFS展示了相对好的性能。

这个工作量有利于EXT4，BTRFS略微落后，XFS性能只有BTRFS的一半.

最终测试处理写性能。Tiobench以一个特定数量的线程写一个给定的尺寸到文件中。我们使用一个2000MB的文件并且运行1，2，4，8和16个线程。两个测试显示总体上BTRFS运行最快。在随机情况下主导了其他两个文件系统。随机情况下有可能BTRFS更好，因为它写任何地方，并且因为我们使用范围锁去写而不是全局的inode锁，这样使得并行操作会更快。性能随着额外的线程有些下降，因为共享inode 锁的争夺。

表4：TIO benchmark, sequential

表5：TIO benchmark,random

这仅仅是三个测试并且绝不能用各种方式去使用文件系统。幸运的是，他们代表了大多数文件系统的使用方式。在所有这些例子中，BTRFS与成熟的同类产品差不多。

（二）Flash disk

Flash disks 正在变得普及，在许多现代笔记本电脑中正在代替传统的硬盘。手机和嵌入式设备运行普通的Linux也会使用flash disks。这个对优化BTRFS对SSDs有一个持续性的激励。我们描述了一些工作；代码是Linux Kernel 3.4的一部分。硬件使用一个FusionIO 设备。

表6描绘了Linux 3.3内核的性能，用BTRFS创建32百万的空文件。表是由Seekwatcher生成的，一个可视化硬盘移动的工具。在顶部表X轴是时间，Y轴是硬盘磁头的定位，读取被标记为蓝色，写被标记为绿色。底部图表跟踪吞吐量。文件系统开始是空的，填写空文件作为测试进度。从图中出现的模式是一个连续的进展，在最后写新文件。文件元数据是批量的，并且在检查点的期间是顺序写的。检查点每三十秒会发生一次。它们导致许多的随机读，表现为散列的蓝点。读取需要访问空闲空间分配树，一个太大不适合在内存中的结构。额外的磁盘检索大大的减慢了系统的速度，也可以在吞吐量图表中看到。写进度不是线性的原因是检查点，额外的写一些新的数据，也会释放块；这些随后会被重复使用。

表6：内核3.3的性能。文件创建率是不稳定的。吞吐量是一系列的峰值和谷值。

为了提高性能，读取的数量不得不减少。核心问题证明是Linux 虚拟内存系统被使用的方式。VM假设分配页将被使用一会。BTRFS，使用许多临时的页因为写时复制的性质，数据可以在磁盘上移动。这个不匹配导致VM保持需要过期的页，减少缓存的效用。反过来，引起额外的页在空闲空间分配树中, 因为缓存的压力该分配树被抛出缓存中。在可用空间分配树中引起了额外的分页，由于高速缓存压力，该分页树被抛出缓存。修复是让BTRFS更加努力地从已经变为无效的VM页面中丢弃.表7展示性能提高的结果。读取的数量减少了，他们更加集中于检查点的间隔。吞吐量稳定于大约125MB/sec，文件创建率是每秒150000个。

表7：内核3.4的性能，4KB大侠的元数据页

测试展示了使用更大的页尺寸在flash中是有益的。表8展示了使用16KB元数据页的效果。每秒创建文件率是170000个。使用更大的元数据页尺寸对于RAID5/6集成是很重要的，因为它允许放置一个页在一个单独的RAID条带中。

表8：内核3.4的性能，16KB大小的元数据页。

在相同的硬件上，XFS执行每秒115000文件，EXT4执行110000个文件。我们相信这个是的文件系统具有可比性。

BTRFS - Performance相关推荐

2020年10月linux内核,Linux内核5.9于2020年10月12日发布
5.9内核已于48分钟前发布: 主要的变更如下(引用自:https://www.phoronix.com/scan.php?page=article&item=linux-59-feature ...
镁光ssd管理工具 linux,在 SSD 上使用 Btrfs 文件系统的相关优化
优化挂载参数在 Linux 中挂载 SSD 上的 btrfs,可以采用各种参数进行优化: # UUID=/btrfs defaults,ssd,discard,noatime,compress=lz ...
Improve Performance and Reduce Memory with PVRTC Textures and Cocos2d
转载自:http://www.uchidacoonga.com/2011/07/pvrtc-textures-and-cocos2d/ Hello everyone! A few months hav ...
笔试算法题（58）：二分查找树性能分析（Binary Search Tree Performance Analysis）
议题:二分查找树性能分析(Binary Search Tree Performance Analysis) 分析: 二叉搜索树(Binary Search Tree,BST)是一颗典型的二叉树,同时任 ...
LVM逻辑卷的缩减与删除，LVM逻辑卷快照，btrfs文件系统，网络管理
逻辑卷缩减缩减的时候要注意缩减的空间不要超过文件系统的空间,不然缩减的时候会损坏文件系统. 第一步要先取消挂载(必须) 第二部检查文件完整性(必须) e2fsck -f /dev/vg0/lv0 第 ...
mysql5.7 sql监控_MySQL5.7中 performance和sys schema中的监控参数解释
MySQL5.7中的mysql performance和sys 监控参数 1.performance schema:介绍在MySQL5.7中,performance schema有很大改进,包括引 ...
二值网络--Bi-Real Net: Enhancing the Performance of 1-bit CNNs
Bi-Real Net: Enhancing the Performance of 1-bit CNNs With Improved Representational Capability and A ...
CNN网络加速--Performance Guaranteed Network Acceleration via High-Order Residual Quantization
Performance Guaranteed Network Acceleration via High-Order Residual Quantization ICCV2017 本文是对 XNOR- ...
任务简介（Query Performance Prediction）
查询性能预测(Query Performance Prediction,简称QPP). 用户向搜索系统提交一个查询,搜索系统就返回结果.现在搜索系统希望多一个功能,即告诉用户,这次返回的结果是差还是好 ...

BTRFS - Performance

BTRFS - Performance相关推荐

最新文章

热门文章