JuiceFS 性能评估指南-低调大师

JuiceFS 性能评估指南

2021-12-08 715

JuiceFS 是一款面向云原生环境设计的高性能 POSIX 文件系统，任何存入 JuiceFS 的数据都会按照一定规则拆分成数据块存入对象存储（如 Amazon S3），相对应的元数据则持久化在独立的数据库中。这种结构决定了 JuiceFS 的存储空间可以根据数据量弹性伸缩，可靠地存储大规模的数据，同时支持在多主机之间共享挂载，实现跨云跨地区的数据共享和迁移。

JuiceFS 在运行过程中, 可能会因为硬件软件差异, 系统配置不同, 文件大小等原因导致实际的性能表现会有所不同。之前分享过[如何利用 JuiceFS 的性能工具做分析和调优]本文我们将更进一步介绍如何对 JuiceFS 进行准确的性能评估，希望能帮到大家。

前言

在进行性能测试之前，最好写下该使用场景的大致描述，包括：

对接的应用是什么？比如 Apache Spark、PyTorch 或者是自己写的程序等
应用运行的资源配置，包括 CPU、内存、网络，以及节点规模
预计的数据规模，包括文件数量和容量
文件的大小和访问模式（大文件或者小文件，顺序读写或者随机读写）
对性能的要求，比如每秒要写入或者读取的数据量、访问的 QPS 或者操作的延迟等

以上这些内容越清晰、越详细，就越容易制定合适的测试计划，以及需要关注的性能指标，来判断应用对存储系统各方面的需求，包括 JuiceFS 元数据配置、网络带宽要求、配置参数等。当然，在一开始就清晰地写出上面所有的内容并不容易，有些内容可以在测试过程中逐渐明确，但是在一次完整的测试结束时，以上使用场景描述以及相对应的测试方法、测试数据、测试结果都应该是完整的。

如果上面的内容还不明确，不要紧，JuiceFS 内置的测试工具可以一行命令得到单机基准性能的核心指标。同时本文还会介绍两个 JuiceFS 内置的性能分析工具，在做更复杂的测试时，这两个工具能帮你简单清晰的分析出 JuiceFS 性能表现背后的原因。

性能测试快速上手

以下示例介绍 JuiceFS 内置的 bench 工具的基本用法。

环境配置

测试主机：Amazon EC2 c5.xlarge 一台
操作系统：Ubuntu 20.04.1 LTS (Kernel 5.4.0-1029-aws)
元数据引擎：Redis 6.2.3, 存储（dir）配置在系统盘
对象存储：Amazon S3
JuiceFS version：0.17-dev (2021-09-23 2ec2badf)

JuiceFS Bench

JuiceFS bench 命令可以帮助你快速完成单机性能测试，通过测试结果判断环境配置和性能表现是否正常。假设你已经把 JuiceFS 挂载到了测试机器的 /mnt/jfs 位置（如果在 JuiceFS 初始化、挂载方面需要帮助，请参考快速上手指南，执行以下命令即可（推荐 -p 参数设置为测试机器的 CPU 核数）：

$ juicefs bench /mnt/jfs -p 4

测试结果会将各项性能指标显示为绿色，黄色或红色。若您的结果中有红色指标，请先检查相关配置，需要帮助可以在 GitHub Discussions 详细描述你的问题。

JuiceFS bench 基准性能测试的具体流程如下（它的实现逻辑非常简单，有兴趣了解细节的可以直接看源码：

N 并发各写 1 个 1 GiB 的大文件，IO 大小为 1 MiB
N 并发各读 1 个之前写的 1 GiB 的大文件，IO 大小为 1 MiB
N 并发各写 100 个 128 KiB 的小文件，IO 大小为 128 KiB
N 并发各读 100 个之前写的 128 KiB 的小文件，IO 大小为 128 KiB
N 并发各 stat 100 个之前写的 128 KiB 的小文件
清理测试用的临时目录

并发数 N 的值即由 bench 命令中的 -p 参数指定。

在这用 AWS 提供的几种常用存储类型做个性能比较：

