大模型訓練的算力規(guī)模持續(xù)擴張，GPU 算力不斷提升的同時，數(shù)據(jù)訪問瓶頸對系統(tǒng)整體性能的影響愈發(fā)突出。本地存儲性能優(yōu)異但擴展性有限，對象存儲在成本與擴展性上具備優(yōu)勢，卻在海量小文件、高并發(fā)場景下面臨吞吐不足的問題，團隊往往需要在二者之間艱難取舍。

為此，分布式文件系統(tǒng)成為平衡高性能與可擴展性的關鍵方案。JuiceFS 已在多行業(yè) AI 場景中廣泛落地，其分布式架構能夠在大規(guī)模數(shù)據(jù)訪問場景下，同時兼顧高性能、強擴展與低成本。本文將從性能角度介紹 JuiceFS 的架構設計，分析不同訪問模式下的核心性能瓶頸與優(yōu)化方法。文中關鍵知識點均附對應詳情鏈接，為用戶理解 JuiceFS 性能機理、掌握常見調優(yōu)方向提供參考。

01 從架構看 JuiceFS 的性能基礎

JuiceFS 分為社區(qū)版與企業(yè)版，二者整體架構一致，均采用元數(shù)據(jù)與數(shù)據(jù)分離的存儲架構。客戶端采用富客戶端設計，承載包括部分元數(shù)據(jù)處理在內的多項核心邏輯，并同時提供元數(shù)據(jù)緩存與數(shù)據(jù)緩存能力，各模塊協(xié)同工作以實現(xiàn)數(shù)據(jù)的高效定位與訪問。底層數(shù)據(jù)存儲基于對象存儲構建，并可借助本地緩存進一步提升訪問性能。對外接口上，JuiceFS 支持多種接入方式，其中 FUSE 最為常用，同時也兼容各類 SDK 與 S3 網(wǎng)關。

社區(qū)版定位為通用文件系統(tǒng)，用戶可根據(jù)需求選擇不同的元數(shù)據(jù)引擎。小規(guī)模部署可選擇 Redis，實現(xiàn)輕量、高響應的數(shù)據(jù)管理；大規(guī)模文件場景可選擇 TiKV，以獲得良好的橫向擴展能力。（參考：JuiceFS 元數(shù)據(jù)引擎選型指南）

企業(yè)版面向復雜高性能場景，相較于社區(qū)版，最大的差異有兩方面：企業(yè)版采用自研多分區(qū)元數(shù)據(jù)引擎，基于 Raft 構建純內存集群，延遲低且橫向擴展能力強，可支持 5,000 億文件規(guī)模。相比社區(qū)版需多次 KV 請求完成的操作，企業(yè)版通常僅需一次或兩次，并可在元數(shù)據(jù)集群內部處理復雜邏輯。其次，企業(yè)版支持分布式緩存共享：同組客戶端可在同一區(qū)域內互訪本地緩存，基于一致性哈希實現(xiàn)，提高緩存命中率和訪問效率。在多節(jié)點高并發(fā)場景下，緩存空間可橫向擴展，任務執(zhí)行前可預熱大部分所需數(shù)據(jù)，從而加速 AI 訓練與推理，提高系統(tǒng)性能和穩(wěn)定性。（JuiceFS 企業(yè)版 5.3 特性詳解：單文件系統(tǒng)支持超 5,000 億文件，首次引入 RDMA）

數(shù)據(jù)分塊設計

JuiceFS 將數(shù)據(jù)切塊后存儲于對象存儲，這一設計是其提升性能的關鍵，將影響數(shù)據(jù)讀取效率、緩存命中率及高并發(fā)訪問下的吞吐能力。

JuiceFS 會將文件拆分為多個 chunk。在每個 chunk 內部，系統(tǒng)維護管理結構 slice，用于跟蹤數(shù)據(jù)寫入和更新。當文件發(fā)生寫入時，新數(shù)據(jù)不會覆蓋已有 slice，而是以新的 slice 追加到 chunk 上層。

理想情況下，每個 chunk 最終只應包含一個 slice。每個 slice 由若干 4 MB 的 block 組成，這些 block 是最終存儲到對象存儲的最小單元。默認情況下，緩存系統(tǒng)也以 block 為單位進行管理。

從右上方示意圖可以看出，文件更新采用追加式寫入：紅色部分為已有 slice，新數(shù)據(jù)以新的 slice 疊加。讀取時，系統(tǒng)組合各層 slice 形成當前視圖；碎片過多時，再通過 compaction 合并，以優(yōu)化訪問性能。更多關于數(shù)據(jù)分塊的細節(jié)可參考文檔。

緩存體系

相較于直接訪問對象存儲，JuiceFS 的性能提升在很大程度上得益于其緩存體系。JuiceFS 客戶端配備了高性能的本地緩存模塊，與之相關的配置項如下：

