JuiceFS 效能評估指南

JuiceFS發表於2021-12-08
UI

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

相關文章