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

JuiceFS發表於2021-11-25
UI

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

相關文章