JuiceFS 性能評估指南

JuiceFS 是一款面向雲原生環境設計的高性能 POSIX 文件系統，任何存入 JuiceFS 的數據都會按照一定規則拆分成數據塊存入對象存儲（如 Amazon S3），相對應的元數據則持久化在獨立的數據庫中。這種結構決定了 JuiceFS 的存儲空間可以根據數據量彈性伸縮，可靠地存儲大規模的數據，同時支持在多主機之間共享掛載，實現跨雲跨地區的數據共享和遷移。

JuiceFS 在運行過程中, 可能會因為硬件軟件差異, 系統配置不同, 文件大小等原因導致實際的性能表現會有所不同。之前分享過[如何利用 JuiceFS 的性能工具做分析和調優]本文我們將更進一步介紹如何對 JuiceFS 進行准確的性能評估，希望能幫到大家。

前言

在進行性能測試之前，最好寫下該使用場景的大致描述，包括：

1. 對接的應用是什么？比如 Apache Spark、PyTorch 或者是自己寫的程序等
2. 應用運行的資源配置，包括 CPU、內存、網絡，以及節點規模
3. 預計的數據規模，包括文件數量和容量
4. 文件的大小和訪問模式（大文件或者小文件，順序讀寫或者隨機讀寫）
5. 對性能的要求，比如每秒要寫入或者讀取的數據量、訪問的 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 基准性能測試的具體流程如下（它的實現邏輯非常簡單，有興趣了解細節的可以直接看源碼：

1. N 並發各寫 1 個 1 GiB 的大文件，IO 大小為 1 MiB
2. N 並發各讀 1 個之前寫的 1 GiB 的大文件，IO 大小為 1 MiB
3. N 並發各寫 100 個 128 KiB 的小文件，IO 大小為 128 KiB
4. N 並發各讀 100 個之前寫的 128 KiB 的小文件，IO 大小為 128 KiB
5. N 並發各 stat 100 個之前寫的 128 KiB 的小文件
6. 清理測試用的臨時目錄

並發數 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 的訪問日志輸出。結束后使用 Ctrl-C 結束 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：

1. 官網下載 50406 版本
2. 安裝 Java：apt-get install openjdk-8-jre
3. 測試 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 論壇或用戶群。

推薦閱讀：知乎 x JuiceFS：利用 JuiceFS 給 Flink 容器啟動加速

如有幫助的話歡迎關注我們項目 Juicedata/JuiceFS 喲！ (0ᴗ0✿)