EFS 1TiB 容量时，读 150MiB/s，写 50MiB/s，价格是 $0.08/GB-month
EBS st1 是吞吐优化型 HDD，最大吞吐 500MiB/s，最大 IOPS（1MiB I/O）500，最大容量 16TiB，价格是 $0.045/GB-month
EBS gp2 是通用型 SSD，最大吞吐 250MiB/s，最大 IOPS（16KiB I/O）16000，最大容量 16TiB，价格是 $0.10/GB-month

不难看出，在上面的测试中，JuiceFS 的顺序读写能力明显优于 AWS EFS，吞吐能力也超过了常用的 EBS。但是写小文件的速度不算快，因为每写一个文件都需要将数据持久化到 S3 中，调用对象存储 API 通常有 10~30ms 的固定开销。

注 1：Amazon EFS 的性能与容量线性相关参考（AWS 官方文档），这样就不适合用在小数据量高吞吐的场景中。

注 2：价格参考 AWS 美东区（US East, Ohio Region），不同 Region 的价格有细微差异。

注 3：以上数据来自 AWS 官方文档，性能指标为最大值，EBS 的实际性能与卷容量和挂载 EC2 实例类型相关，总的来说是越大容量，搭配约高配置的 EC2，得到的 EBS 性能越好，但不超过上面提到的最大值。

性能观测和分析工具

接下来介绍两个性能观测和分析工具，是 JuiceFS 测试、使用、调优过程中必备的利器。

JuiceFS Stats

JuiceFS stats 是一个实时统计 JuiceFS 性能指标的工具，类似 Linux 系统的 dstat 命令，可以实时显示 JuiceFS 客户端的指标变化（详细说明和使用方法见性能监控文档）。执行 juicefs bench 时，在另一个会话中执行以下命令：

$ juicefs stats /mnt/jfs --verbosity 1

结果如下，可以将其与上述基准测试流程对照来看，更易理解：

其中各项指标具体含义如下：

usage
- cpu: JuiceFS 进程消耗的 CPU
- mem: JuiceFS 进程占用的物理内存
- buf: JuiceFS 进程内部的读写 buffer 大小，受挂载项 --buffer-size 限制
- cache: 内部指标，可不关注
fuse
- ops/lat: FUSE 接口每秒处理的请求个数及其平均时延（单位为毫秒，下同）
- read/write: FUSE 接口每秒处理读写请求的带宽值
meta
- ops/lat: 元数据引擎每秒处理的请求个数及其平均时延（请注意部分能在缓存中直接处理的请求未列入统计，以更好地体现客户端与元数据引擎交互的耗时）
- txn/lat: 元数据引擎每秒处理的写事务个数及其平均时延（只读请求如 getattr 只会计入 ops 而不会计入 txn）
- retry: 元数据引擎每秒重试写事务的次数
blockcache
- read/write: 客户端本地数据缓存的每秒读写流量
object
- get/get_c/lat: 对象存储每秒处理读请求的带宽值，请求个数及其平均时延
- put/put_c/lat: 对象存储每秒处理写请求的带宽值，请求个数及其平均时延
- del_c/lat: 对象存储每秒处理删除请求的个数和平均时延

JuiceFS Profile

JuiceFS profile 一方面用来实时输出 JuiceFS 客户端的所有访问日志，包含每个请求的信息。同时，它也可以用来回放、统计 JuiceFS 访问日志，方便用户直观了解 JuiceFS 的运行情况（详细的说明和使用方法见性能诊断文档）。执行 juicefs bench 时，在另一个会话中执行以下命令：

$ cat /mnt/jfs/.accesslog > access.log

其中 .accesslog 是一个虚拟文件，它平时不会产生任何数据，只有在读取（如执行 cat）时才会有 JuiceFS 的访问日志输出。结束后使用 <kbd>Ctrl-C</kbd> 结束 cat 命令，并运行：

$ juicefs profile access.log --interval 0

其中 --interval 参数设置访问日志的采样间隔，设为 0 时用于快速重放一个指定的日志文件，生成统计信息，如下图所示：

从之前基准测试流程描述可知，本次测试过程一共创建了 (1 + 100) * 4 = 404 个文件，每个文件都经历了「创建 → 写入 → 关闭 → 打开 → 读取 → 关闭 → 删除」的过程，因此一共有：

