如何利用 JuiceFS 的效能工具做檔案系統分析和調優

JuiceFS 發表於 2021-11-25

JuiceFS 是一款面向雲原生環境設計的高效能 POSIX 檔案系統,在 AGPL v3.0 開源協議下發布。作為一個雲上的分散式檔案系統,任何存入 JuiceFS 的資料都會按照一定規則拆分成資料塊存入物件儲存(如 Amazon S3),相對應的後設資料則持久化在獨立的資料庫中。這種結構決定了 JuiceFS 的儲存空間可以根據資料量彈性伸縮,可靠地儲存大規模的資料,同時支援在多主機之間共享掛載,實現跨雲跨地區的資料共享和遷移。

從 v0.13 釋出以來, JuiceFS 新增了多項與效能監測和分析相關的功能,從某種程度上說,開發團隊希望 JuiceFS 既能提供大規模分散式計算場景下的出色效能,也能廣泛地覆蓋更多日常的使用場景。

本文我們從單機應用入手,看依賴單機檔案系統的應用是否也可以用在 JuiceFS 之上,並分析它們的訪問特點進行鍼對性的調優。

測試環境

接下來的測試我們會在同一臺亞馬遜雲伺服器上進行,配置情況如下:

  • 伺服器配置:Amazon c5d.xlarge: 4 vCPUs, 8 GiB 記憶體, 10 Gigabit 網路, 100 GB SSD
  • JuiceFS:使用本地自建的 Redis 作為後設資料引擎,物件儲存使用與伺服器相同區域的 S3。
  • EXT4:直接在本地 SSD 上建立
  • 資料樣本:使用 Redis 的原始碼作為測試樣本

測試專案一:Git

常用的 git 系列命令有 clone、status、add、diff 等,其中 clone 與編譯操作類似,都涉及到大量小檔案寫。這裡我們主要測試 status 命令。

分別將程式碼克隆到本地的 EXT4 和 JuiceFS,然後執行 git status 命令的耗時情況如下:

  • Ext4:0m0.005s
  • JuiceFS:0m0.091s

可見,耗時出現了數量級的差異。如果單從測試環境的樣本來說,這樣的效能差異微乎其微,使用者幾乎是察覺不到的。但如果使用規模更大的程式碼倉庫時,二者的效能差距就會逐漸顯現。例如,假設兩者耗時都乘以 100 倍,本地檔案系統需要約 0.5s,尚在可接受範圍內;但 JuiceFS 會需要約 9.1s,使用者已能感覺到明顯的延遲。為搞清楚主要的耗時點,我們可以使用 JuiceFS 客戶端提供的 profile 工具:

$ juicefs profile /mnt/jfs

在分析過程中,更實用的方式是先記錄日誌,再用回放模式

$ cat /mnt/jfs/.accesslog > a.log
# 另一個會話:git status
# Ctrl-C 結束 cat
$ juicefs profile --interval 0 a.log

結果如下:

如何利用 JuiceFS 的效能工具做檔案系統分析和調優

這裡可以清楚地看到有大量的 lookup 請求,我們可以通過調整 FUSE 的掛載引數來延長核心中後設資料的快取時間,比如使用以下引數重新掛載檔案系統:

$ juicefs mount -d --entry-cache 300 localhost /mnt/jfs

然後我們再用 profile 工具分析,結果如下:

如何利用 JuiceFS 的效能工具做檔案系統分析和調優

可以看到,lookup 請求減少了很多,但都轉變成了 getattr 請求,因此還需要屬性的快取:

$ juicefs mount -d --entry-cache 300 --attr-cache 300 localhost /mnt/jfs

此時測試發現 status 命令耗時下降到了 0m0.034s,profile 工具結果如下:

如何利用 JuiceFS 的效能工具做檔案系統分析和調優

可見一開始最耗時的 lookup 已經減少了很多,而 readdir 請求變成新的瓶頸點。我們還可以嘗試設定 --dir-entry-cache,但提升可能不太明顯。

測試專案二:Make

大型專案的編譯時間往往需要以小時計,因此編譯時的效能顯得更加重要。依然以 Redis 專案為例,測試編譯的耗時為:

  • Ext4:0m29.348s
  • JuiceFS:2m47.335s

我們嘗試調大後設資料快取引數,整體耗時下降約 10s。通過 profile 工具分析結果如下:

如何利用 JuiceFS 的效能工具做檔案系統分析和調優

顯然這裡的資料讀寫是效能關鍵,我們可以使用 stats 工具做進一步的分析:

$ juicefs stats /mnt/jfs

其中一段結果如下:

如何利用 JuiceFS 的效能工具做檔案系統分析和調優

從上圖可見 fuse 的 ops 與 meta 接近,但平均 latency 遠大於 meta,因此可以判斷出主要的瓶頸點在物件儲存側。不難想象,編譯前期產生了大量的臨時檔案,而這些檔案又會被編譯的後幾個階段讀取,以通常物件儲存的效能很難直接滿足要求。好在 JuiceFS 提供了資料 writeback 模式,可以在本地盤上先建立寫快取,正好適用於編譯這種場景:

$ juicefs mount -d --entry-cache 300 --attr-cache 300 --writeback localhost /mnt/jfs

此時編譯總耗時下降到 0m38.308s,已經與本地盤非常接近了。後階段的 stats 工具監控結果如下:

如何利用 JuiceFS 的效能工具做檔案系統分析和調優

可見,讀請求基本全部在 blockcache 命中,而不再需要去訪問物件儲存;fuse 和 meta 側的 ops 統計也得到了極大提升,與預期吻合。

總結

本文以本地檔案系統更擅長的 Git 倉庫管理和 Make 編譯任務為切入點,評估這些任務在 JuiceFS 儲存上的效能表現,並使用 JuiceFS 自帶的 profile 與 stats 工具進行分析,通過調整檔案系統掛載引數做針對性的優化。

毫無疑問,本地檔案系統與 JuiceFS 等分散式檔案系統存在著天然的特徵差異,二者面向的應用場景也截然不同。本文選擇了兩種特殊的應用場景,只是為了在差異鮮明的情境下介紹如何為 JuiceFS 做效能調優,旨在拋磚引玉,希望大家舉一反三。如果你有相關的想法或經驗,歡迎在 JuiceFS 論壇或使用者群分享和討論。

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

專案地址: Github (https://github.com/juicedata/juicefs)如有幫助的話歡迎關注我們喲! (0ᴗ0✿)