• cache-dir：用于指定緩存目錄；
• cache-size：用于設定用于緩存的空間大??；
• prefetch：這是緩存模塊中的一個參數(shù)，負責預取功能。當某一請求命中某個 block 時，會啟動一個后臺線程，將整個塊完整拉取下來；
• write back 相關配置：用于提高寫 IOPS，將需要上傳至對象存儲的數(shù)據(jù)塊，先寫入本地緩存，再異步上傳至對象存儲。

企業(yè)版還具備一些進階配置，例如通過 cache group 指定一批客戶端，將它們的本地緩存配置為同一個分布式緩存組，實現(xiàn)緩存數(shù)據(jù)的共享。此外，no sharing 是與緩存組相關的配置，啟用 no sharing 后，客戶端僅從指定的緩存組讀取數(shù)據(jù)，但不作為緩存組成員提供數(shù)據(jù)讀取服務。如此一來，便形成了兩級緩存：第一級是本地緩存，第二級是緩存組中其他節(jié)點上的緩存。

另一個提升性能的機制是內存 buffer（讀 buffer），具有以下作用：

• 合并 IO 請求：可內存層面合并多個連續(xù)的 IO 請求。例如，系統(tǒng)發(fā)出三個 IO 請求，經(jīng)內存緩存處理后，實際發(fā)出的可能僅有一個；
• 自適應預讀功能：在大文件順序讀取場景下，自適應預讀功能通過預讀來提升請求并發(fā)度，從而充分利用緩存和對象存儲資源，提高整體 I/O 性能。

企業(yè)版還有一些進階配置：

• max read ahead：用于設定預讀的最大范圍。
• initial read ahead： 用于設置開啟預讀時的預讀窗口大小，默認以 4MB 塊為單位。
• read ahead ratio： 是去年新增的配置，用于控制大文件隨機讀取時的預讀比例，減少讀放大導致的帶寬瓶頸。過于激進的預讀可能對隨機讀取性能產(chǎn)生負面影響，read ahead ratio 可用于緩解該問題。在 AI 場景中，遇到大文件順序或隨機訪問導致的帶寬或 IOPS 瓶頸時，可通過調整這些參數(shù)優(yōu)化整體性能。

02 JuiceFS 基準 I/O 測試與瓶頸分析

在介紹 JuiceFS 在常見 AI 場景下的性能調優(yōu)之前，先通過連續(xù)讀和隨機讀基準測試觀察系統(tǒng)在理想條件下的 I/O 表現(xiàn)，以理解不同訪問模式下的吞吐量與延遲，為后續(xù) AI/ML 場景的讀寫模式提供參考。

連續(xù)讀性能

在 JuiceFS 中，連續(xù)讀的性能通常主要受帶寬因素影響。在冷讀場景下，性能主要受對象存儲帶寬約束；而在分布式緩存場景下，網(wǎng)絡帶寬可能成為瓶頸。例如，一臺配備 40 Gbps 網(wǎng)卡的機器，其實際可用帶寬可能不足 5 Gbps。此外，F(xiàn)USE 層的用戶態(tài)與內核態(tài)轉換開銷也會限制單線程吞吐，經(jīng)測試單線程讀取文件的帶寬約為 3.5 Gbps。要突破此限制，需要采用多線程或多并發(fā)策略以充分利用存儲與網(wǎng)絡資源。

JuiceFS 連續(xù)讀性能測試

在性能測試中，單線程連續(xù)讀帶寬約為 3.5 Gbps，隨著線程數(shù)增加，整體吞吐量可逐漸接近網(wǎng)絡帶寬上限。為了方便評估自身環(huán)境的性能上限，JuiceFS 提供了 bj bench 子命令，可用于測試對象存儲帶寬。

在實際業(yè)務中，緩存往往比直接訪問對象存儲更常見。此時，可通過增大 buffer size 提高后臺預讀請求數(shù)，從而提升并發(fā)度并改善整體吞吐。例如，將 buffer size 調整至 400 MB（對應 100 個 4 MB 塊的后臺預讀請求）后，并發(fā)度顯著提升，整體吞吐量隨之增強。

隨機讀性能

低并發(fā)隨機讀

在低并發(fā)且非異步訪問場景下，每個請求需等待前一個完成后才能發(fā)出，因此延遲對整體性能的影響尤為顯著。I/O 延遲可能來源于多方面，包括元數(shù)據(jù)查詢延遲、對象存儲訪問延遲，以及本地緩存或分布式緩存讀取延遲。在分析隨機讀性能時，需要重點關注這些延遲因素。

在 4 KB 隨機冷讀場景下，若 IOPS 僅為 8，且對象存儲延遲約 125 毫秒，則可計算出系統(tǒng)并發(fā)度約為 1（8 IOPS × 125 ms ≈ 1000 ms）。

這表明當前處于近似單并發(fā)、請求串行阻塞的狀態(tài)。在這種情況下，優(yōu)化重點通常不在于進一步提升并發(fā)，而在于縮短訪問路徑、降低單次請求延遲，例如將數(shù)據(jù)預熱至本地緩存。完成預熱后，隨機讀路徑可由對象存儲切換至本地緩存，IOPS 可提升至約 12,000，接近本地磁盤的 I/O 水平。