404 次 create，open 和 unlink 请求
808 次 flush 请求：每当文件关闭时会自动调用一次 flush
33168 次 write/read 请求：每个大文件写入了 1024 个 1 MiB IO，而在 FUSE 层请求的默认最大值为 128 KiB，也就是说每个应用 IO 会被拆分成 8 个 FUSE 请求，因此一共有 (1024 * 8 + 100) * 4 = 33168 个请求。读 IO 与之类似，计数也相同。

以上这些值均能与 profile 的结果完全对应上。另外，结果中还显示 write 的平均时延非常小（45 微秒），而主要耗时点在 flush。这是因为 JuiceFS 的 write 默认先写入内存缓冲区，在文件关闭时再调用 flush 上传数据到对象存储，与预期吻合。

其他测试工具配置示例

Fio 单机性能测试

Fio 是业界常用的一个性能测试工具，完成 JuiceFS bench 后可以用它来做更复杂的性能测试。

环境配置

与 JuiceFS Bench 测试环境一致。

测试任务

执行下面四个 Fio 任务，分别进行顺序写、顺序读、随机写、随机读测试：

# Sequential
$ fio --name=jfs-test --directory=/mnt/jfs --ioengine=libaio --rw=write --bs=1m --size=1g --numjobs=4 --direct=1 --group_reporting
$ fio --name=jfs-test --directory=/mnt/jfs --ioengine=libaio --rw=read --bs=1m --size=1g --numjobs=4 --direct=1 --group_reporting

# Random
$ fio --name=jfs-test --directory=/mnt/jfs --ioengine=libaio --rw=randwrite --bs=1m --size=1g --numjobs=4 --direct=1 --group_reporting
$ fio --name=jfs-test --directory=/mnt/jfs --ioengine=libaio --rw=randread --bs=1m --size=1g --numjobs=4 --direct=1 --group_reporting

参数说明：

--name：用户指定的测试名称，会影响测试文件名
--directory：测试目录
--ioengine：测试时下发 IO 的方式；通常用 libaio 即可
--rw：常用的有 read，write，randread，randwrite，分别代表顺序读写和随机读写
--bs：每次 IO 的大小
--size：每个线程的 IO 总大小；通常就等于测试文件的大小
--numjobs：测试并发线程数；默认每个线程单独跑一个测试文件
--direct：在打开文件时添加 O_DIRECT 标记位，不使用系统缓冲，可以使测试结果更稳定准确

结果如下：

# Sequential
WRITE: bw=703MiB/s (737MB/s), 703MiB/s-703MiB/s (737MB/s-737MB/s), io=4096MiB (4295MB), run=5825-5825msec
READ: bw=817MiB/s (856MB/s), 817MiB/s-817MiB/s (856MB/s-856MB/s), io=4096MiB (4295MB), run=5015-5015msec

# Random
WRITE: bw=285MiB/s (298MB/s), 285MiB/s-285MiB/s (298MB/s-298MB/s), io=4096MiB (4295MB), run=14395-14395msec
READ: bw=93.6MiB/s (98.1MB/s), 93.6MiB/s-93.6MiB/s (98.1MB/s-98.1MB/s), io=4096MiB (4295MB), run=43773-43773msec

Vdbench 多机性能测试

Vdbench 也是业界常见的文件系统评测工具，且很好地支持了多机并发测试。

测试环境

与 JuiceFS Bench 测试环境类似，只是多开了两台同配置主机，一共三台。

准备工作

需要在每个节点相同路径下安装 vdbench：

官网下载 50406 版本
安装 Java：apt-get install openjdk-8-jre
测试 vdbench 安装成功：./vdbench -t

然后，假设三个节点名称分别为 node0，node1 和 node2，则需在 node0 上创建配置文件，如下（测试大量小文件读写）：

$ cat jfs-test
hd=default,vdbench=/root/vdbench50406,user=root
hd=h0,system=node0
hd=h1,system=node1
hd=h2,system=node2

fsd=fsd1,anchor=/mnt/jfs/vdbench,depth=1,width=100,files=3000,size=128k,shared=yes

