JuiceFS 效能評估指南
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 論壇或使用者群。
推薦閱讀:知乎 x JuiceFS:利用 JuiceFS 給 Flink 容器啟動加速
如有幫助的話歡迎關注我們專案 Juicedata/JuiceFS 喲! (0ᴗ0✿)
- JuiceFS 在理想汽車的使用和展望
- 嫌 OSS 查詢太慢?看我們如何將速度提升 10 倍!
- JuiceFS 在理想汽車的使用和展望
- JuiceFS 資料加密原理
- 如何把 MySQL 備份驗證效能提升 10 倍
- 巧用符號連結遷移 HDFS 資料,業務完全無感知!
- JuiceFS 資料加密原理
- JuiceFS 快取策略詳解
- JuiceFS 快取策略詳解
- JuiceFS 效能評估指南
- JuiceFS 效能評估指南
- JuiceFS 資料讀寫流程詳解
- JuiceFS 資料讀寫流程詳解
- 如何在 Kubernetes 叢集中玩轉 Fluid JuiceFS
- 如何在 Kubernetes 叢集中玩轉 Fluid JuiceFS
- 如何利用 JuiceFS 的效能工具做檔案系統分析和調優
- 知乎利用 JuiceFS 給 Flink 容器啟動加速實踐
- JuiceFS 在大搜車資料平臺的實踐
- 環球易購資料平臺如何做到既提速又省錢?
- JuiceFS CSI Driver 的最佳實踐