如何利用 JuiceFS 的性能工具做文件系統分析和調優

語言: CN / TW / HK

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

結果如下:

這裏可以清楚地看到有大量的 lookup 請求,我們可以通過調整 FUSE 的掛載參數來延長內核中元數據的緩存時間,比如使用以下參數重新掛載文件系統:

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

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

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

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

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

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

測試項目二:Make

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

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

我們嘗試調大元數據緩存參數,整體耗時下降約 10s。通過 profile 工具分析結果如下:

顯然這裏的數據讀寫是性能關鍵,我們可以使用 stats 工具做進一步的分析:

$ juicefs stats /mnt/jfs

其中一段結果如下:

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

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

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

可見,讀請求基本全部在 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✿)