fwd=default,fsd=fsd1,operation=read,xfersize=128k,fileio=random,fileselect=random,threads=4
fwd=fwd1,host=h0
fwd=fwd2,host=h1
fwd=fwd3,host=h2

rd=rd1,fwd=fwd*,fwdrate=max,format=yes,elapsed=300,interval=1

参数说明：

vdbench=/root/vdbench50406：指定了 vdbench 工具的安装路径
anchor=/mnt/jfs/vdbench：指定了每个节点上运行测试任务的路径
depth=1,width=100,files=3000,size=128k：定义了测试任务文件树结构，即测试目录下再创建 100 个目录，每个目录内包含 3000 个 128 KiB 大小的文件，一共 30 万个文件
operation=read,xfersize=128k,fileio=random,fileselect=random：定义了实际的测试任务，即随机选择文件下发 128 KiB 大小的读请求

结果如下：

FILE_CREATES        Files created:                              300,000        498/sec
READ_OPENS          Files opened for read activity:             188,317        627/sec

系统整体创建 128 KiB 文件速度为每秒 498 个，读取文件速度为每秒 627 个。

总结

本文从环境配置、工具介绍、实例测试等角度全方位的分享了对 JuiceFS 进行性能评估的整体流程，准确的性能评估可以帮助优化 JuiceFS 更好的适配你的应用场景。最后，欢迎大家积极记录并分享自己的测试过程和结果到 JuiceFS 论坛或用户群。

如有帮助的话欢迎关注我们项目 Juicedata/JuiceFS 哟！ (0ᴗ0✿)

微信关注我们

原文链接：https://my.oschina.net/u/5389802/blog/5348617

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

7张图揭晓RocketMQ存储设计的精髓

RocketMQ作为一款基于磁盘存储的中间件，具有无限积压能力，并提供高吞吐、低延迟的服务能力，其最核心的部分必然是它优雅的存储设计。温馨提示：本文节选自新上市《RocketMQ技术内幕》第二版本，一个最大的改变就是在进入源码分析之前，首先通过图文的方式，提炼出RocketMQ的核心工作机制，降低源码阅读的难度，引发思考。 1、存储概述 RocketMQ存储的文件主要包括Commitlog文件、ConsumeQueue文件、Index文件。 RocketMQ将所有主题的消息存储在同一个文件中，确保消息发送时按顺序写文件，尽最大能力确保消息发送的高可用性与高吞吐量。但消息中间件一般都是基于主题的订阅与发布模式，消息消费时必须按照主题进行筛选消息，显然从Commitlog文件中按照topic去筛选消息会变得及其低效，为了提高根据主题检索消息的效率，RocketMQ引入了ConsumeQueue文件，俗称消费队列文件。关系型数据库可以按照字段属性进行记录检索，作为一款主要面向业务开发的消息中间件，RocketMQ也提供了基于消息属性的检索能力，底层的核心设计理念是为Commitlog文...

2021-12-08

452

前言— 随着前端智能化的火热，AI机器学习进入前端开发者们的视野。AI能够解决编程领域不能直接通过规则和运算解决的问题，通过自动推理产出最佳策略，成为了前端工程师们解决问题的又一大利器。可能很多同学都跃跃欲试过，打开 TensorFlow 或者 Pytorch 官网，然后按照文档想要写一个机器学习的 Hello World ，然后就会遇到一些不知道是什么的函数，跑完例子却一头雾水，这是因为 TensorFlow 和 Pytorch 是使用机器学习的工具，而没有说明什么是机器学习。所以这篇文章以实践为最终目的出发，介绍一些机器学习入门的基本原理，加上一丢丢图像处理的卷积，希望可以帮助你理解。基础概念— 首先，什么是机器学习？机器学习约等于找这样一个函数，比如在语音识别中，输入一段语音，输出文字内容在图像识别中，输入一张图像，输出图中的对象，在围棋中，输入棋盘数据，输出下一步怎么走，在对话系统中，输入一句 hi ，输出一句回应，而这个函数，是由你写的程序加上大量的数据，然后由机器自己学习到的。怎么找这样一个函数呢，让我们从线性模型入手。线性模型形式简单，易于建模，但是蕴含着机...

2021-12-02

500

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。