关于mysql:JuiceFS-v017-发布通过-1270-项-LTP-测试

27次阅读

共计 1973 个字符,预计需要花费 5 分钟才能阅读完成。

小伙伴们大家好,JuiceFS v0.17 在国庆小长假降临之际如期公布了!这是咱们在 2021 年秋季推出的第二个版本,让咱们直奔主题,看看都有哪些新变动吧。

本次更新累计 80+ 提交,共有 9 位来自 JuiceFS 社区的小伙伴在 GitHub 上奉献代码。在这里,咱们向每一位贡献者示意最诚挚的感激,同时欢送屏幕前的你也退出到 JuiceFS 开源社区,奉献代码、文档或探讨想法。

通过 LTP 1270 项测试,Linux 零碎下兼容性更完满

JuiceFS 的最新版本针对 Linux 零碎环境做了进一步的优化,改良了 rename 和 setxattr 读其余参数的反对,顺利通过了 LTP 的 1270 项测试。

LTP(Linux Test Project)是一个由 IBM,Cisco 等多家公司联合开发保护的我的项目,旨在为开源社区提供一个验证 Linux 可靠性和稳定性的测试集。LTP 中蕴含了各种工具来测验 Linux 内核和相干个性。

测试后果

Testcase                                           Result     Exit Value
--------                                           ------     ----------
fcntl17                                            FAIL       7
fcntl17_64                                         FAIL       7
getxattr05                                         CONF       32
ioctl_loop05                                       FAIL       4
ioctl_ns07                                         FAIL       1
lseek11                                            CONF       32
open14                                             CONF       32
openat03                                           CONF       32
setxattr03                                         FAIL       6

-----------------------------------------------
Total Tests: 1270
Total Skipped Tests: 4
Total Failures: 5
Kernel Version: 5.4.0-1029-aws
Machine Architecture: x86_64

其中,跳过和失败的我的项目次要是因为几个尚未反对的性能,详情见此文档。

优化存储长期数据的性能

针对 Spark 的 shuffle 文件等长期数据存储需要,社区贡献者 祝威廉(@allwefantasy)给 JuiceFS 奉献了数据提早上传性能,它能够让 JuiceFS 优先将数据写入到本地缓存盘中,如果这些数据在短时间内又被删除,则无需写入对象存储,能够提供靠近本地盘的读写性能。而当写入数据很多时,又会主动写到对象存储来开释本地盘空间,再也不必放心 shuffle 数据把磁盘写满了。

这个新性能让 JuiceFS 能够作为一个弹性本地盘应用,为长期数据提供有限存储空间和低延时拜访。

为了进一步晋升性能,还新增了一个运行在客户端内存中的元数据引擎(MemKV)。与其余元数据引擎一样,MemKV 的作用也是用来保留数据相干的元信息,但它不长久化,客户端 umount 当前,MemKV 的元数据就开释了。MemKV 齐全在内存中运行,有着相对的性能劣势,非常适合用作临时文件的存储场景。

TiKV 元数据引擎在 Hadoop 场景中性能晋升 5 倍

JuiceFS Java 客户端须要频繁做门路解析,Redis 引擎通过 Lua 实现了服务器端的多级门路解析,而 SQL 和 TiKV 引擎依然须要屡次元数据申请能力解析一个门路,尤其是当门路比拟深时对影响有比拟大的影响。

为了解决这个问题,本次更新在 JuiceFS Hadoop SDK 客户端中引入了相似于 Linux 内核的元数据缓存机制,能够别离通过参数管制目录、文件和属性的过期工夫。能够通过如下的形式启用:

<property>
  <name>juicefs.attr-cache</name>
  <value>3</value>
</property>
<property>
  <name>juicefs.entry-cache</name>
  <value>3</value>
</property>
<property>
  <name>juicefs.dir-entry-cache</name>
  <value>3</value>
</property>

以下是对 9 层目录的元数据性能测试,能够看到启用元数据缓存够大幅晋升元数据操作的性能。(数值代表操作的时延,越小越好。)

但须要留神的是,开启元数据缓存后会影响多客户端之间的一致性(无限工夫窗口的最终一致性),比方一个客户端删除了某个文件后,其余节点可能因为缓存未到期,依然认为文件存在。因而,个别倡议在查问场景下应用该性能。如果是混合读写的场景,倡议适当开启目录和属性的缓存,而敞开文件项的缓存。

1 分钟上手性能测试,后果高深莫测

咱们为 JuiceFS 内置的性能测试工具 bench 的后果做了进一步的优化,在简洁直观的根底上,进一步的让要害数据高亮显示,如果某项性能数据偏离失常区间,会显示为黄色甚至红色,倡议特地关注下。

无关 JuiceFS 新版的更多内容,欢送拜访 GitHub 我的项目主页理解详情:

举荐浏览:
如何借助 JuiceFS 为 AI 模型训练提速 7 倍
如何利用 JuiceFS 的性能工具做剖析和调优

正文完
 0