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?)
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/373804.html
標籤：其他