共计 2344 个字符，预计需要花费 6 分钟才能阅读完成。
JuiceFS 是一款面向云原生环境设计的高性能 POSIX 文件系统，在 AGPL v3.0 开源协定下公布。作为一个云上的分布式文件系统，任何存入 JuiceFS 的数据都会依照肯定规定拆分成数据块存入对象存储（如 Amazon S3），绝对应的元数据则长久化在独立的数据库中。这种构造决定了 JuiceFS 的存储空间能够依据数据量弹性伸缩，牢靠地存储大规模的数据，同时反对在多主机之间共享挂载，实现跨云跨地区的数据共享和迁徙。
从 v0.13 公布以来，JuiceFS 新增了多项与性能监测和剖析相干的性能，从某种程度上说，开发团队心愿 JuiceFS 既能提供大规模分布式计算场景下的杰出性能，也能宽泛地笼罩更多日常的应用场景。
本文咱们从单机利用动手，看依赖单机文件系统的利用是否也能够用在 JuiceFS 之上，并剖析它们的拜访特点进行针对性的调优。
测试环境
接下来的测试咱们会在同一台亚马逊云服务器上进行，配置状况如下：
- 服务器配置：Amazon c5d.xlarge: 4 vCPUs, 8 GiB 内存, 10 Gigabit 网络, 100 GB SSD
- JuiceFS：应用本地自建的 Redis 作为元数据引擎，对象存储应用与服务器雷同区域的 S3。
- EXT4：间接在本地 SSD 上创立
- 数据样本：应用 Redis 的源代码作为测试样本
测试项目一：Git
罕用的 git 系列命令有 clone、status、add、diff 等，其中 clone 与编译操作相似，都波及到大量小文件写。这里咱们次要测试 status 命令。
别离将代码克隆到本地的 EXT4 和 JuiceFS，而后执行 git status 命令的耗时状况如下：
- Ext4：0m0.005s
- JuiceFS：0m0.091s
可见，耗时呈现了数量级的差别。如果单从测试环境的样本来说，这样的性能差别微不足道，用户简直是觉察不到的。但如果应用规模更大的代码仓库时，二者的性能差距就会逐步浮现。例如，假如两者耗时都乘以 100 倍，本地文件系统须要约 0.5s，尚在可承受范畴内；但 JuiceFS 会须要约 9.1s，用户已能感觉到显著的提早。为搞清楚次要的耗时点，咱们能够应用 JuiceFS 客户端提供的 profile 工具：
$ juicefs profile /mnt/jfs在剖析过程中，更实用的形式是先记录日志，再用 回放模式：
$ cat /mnt/jfs/.accesslog > a.log
# 另一个会话：git status
# Ctrl-C 完结 cat
$ juicefs profile --interval 0 a.log后果如下：
这里能够分明地看到有大量的 lookup 申请，咱们能够通过调整 FUSE 的挂载参数来缩短内核中元数据的缓存工夫，比方应用以下参数从新挂载文件系统：
$ juicefs mount -d --entry-cache 300 localhost /mnt/jfs而后咱们再用 profile 工具剖析，后果如下：
能够看到，lookup 申请缩小了很多，但都转变成了 getattr 申请，因而还须要属性的缓存：
$ juicefs mount -d --entry-cache 300 --attr-cache 300 localhost /mnt/jfs此时测试发现 status 命令耗时降落到了 0m0.034s，profile 工具后果如下：
可见一开始最耗时的 lookup 曾经缩小了很多，而 readdir 申请变成新的瓶颈点。咱们还能够尝试设置 --dir-entry-cache，但晋升可能不太显著。
测试项目二：Make
大型项目的编译工夫往往须要以小时计，因而编译时的性能显得更加重要。仍然以 Redis 我的项目为例，测试编译的耗时为：
- Ext4：0m29.348s
- JuiceFS：2m47.335s
咱们尝试调大元数据缓存参数，整体耗时降落约 10s。通过 profile 工具剖析后果如下：
显然这里的数据读写是性能要害，咱们能够应用 stats 工具做进一步的剖析：
$ juicefs stats /mnt/jfs其中一段后果如下：
从上图可见 fuse 的 ops 与 meta 靠近，但均匀 latency 远大于 meta，因而能够判断出次要的瓶颈点在对象存储侧。不难想象，编译后期产生了大量的临时文件，而这些文件又会被编译的后几个阶段读取，以通常对象存储的性能很难间接满足要求。好在 JuiceFS 提供了数据 writeback 模式，能够在本地盘上先建设写缓存，正好实用于编译这种场景：
$ juicefs mount -d --entry-cache 300 --attr-cache 300 --writeback localhost /mnt/jfs此时编译总耗时降落到 0m38.308s，曾经与本地盘十分靠近了。后阶段的 stats 工具监控后果如下：
可见，读申请根本全副在 blockcache 命中，而不再须要去拜访对象存储；fuse 和 meta 侧的 ops 统计也失去了极大晋升，与预期吻合。
总结
本文以本地文件系统更善于的 Git 仓库治理和 Make 编译工作为切入点，评估这些工作在 JuiceFS 存储上的性能体现，并应用 JuiceFS 自带的 profile 与 stats 工具进行剖析，通过调整文件系统挂载参数做针对性的优化。
毫无疑问，本地文件系统与 JuiceFS 等分布式文件系统存在着人造的特色差别，二者面向的利用场景也截然不同。本文抉择了两种非凡的利用场景，只是为了在差别显明的情境下介绍如何为 JuiceFS 做性能调优，旨在抛砖引玉，心愿大家触类旁通。如果你有相干的想法或教训，欢送在 JuiceFS 论坛或用户群分享和探讨。
举荐浏览
知乎 x JuiceFS：利用 JuiceFS 给 Flink 容器启动减速
我的项目地址 ：Github（https://github.com/juicedata/juicefs）如有帮忙的话 欢送关注咱们哟！ (0ᴗ0✿)
