JuiceFS 效能評估指南

語言: CN / TW / HK

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 的訪問日誌輸出。結束後使用 <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:

  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✿)