高并發(fā)隨機讀

高并發(fā)隨機讀通常發(fā)生在并發(fā)數(shù)較高或采用異步 I/O 的場景下，其性能瓶頸主要體現(xiàn)在 IOPS 限制上。IOPS 包括元數(shù)據(jù) IOPS、對象存儲 IOPS 以及緩存 IOPS。通過 JuiceFS，可以觀察這些指標，從而確定性能瓶頸所在。此外，客戶端機器的資源（如 CPU 和內存）也可能對性能產(chǎn)生影響，但這類瓶頸相對容易監(jiān)測。

在冷讀場景下，以通過 Libaio 發(fā)起的隨機讀為例，對象存儲側的 IOPS 上限接近 7,000/s。若啟用緩存并完成數(shù)據(jù)預熱，訪問路徑將由對象存儲切換至緩存層，IOPS 可進一步提升至 20,000 以上，說明高并發(fā)隨機讀的瓶頸會隨訪問路徑變化而發(fā)生轉移。

有興趣深入了解 JuiceFS 的完整數(shù)據(jù)訪問鏈路，請參考博客：一文詳解 JuiceFS 讀性能——預讀、預取、緩存、FUSE 和對象存儲。

03 常見 AI 場景下的 I/O 特性與性能調優(yōu)

大文件順序讀場景

大文件順序讀取的典型應用場景之一是模型加載，例如通過 Pickle 序列化保存的 PT 文件。在此過程中，性能受到兩方面限制：一方面，Pickle 的反序列化效率決定了數(shù)據(jù)處理速度；另一方面，數(shù)據(jù)讀取通常為單線程，受 FUSE 帶寬上限和 CPU 性能約束。為提升吞吐量，可通過增加并發(fā)度實現(xiàn)多線程或分片加載，從而充分利用 I/O 能力。在大文件順序讀取的場景下，若能夠將數(shù)據(jù)集完全緩存至本地，可獲得最佳性能；若僅需按需讀取數(shù)據(jù)，則實現(xiàn)相對簡單。

關于大文件順序讀場景性能優(yōu)化，可參考如何構建 70GB/s 吞吐的緩存池

海量小文件場景

在計算機視覺和多模態(tài)任務中，訓練數(shù)據(jù)集通常由大量單獨文件組成，例如單張圖片、視頻幀或文本標注文件。這類海量小文件場景對元數(shù)據(jù)服務的壓力較大。

海量小文件場景下，元數(shù)據(jù)性能影響顯著。一方面，每個文件的數(shù)據(jù)量較小；另一方面，存放大量小文件的目錄元數(shù)據(jù)訪問效率較低。對于只讀負載，可通過開啟客戶端元數(shù)據(jù)緩存并延長緩存周期來提升性能。此外，數(shù)據(jù)讀取層的 IOPS 壓力也更大，因為小文件無法充分利用預讀機制，導致請求更加碎片化。常用的優(yōu)化措施包括增加本地緩存容量，對于商業(yè)版本可進一步采用橫向擴展的分布式緩存集群。由于小文件難以受益于預讀機制，其延遲表現(xiàn)也相對較高。

該場景性能優(yōu)化可參考：海量小文件 + 多云協(xié)同：地瓜機器人 JuiceFS 存儲優(yōu)化之路

大文件隨機讀場景

此類場景在 AI 訓練中較為常見，例如按樣本隨機訪問 TFRecord、HDF5 或 LMDB 格式的數(shù)據(jù)集等。以模型加載為例，若數(shù)據(jù)集格式為隨機讀且每次讀取的大小為數(shù)據(jù)集樣本大?。ㄈ?1MB 至 4MB 的圖片或短視頻），則預讀機制可能導致帶寬浪費。此類場景通常可通過多并發(fā)加載來突破 IOPS 瓶頸，可采取以下措施：

• 增加數(shù)據(jù)加載的 reader 線程數(shù)。
• 使用異步 IO 提高并發(fā)度，盡量打滿 IOPS。
• 完善緩存體系，如提前將數(shù)據(jù)映射至緩存以提高底層 IOPS 性能。
• 調整 read ahead ratio 參數(shù)（如設為 0.5），以降低預讀帶來的帶寬浪費。例如，原本 4MB 的順序讀會預讀 4MB 數(shù)據(jù)，調整后僅預讀 2MB 數(shù)據(jù)。

本文從性能角度分析了 JuiceFS 的架構設計、基準 I/O 測試以及在典型 AI 場景下的調優(yōu)方法，為讀者提供關于系統(tǒng)性能的入門參考。JuiceFS 已在大量生產(chǎn)環(huán)境中得到應用，其分布式架構在性能與成本之間提供了可行的平衡方案。

歡迎在評論區(qū)分享或討論實際使用中的經(jīng)驗與策略。