JuiceFS 是一款面向云原生環(huán)境設(shè)計(jì)的高性能 POSIX 文件系統(tǒng)，在 AGPL v3.0 開源協(xié)議下發(fā)布。作為一個(gè)云上的分布式文件系統(tǒng)，任何存入 JuiceFS 的數(shù)據(jù)都會(huì)按照一定規(guī)則拆分成數(shù)據(jù)塊存入對(duì)象存儲(chǔ)（如 Amazon S3），相對(duì)應(yīng)的元數(shù)據(jù)則持久化在獨(dú)立的數(shù)據(jù)庫(kù)中。這種結(jié)構(gòu)決定了 JuiceFS 的存儲(chǔ)空間可以根據(jù)數(shù)據(jù)量彈性伸縮，可靠地存儲(chǔ)大規(guī)模的數(shù)據(jù)，同時(shí)支持在多主機(jī)之間共享掛載，實(shí)現(xiàn)跨云跨地區(qū)的數(shù)據(jù)共享和遷移。
從 v0.13 發(fā)布以來， JuiceFS 新增了多項(xiàng)與性能監(jiān)測(cè)和分析相關(guān)的功能，從某種程度上說，開發(fā)團(tuán)隊(duì)希望 JuiceFS 既能提供大規(guī)模分布式計(jì)算場(chǎng)景下的出色性能，也能廣泛地覆蓋更多日常的使用場(chǎng)景。
本文我們從單機(jī)應(yīng)用入手，看依賴單機(jī)文件系統(tǒng)的應(yīng)用是否也可以用在 JuiceFS 之上，并分析它們的訪問特點(diǎn)進(jìn)行針對(duì)性的調(diào)優(yōu)。
測(cè)試環(huán)境
接下來的測(cè)試我們會(huì)在同一臺(tái)亞馬遜云服務(wù)器上進(jìn)行，配置情況如下：
- 服務(wù)器配置：Amazon c5d.xlarge: 4 vCPUs, 8 GiB 內(nèi)存, 10 Gigabit 網(wǎng)絡(luò), 100 GB SSD
- JuiceFS：使用本地自建的 Redis 作為元數(shù)據(jù)引擎，對(duì)象存儲(chǔ)使用與服務(wù)器相同區(qū)域的 S3。
- EXT4：直接在本地 SSD 上創(chuàng)建
- 數(shù)據(jù)樣本：使用 Redis 的源代碼作為測(cè)試樣本
測(cè)試項(xiàng)目一：Git
常用的 git 系列命令有 clone、status、add、diff 等，其中 clone 與編譯操作類似，都涉及到大量小文件寫。這里我們主要測(cè)試 status 命令。
分別將代碼克隆到本地的 EXT4 和 JuiceFS，然后執(zhí)行 git status 命令的耗時(shí)情況如下：
- Ext4：0m0.005s
- JuiceFS：0m0.091s
可見，耗時(shí)出現(xiàn)了數(shù)量級(jí)的差異。如果單從測(cè)試環(huán)境的樣本來說，這樣的性能差異微乎其微，用戶幾乎是察覺不到的。但如果使用規(guī)模更大的代碼倉(cāng)庫(kù)時(shí)，二者的性能差距就會(huì)逐漸顯現(xiàn)。例如，假設(shè)兩者耗時(shí)都乘以 100 倍，本地文件系統(tǒng)需要約 0.5s，尚在可接受范圍內(nèi)；但 JuiceFS 會(huì)需要約 9.1s，用戶已能感覺到明顯的延遲。為搞清楚主要的耗時(shí)點(diǎn)，我們可以使用 JuiceFS 客戶端提供的 profile 工具：
$ juicefs profile /mnt/jfs
在分析過程中，更實(shí)用的方式是先記錄日志，再用回放模式：
$ cat /mnt/jfs/.accesslog > a.log
# 另一個(gè)會(huì)話：git status
# Ctrl-C 結(jié)束 cat
$ juicefs profile --interval 0 a.log
結(jié)果如下：
這里可以清楚地看到有大量的 lookup 請(qǐng)求，我們可以通過調(diào)整 FUSE 的掛載參數(shù)來延長(zhǎng)內(nèi)核中元數(shù)據(jù)的緩存時(shí)間，比如使用以下參數(shù)重新掛載文件系統(tǒng)：
$ juicefs mount -d --entry-cache 300 localhost /mnt/jfs
然后我們?cè)儆?profile 工具分析，結(jié)果如下：
可以看到，lookup 請(qǐng)求減少了很多，但都轉(zhuǎn)變成了 getattr 請(qǐng)求，因此還需要屬性的緩存：
$ juicefs mount -d --entry-cache 300 --attr-cache 300 localhost /mnt/jfs
此時(shí)測(cè)試發(fā)現(xiàn) status 命令耗時(shí)下降到了 0m0.034s，profile 工具結(jié)果如下：
可見一開始最耗時(shí)的 lookup 已經(jīng)減少了很多，而 readdir 請(qǐng)求變成新的瓶頸點(diǎn)。我們還可以嘗試設(shè)置 --dir-entry-cache，但提升可能不太明顯。
測(cè)試項(xiàng)目二：Make
大型項(xiàng)目的編譯時(shí)間往往需要以小時(shí)計(jì)，因此編譯時(shí)的性能顯得更加重要。依然以 Redis 項(xiàng)目為例，測(cè)試編譯的耗時(shí)為：
- Ext4：0m29.348s
- JuiceFS：2m47.335s
我們嘗試調(diào)大元數(shù)據(jù)緩存參數(shù)，整體耗時(shí)下降約 10s。通過 profile 工具分析結(jié)果如下：
顯然這里的數(shù)據(jù)讀寫是性能關(guān)鍵，我們可以使用 stats 工具做進(jìn)一步的分析：
$ juicefs stats /mnt/jfs
其中一段結(jié)果如下：
從上圖可見 fuse 的 ops 與 meta 接近，但平均 latency 遠(yuǎn)大于 meta，因此可以判斷出主要的瓶頸點(diǎn)在對(duì)象存儲(chǔ)側(cè)。不難想象，編譯前期產(chǎn)生了大量的臨時(shí)文件，而這些文件又會(huì)被編譯的后幾個(gè)階段讀取，以通常對(duì)象存儲(chǔ)的性能很難直接滿足要求。好在 JuiceFS 提供了數(shù)據(jù) writeback 模式，可以在本地盤上先建立寫緩存，正好適用于編譯這種場(chǎng)景：
$ juicefs mount -d --entry-cache 300 --attr-cache 300 --writeback localhost /mnt/jfs
此時(shí)編譯總耗時(shí)下降到 0m38.308s，已經(jīng)與本地盤非常接近了。后階段的 stats 工具監(jiān)控結(jié)果如下：
可見，讀請(qǐng)求基本全部在 blockcache 命中，而不再需要去訪問對(duì)象存儲(chǔ)；fuse 和 meta 側(cè)的 ops 統(tǒng)計(jì)也得到了極大提升，與預(yù)期吻合。
總結(jié)
本文以本地文件系統(tǒng)更擅長(zhǎng)的 Git 倉(cāng)庫(kù)管理和 Make 編譯任務(wù)為切入點(diǎn)，評(píng)估這些任務(wù)在 JuiceFS 存儲(chǔ)上的性能表現(xiàn)，并使用 JuiceFS 自帶的 profile 與 stats 工具進(jìn)行分析，通過調(diào)整文件系統(tǒng)掛載參數(shù)做針對(duì)性的優(yōu)化。
毫無疑問，本地文件系統(tǒng)與 JuiceFS 等分布式文件系統(tǒng)存在著天然的特征差異，二者面向的應(yīng)用場(chǎng)景也截然不同。本文選擇了兩種特殊的應(yīng)用場(chǎng)景，只是為了在差異鮮明的情境下介紹如何為 JuiceFS 做性能調(diào)優(yōu)，旨在拋磚引玉，希望大家舉一反三。如果你有相關(guān)的想法或經(jīng)驗(yàn)，歡迎在 JuiceFS 論壇或用戶群分享和討論。
推薦閱讀
知乎 x JuiceFS：利用 JuiceFS 給 Flink 容器啟動(dòng)加速
項(xiàng)目地址： Github （https://github.com/juicedata/juicefs）如有幫助的話歡迎關(guān)注我們喲！ (0?0?)
