作者 | 車漾（阿里云高級技術專家）、顧榮（南京大學 副研究員）

導讀：Alluxio 項目誕生于 UC Berkeley AMP 實驗室，自開源以來經(jīng)過 7 年的不斷開發(fā)迭代，支撐大數(shù)據(jù)處理場景的數(shù)據(jù)統(tǒng)一管理和高效緩存功能日趨成熟。然而，隨著云原生人工智能（Cloud Native AI）的興起，靈活的計算存儲分離架構大行其道。在此背景下，用戶在云上訓練大規(guī)模深度學習模型引發(fā)的數(shù)據(jù)緩存需求日益旺盛。為此，阿里云容器服務團隊與 Alluxio 開源社區(qū)和南京大學顧榮老師等人通力合作尋找相關解決方案，當前已經(jīng)提供 K8s 上運行模型訓練數(shù)據(jù)加速的基礎方案，包括容器化部署、生命周期管理以及性能優(yōu)化（持續(xù)中），從而降低數(shù)據(jù)訪問高成本和復雜度，進一步助力云上普惠 AI 模型訓練。

AI 訓練新趨勢：基于 Kubernetes 的云上深度學習

1. 背景介紹

近些年，以深度學習為代表的人工智能技術取得了飛速的發(fā)展，正落地應用于各行各業(yè)。隨著深度學習的廣泛應用，眾多領域產(chǎn)生了大量強烈的高效便捷訓練人工智能模型方面的需求。另外，在云計算時代，以 Docker、Kubernetes 以主的容器及其編排技術在應用服務自動化部署的軟件開發(fā)運維浪潮中取得了長足的發(fā)展。Kubernetes 社區(qū)對于 GPU 等加速計算設備資源的支持方興未艾。鑒于云環(huán)境在計算成本和規(guī)模擴展方面的優(yōu)勢，以及容器化在高效部署和敏捷迭代方面的長處，基于“容器化彈性基礎架構+云平臺 GPU 實例”進行分布式深度學習模型訓練成為了業(yè)界生成 AI 模型的主要趨勢。

為了兼顧資源擴展的靈活性，云應用大多采用計算和存儲分離的基本架構。其中，對象存儲因為能夠有效地降低存儲成本、提升擴展彈性，經(jīng)常用來存儲管理海量訓練數(shù)據(jù)。除了采用單一云上存儲之外，很多云平臺的用戶因為安全合規(guī)、數(shù)據(jù)主權或者遺產(chǎn)架構方面的因素，大量數(shù)據(jù)還存儲在私有數(shù)據(jù)中心。這些用戶希望基于混合云的方式構建人工智能訓練平臺，利用云平臺的彈性計算能力滿足高速增長的 AI 業(yè)務模型訓練方面的需求，然而這種“本地存儲+云上訓練”的訓練模式加劇了計算存儲分離架構帶來的遠程數(shù)據(jù)訪問的性能影響。計算存儲分離的基本架構雖然可以為計算資源和存儲資源的配置和擴展帶來更高的靈活性，但是從數(shù)據(jù)訪問效率的角度來看，由于受限于網(wǎng)絡傳輸帶寬，用戶不經(jīng)調(diào)優(yōu)簡單使用這種架構通常會遇到模型訓練性能下降的問題。

2. 常規(guī)方案面臨的數(shù)據(jù)訪問挑戰(zhàn)

目前云上深度學習模型訓練的常規(guī)方案主要采用手動方式進行數(shù)據(jù)準備，具體是將數(shù)據(jù)復制并分發(fā)到云上單機高效存儲（例如，NVMe SSD）或分布式高性能存儲（例如 GlusterFS 并行文件系統(tǒng)）上。這種由用戶手工或者腳本完成的數(shù)據(jù)準備過程通常面臨如下三個問題：

1.數(shù)據(jù)同步管理成本高： 數(shù)據(jù)的不斷更新需要從底層存儲定期進行數(shù)據(jù)同步，這個過程管理成本較高；
2.云存儲成本開銷更多： 需要為云上單機存儲或高性能分布式存儲支付額外費用；
3.大規(guī)模擴展更加復雜： 隨著數(shù)據(jù)量增長，難以將全部數(shù)據(jù)復制到云上單機存儲；即使復制到 GlusterFS 這樣的海量并行文件系統(tǒng)也會花費大量的時間。

基于容器和數(shù)據(jù)編排的模型訓練架構方案

針對云上深度學習訓練常規(guī)方案存在的上述問題，我們設計并實現(xiàn)了一種基于容器和數(shù)據(jù)編排技術的模型訓練架構方案。具體系統(tǒng)架構如圖 1 所示：

系統(tǒng)架構核心組件

• Kubernetes：是一種流行的深度神經(jīng)網(wǎng)絡訓練容器集群管理平臺，它提供了通過容器使用不同機器學習框架的靈活性以及按需擴展的敏捷性。阿里云容器服務 ACK（Alibaba Cloud Kubernetes）是阿里云提供的 Kubernetes 服務，可以在阿里云平臺的 CPU、GPU、NPU(含光 800 芯片)、神龍裸金屬實例上運行 Kubernetes 工作負載；
• Kubeflow：是開源的基于 Kubernetes 云原生 AI 平臺，用于開發(fā)、編排、部署和運行可擴展的便攜式機器學習工作負載。Kubeflow 支持兩種 TensorFlow 框架分布式訓練，分別是參數(shù)服務器模式和 AllReduce 模式。基于阿里云容器服務團隊開發(fā)的?Arena,用戶可以提交這兩種類型的分布式訓練框架；
• Alluxio：是面向混合云環(huán)境的開源數(shù)據(jù)編排與存儲系統(tǒng)。通過在存儲系統(tǒng)和計算框架之間增加一層數(shù)據(jù)抽象層，提供統(tǒng)一的掛載命名空間、層次化緩存和多種數(shù)據(jù)訪問接口，可以支持大規(guī)模數(shù)據(jù)在各種復雜環(huán)境（私有云集群、混合云、公有云）中的數(shù)據(jù)高效訪問。

Alluxio?發(fā)軔于大數(shù)據(jù)時代，流觴自誕生了 Apache Spark 的 UC Berkeley AMP 實驗室。Alluxio 系統(tǒng)設計的初衷是為了解決大數(shù)據(jù)處理流水線中不同計算框架在通過磁盤文件系統(tǒng)（如 HDFS）互換數(shù)據(jù)，造成整個分析性能瓶頸耗時在 I/O 操作方面的問題。Alluxio 項目開源于 2013 年，經(jīng)過 7 年的不斷開發(fā)迭代，在大數(shù)據(jù)處理場景下的應用日趨成熟。另外，近些年隨著深度學習的崛起，Alluxio 分布式緩存技術正逐步成為業(yè)界解決云上 I/O 性能問題的主流解決方案。進一步地，Alluxio 推出基于 FUSE 的 POSIX 文件系統(tǒng)接口，為云上 AI 模型訓練提供了高效的數(shù)據(jù)訪問手段。

為了能夠更好的將 Alluxio 融入 Kubernetes 生態(tài)系統(tǒng)發(fā)揮兩者結合的優(yōu)勢，Alluxio 團隊和阿里云容器服務團隊協(xié)作開發(fā)提供了 Alluxio 的?Helm Chart 方案, ?極大地簡化了在 Kubernetes 內(nèi)的部署和使用。

云上訓練——Alluxio 分布式緩存初探

1. 深度學習實驗環(huán)境

• 我們使用 ResNet-50 模型與 ImageNet 數(shù)據(jù)集，數(shù)據(jù)集大小 144GB，數(shù)據(jù)以 TFRecord 格式存儲，每個 TFRecord 大小約 130MB。每個 GPU 的 batch_size 設置為 256；
• 模型訓練硬件選擇的是 4 臺?V100（高配 GPU 機型），一共 32 塊 GPU 卡；
• 數(shù)據(jù)存儲在阿里云對象存儲服務中，模型訓練程序通過 Alluxio 讀取數(shù)據(jù)，并在讀取過程中將數(shù)據(jù)自動緩存到 Alluxio 系統(tǒng)。Alluxio 緩存層級配置為內(nèi)存，每臺機器提供 40GB 內(nèi)存作為內(nèi)存存儲，總的分布式緩存量為 160GB，沒有使用預先加載策略。

2. 初遇性能瓶頸

在性能評估中，我們發(fā)現(xiàn)當 GPU 硬件從 NVidia P100 升級到 NVidia V100 之后，單卡的計算訓練速度得到了不止 3 倍的提升。計算性能的極大提升給數(shù)據(jù)存儲訪問的性能帶來了壓力。這也給 Alluxio 的 I/O 提出了新的挑戰(zhàn)。

下圖是在分別在合成數(shù)據(jù)（Synthetic Data）和使用 Alluxio 緩存的性能對比，橫軸表示 GPU 的數(shù)量，縱軸表示每秒鐘處理的圖片數(shù)。合成數(shù)據(jù)指訓練程序讀取的數(shù)據(jù)有程序自身產(chǎn)生，沒有 I/O 開銷，代表模型訓練性能的理論上限; 使用 Alluxio 緩存指訓練程序讀取的數(shù)據(jù)來自于 Alluxio 系統(tǒng)。

在 GPU 數(shù)量為 1 和 2 時，使用 Alluxio 和合成數(shù)據(jù)對比，性能差距在可以接受的范圍。但是當 GPU 的數(shù)量增大到 4 時，二者差距就比較明顯了，Alluxio 的處理速度已經(jīng)從 4981 images/second 降到了 3762 images/second。 而當 GPU 的數(shù)量達到 8 的時候，Alluxio 上進行模型訓練的性能不足合成數(shù)據(jù)的 30%。而此時通過系統(tǒng)監(jiān)控，我們觀察到整個系統(tǒng)的計算、內(nèi)存和網(wǎng)絡都遠遠沒有達到瓶頸。這間接說明了簡單使用 Alluxio 難以高效支持 V100 單機 8 卡的訓練場景。

為了能夠深入了解是什么因素影響了性能并進行調(diào)優(yōu)，需要首先研究分析 Alluxio 在 Kubernetes 下支持 FUSE 的整個技術棧。如下圖所示：

3. 原因剖析

通過深度分析整個技術棧和Alluxio內(nèi)核，我們將造成相關性能影響的原因總結如下：

1.Alluxio 文件操作引入多次 RPC 交互，在訓練場景下引入性能開銷。

Alluxio 不只是一個單純的緩存服務。它首先是一個分布式虛擬文件系統(tǒng)，包含完整的元數(shù)據(jù)管理、塊數(shù)據(jù)管理、UFS 管理（UFS 是底層文件系統(tǒng)的簡稱）以及健康檢查機制，尤其是它的元數(shù)據(jù)管理實現(xiàn)比很多底層文件系統(tǒng)更加強大。這些功能是 Alluxio 的優(yōu)點和特色，但也意味著使用分布式系統(tǒng)帶來的開銷。例如，在默認設置下使用 Alluxio 客戶端來讀一個文件，即便數(shù)據(jù)已經(jīng)緩存在本地的 Alluxio Worker 中，客戶端也會和 Master 節(jié)點有多次 RPC 交互來獲取文件元信息以保證數(shù)據(jù)的一致性。完成整個讀操作的鏈路額外開銷在傳統(tǒng)大數(shù)據(jù)場景下并不明顯，但是深度面對學習場景下高吞吐和低延時的需求就顯得捉襟見肘了。

2.Alluxio 的數(shù)據(jù)緩存和驅逐策略會頻繁觸發(fā)節(jié)點數(shù)據(jù)緩存震蕩。

深度學習場景數(shù)據(jù)冷熱經(jīng)常不明顯，因此每個 Alluxio Worker 都會完整讀取數(shù)據(jù)。而 Alluxio 默認模式會優(yōu)先數(shù)據(jù)本地讀取，即使數(shù)據(jù)已經(jīng)保存在 Alluxio 集群中，也會從其他緩存節(jié)點拉取到本地存一份副本。這個特性在我們的場景下會帶來兩個額外開銷：

• 異步數(shù)據(jù)緩存的額外開銷；
• 本地空間不足會觸發(fā)自動數(shù)據(jù)驅逐的開銷，特別當節(jié)點緩存數(shù)據(jù)接近飽和的情況下性能開銷巨大。

3.基于 FUSE 進行文件系統(tǒng)的開發(fā)、部署、使用都很簡單，但是默認性能并不理想，原因如下：

• FUSE 讀操作效率不高，每次 read 最多只能讀 128KB，讀一個 128MB 的文件需要 1000 次調(diào)用 read；
• FUSE 讀操作屬于非阻塞行為，由 libfuse 非阻塞線程池處理，一旦并發(fā)請求數(shù)量遠超過線程池 (max_idle_threads) 的大小，就會觸發(fā)頻繁的大量線程創(chuàng)建和刪除，從而影響讀性能。而在 FUSE 中，這個默認配置是 10；
• 元數(shù)據(jù)的頻繁訪問，因為 FUSE 內(nèi)核模塊是個橋梁角色，連接了應用程序和 Alluxio 的文件系統(tǒng)，而每一次讀獲取文件/目錄的 inode 以及 dentry，FUSE 內(nèi)核模塊都會到 Alluxio 系統(tǒng)運行一趟，增加了系統(tǒng)壓力。

4.Alluxio 和 FUSE 的集成（下文簡稱為 AlluxioFUSE）在深度學習中常見的多線程高并發(fā)場景下性能有待優(yōu)化，甚至需要深度定制：

• Alluxio 目前僅支持在 FUSE 中使用?direct_io?模式，而不能使用?kernel_cache?模式來借助 page cache 進一步提高 I/O 效率。這是因為 Alluxio 當前設計要求在多線程場景下，每個線程都必須使用自己的文件輸入句柄(FileInputStream)。而如果打開 page cache，當前的 AlluxioFUSE 會有些并發(fā)預先讀到 cache 的操作，從而產(chǎn)生報錯；
• 數(shù)據(jù)從被 Alluxio 客戶端讀入后，到進入 FUSE 要經(jīng)歷多次拷貝。這些額外的拷貝通常是由于 AlluxioFUSE 使用到的第三方 Java 庫 API 限制；
• AlluxioFUSE 實現(xiàn)中使用到的第三方庫 JNRFuse 只能適配較低版本的 FUSE，并且在高并發(fā)場景下有較大的性能負擔。

5.Kubernetes 對于 Alluxio 的線程池影響。

Alluxio 基于 Java 1.8 版本實現(xiàn)，其中的一些線程池的計算會依賴于?Runtime.getRuntime().availableProcessors()，但是在 Kubernetes 環(huán)境下，默認配置中 cpu_shares 的值為 2，而 JVM 對于 cpu 的核心數(shù)的計算公式?cpu_shares()/1024，導致結果是 1。這會影響 java 進程在容器內(nèi)的并發(fā)能力。

云上模型訓練的性能優(yōu)化

在分析了上述性能問題和因素之后，我們將設計了一系列性能優(yōu)化策略以提升云上模型訓練的性能。首先，需要明白數(shù)據(jù)訪問的“多快好省”是無法全部兼顧，我們針對的主要是模型訓練下只讀數(shù)據(jù)集的數(shù)據(jù)訪問加速。優(yōu)化的基本思路是關注高性能和數(shù)據(jù)一致性，而犧牲一部分靈活的自適應性（比如讀寫同時發(fā)生，數(shù)據(jù)內(nèi)容不斷更新等場景）。

基于上述思路，我們設計了具體的性能優(yōu)化策略，這些策略遵循以下核心原則：

• 尋找資源限制，包括線程池以及 JVM 在容器中的配置；
• 借助各級緩存，包括 FUSE 層和 Alluxio 元數(shù)據(jù)緩存；
• 避免額外開銷，減少非必須的調(diào)用鏈路。比如避免不必要的元數(shù)據(jù)交互，引入上下文切換的 GC 線程和 compiler 進程；以及 Alluxio 內(nèi)部的一些可以簡化的操作。

下面將從各層的組件優(yōu)化角度，對這些優(yōu)化策略逐一介紹：

1. 對 FUSE 的優(yōu)化

升級 Linux Kernel 版本

FUSE 實現(xiàn)分為兩層：運行在用戶態(tài)的 libfuse 和運行在內(nèi)核態(tài)的 FUSE Kernel。高版本的 Linux Kernel 針對 FUSE 做了大量的優(yōu)化。我們對比了 Kernel 3.10 和 4.19 的性能，發(fā)現(xiàn)讀性能可以達到 20% 的提升。

優(yōu)化 FUSE 參數(shù)

1.延長 FUSE 元數(shù)據(jù)有效時間

Linux 中每個打開文件在內(nèi)核中擁有兩種元數(shù)據(jù)信息：struct dentry?和?struct inode，它們是文件在內(nèi)核的基礎。所有對文件的操作，都需要先獲取文件這兩個結構。所以，每次獲取文件/目錄的 inode 以及 dentry 時，FUSE 內(nèi)核模塊都會從 libfuse 以及 Alluxio 文件系統(tǒng)進行完整操作，這樣會帶來數(shù)據(jù)訪問的高延時和高并發(fā)下對于 Alluxio Master 的巨大壓力。可以通過配置?–o entry_timeout=T –o attr_timeout=T?進行優(yōu)化。

2.配置?max_idle_threads?避免頻繁線程創(chuàng)建銷毀引入 CPU 開銷。

這是由于 FUSE 在多線程模式下，以一個線程開始運行。當有兩個以上的可用請求，則 FUSE 會自動生成其他線程。每個線程一次處理一個請求。處理完請求后，每個線程檢查目前是否有超過?max_idle_threads?(默認 10) 個線程；如果有，則該線程回收。而這個配置實際上要和用戶進程生成的 I/O 活躍數(shù)相關，可以配置成用戶讀線程的數(shù)量。而不幸的是?max_idle_threads?本身只在 libfuse3 才支持，而 AlluxioFUSE 只支持 libfuse2， 因此我們修改了 libfuse2 的代碼支持了?max_idle_threads?的配置。

2. 對 Alluxio 的優(yōu)化

Alluxio 和 FUSE 的集成通過一個名為?AlluxioFuse?的進程實現(xiàn)。該進程在運行期會通過調(diào)用內(nèi)嵌的 Alluxio 客戶端和運行的 Alluxio Master 以及 Worker 交互。我們針對深度學習的場景，定制?AlluxioFuse?所使用的 Alluxio 屬性來優(yōu)化性能。

避免頻繁逐出（Cache Eviction）造成緩存抖動

由于深度學習訓練場景下，每次訓練迭代都是全量數(shù)據(jù)集的迭代，緩存幾個 TB 的數(shù)據(jù)集對于任何一個節(jié)點的存儲空間來說都是捉襟見肘。而 Alluxio 的默認緩存策略是為大數(shù)據(jù)處理場景（例如查詢）下的冷熱數(shù)據(jù)分明的需求設計的，數(shù)據(jù)緩存會保存在 Alluxio 客戶端所在的本地節(jié)點，用來保證下次讀取的性能最優(yōu)。具體來說：

1.alluxio.user.ufs.block.read.location.policy?默認值為?alluxio.client.block.policy.LocalFirstPolicy， 這表示 Alluxio 會不斷將數(shù)據(jù)保存到 Alluxio 客戶端所在的本地節(jié)點，就會引發(fā)其緩存數(shù)據(jù)接近飽和時，該節(jié)點的緩存一直處于抖動狀態(tài)，引發(fā)吞吐和延時極大的下降，同時對于 Master 節(jié)點的壓力也非常大。因此需要?location.policy?設置為?alluxio.client.block.policy.LocalFirstAvoidEvictionPolicy??的同時，指定?alluxio.user.block.avoid.eviction.policy.reserved.size.bytes?參數(shù)，這個參數(shù)決定了當本地節(jié)點的緩存數(shù)據(jù)量達到一定的程度后，預留一些數(shù)據(jù)量來保證本地緩存不會被驅逐。通常這個參數(shù)應該要大于?節(jié)點緩存上限 X （100% - 節(jié)點驅逐上限的百分比）?。

2.alluxio.user.file.passive.cache.enabled?設置是否在 Alluxi 的本地節(jié)點中緩存額外的數(shù)據(jù)副本。這個屬性是默認開啟的。因此，在 Alluxio 客戶端請求數(shù)據(jù)時，它所在的節(jié)點會緩存已經(jīng)在其他 Worker 節(jié)點上存在的數(shù)據(jù)。可以將該屬性設為 false，避免不必要的本地緩存。

3.alluxio.user.file.readtype.default?默認值為?CACHE_PROMOTE。這個配置會有兩個潛在問題，首先是可能引發(fā)數(shù)據(jù)在同一個節(jié)點不同緩存層次之間的不斷移動，其次是對數(shù)據(jù)塊的大多數(shù)操作都需要加鎖，而 Alluxio 源代碼中加鎖操作的實現(xiàn)不少地方還比較重量級，大量的加鎖和解鎖操作在并發(fā)較高時會帶來不小的開銷，即便數(shù)據(jù)沒有遷移還是會引入額外開銷。因此可以將其設置為 CACHE 以避免 moveBlock 操作帶來的加鎖開銷，替換默認的?CACHE_PROMOTE。

緩存元數(shù)據(jù)和節(jié)點列表

在深度學習訓練場景下，每次訓練任務開始前會列出所有訓練數(shù)據(jù)文件并讀取其元數(shù)據(jù)，然后運行訓練任務的進程會進一步讀取訓練數(shù)據(jù)文件。通過 Alluxio 讀取文件訪問時默認會完成如下操作：首先從 Master 獲取文件元數(shù)據(jù)，從中獲取 block 元數(shù)據(jù)，再從 Worker 獲取 block 的具體位置，最后真正從獲取的位置讀取 block 數(shù)據(jù)。完成完整的操作鏈路包括多次 RPC 開銷，引入明顯的文件訪問延時。如果能將該數(shù)據(jù)文件的 block 信息緩存到客戶端內(nèi)存中，會非常明顯的提升文件的訪問性能。

1.將?alluxio.user.metadata.cache.enabled?設置為?true, 可以在 Alluxio 客戶端開啟文件以及目錄的元數(shù)據(jù)緩存，避免二次訪問時仍需要通過 RPC 訪問元數(shù)據(jù)的問題。結合分配給 AlluxioFUSE 的堆大小，用戶可以配置?alluxio.user.metadata.cache.max.size?來設置最多緩存文件和目錄的元數(shù)據(jù)數(shù)量，也可以配置?alluxio.user.metadata.cache.expiration.time?調(diào)整元數(shù)據(jù)緩存的有效時間。同時在每次選擇讀取數(shù)據(jù)的 Worker 節(jié)點時，Alluxio Master 節(jié)點也會不斷去查詢所有 Worker 節(jié)點的狀態(tài)，這也會在高并發(fā)場景下引入額外開銷。

2.將?alluxio.user.worker.list.refresh.interval?設置為 2min 或者更長。

3.讀取文件也會不斷更新 last accesstime，實際上在高并發(fā)的場景下，這會對 Alluxio Master 造成很大壓力。我們通過修改 Alluxio 代碼增加了開關，可以關閉掉 last accesstime 的更新。

充分利用數(shù)據(jù)本地性

1.數(shù)據(jù)本地性就是盡量將計算移到數(shù)據(jù)所在的節(jié)點上進行，避免數(shù)據(jù)在網(wǎng)絡上的傳輸。分布式并行計算環(huán)境下，數(shù)據(jù)的本地性非常重要。在容器環(huán)境下支持兩種短路讀寫方式：Unix socket?方式和直接文件訪問方式。

• Unix Socket 的方式好處在于隔離性好，不需要 Alluxio Client 和 Alluxio Worker 容器運行在同樣的 Network，UTS，Mount 的 Namespace。但是它的性能比直接文件訪問要差一些，同時會引發(fā) netty 的 OutOfDirectMemoryError
• 而直接訪問文件的方式則所以需要確保同一臺機器上運行的 Alluxio Worker 和 AlluxioFUSE 的主機名和 IP 地址一致，同時要保證 Alluxio Client 和 Worker 共享同樣緩存目錄，這種方式性能更好同時更加穩(wěn)定。但是它實際上犧牲了隔離性，需要二者共享 Network，UTS，Mount 的 Namespace

我們目前選擇的方案是優(yōu)先采用后者。

3. 對 Java & Kubernetes 的優(yōu)化

配置?ActiveProcessorCount

1.Runtime.getRuntime().availableProcessors()?控制的；而如果通過 Kubernetes 部署容器而不指定 cpu 資源的 request 數(shù)量，容器內(nèi) Java 進程讀到 proc 文件系統(tǒng)下的 cpushare 數(shù)量為 2， 而此時的?availableProcessors()?來自于?cpu_shares()/1024，會被算成 1。實際上限制了容器內(nèi) Alluxio 的并發(fā)線程數(shù)。考慮到 Alluxio Client 屬于 I/O 密集型的應用，因此可以通過?-XX:ActiveProcessorCount?設置處理器數(shù)目。這里的基本原則是?ActiveProcessorCount?盡量設置得高些。

調(diào)整 GC，JIT 線程

2.JVM 的缺省 GC，JIT 編譯線程數(shù)量取決于?-XX:ActiveProcessorCount?的數(shù)量，但實際上也可以通過?-XX:ParallelGCThreads -XX:ConcGCThreads -XX:CICompilerCount?等參數(shù)配置，可以將其設置的小些，避免這些進程頻繁的搶占切換，導致性能下降。

4. 性能優(yōu)化效果

在優(yōu)化 Alluxio 之后，ResNet50 的訓練性能單機八卡性能提升了 236.1%，并且擴展性問題得到了解決，訓練速度在不但可以擴展到了四機八卡，而且在此場景下和合成數(shù)據(jù)相比性能損失為 3.29%(31068.8 images/s vs 30044.8 images/s)。相比于把數(shù)據(jù)保存到 SSD 云盤，在四機八卡的場景下，Alluxio 的性能提升了 70.1% (云 SSD 17667.2 images/s vs 30044.8 images/s)。

而實際訓練時間方面，使用 Alluxio 需要 65 分鐘（合成數(shù)據(jù)場景耗時 63 分鐘），和通過云上 SSD 進行模型訓練相比節(jié)省了 45 分鐘，節(jié)省成本 40.9%。

5. 總結與進一步工作

在本文中，我們總結了 Alluxio 在高性能分布式深度學習模型訓練場景中落地的挑戰(zhàn)點，以及我們在優(yōu)化 Alluxio 的實踐。進一步地，我們介紹了如何從多個層面提升 AlluxioFUSE 在高并發(fā)讀場景下性能優(yōu)化的經(jīng)驗。最后，我們實現(xiàn)的基于 Alluxio 優(yōu)化的分布式模型訓練方案，并在 4 機 8 卡的 ResNet50 場景下進行了性能驗證，取得了很好的效果。

在進一步工作方面，對于高吞吐海量規(guī)模的小文件和高并發(fā)讀場景，Alluxio 還有一些在 page cache 的支持和 FUSE 層的穩(wěn)定性方面的工作，我們阿里云容器服務團隊也會和 Alluxio 開源社區(qū)以及南京大學戴海鵬、顧榮等老師一起繼續(xù)合作努力改進。我們相信通過工業(yè)界、開源社區(qū)和學術界和聯(lián)合的創(chuàng)新力量，能夠逐步降低計算存儲分離場景下深度學習訓練的數(shù)據(jù)訪問高成本和復雜度，進一步助力云上普惠 AI 模型訓練。

6. 致謝

感謝 Alluxio 團隊的范斌，邱璐，Calvin Jia，常鋮在整個方案的設計和優(yōu)化過程中的巨大幫助，從 Alluxio 自身能力上對于元數(shù)據(jù)緩存系統(tǒng)做了顯著的提升，為 Alluxio 落地 AI 場景開啟了可能性。

作者簡介

車漾? 阿里云高級技術專家，從事 Kubernetes 和容器相關產(chǎn)品的開發(fā)。尤其關注利用云原生技術構建機器學習平臺系統(tǒng)，是?GPU 共享調(diào)度的主要作者和維護者；

顧榮? 南京大學副研究員，Alluxio 項目核心開發(fā)者，研究方向大數(shù)據(jù)處理，2016 年獲南京大學博士學位，曾在微軟亞洲研究院、英特爾、百度從事大數(shù)據(jù)系統(tǒng)實習研發(fā)。

課程推薦

為了更多開發(fā)者能夠享受到 Serverless 帶來的紅利，這一次，我們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發(fā)者入門的 Serverless 公開課，讓你即學即用，輕松擁抱云計算的新范式——Serverless。

點擊即可免費觀看課程：https://developer.aliyun.com/learning/roadmap/serverless

“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的公眾號。”

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉載。

總結

以上是生活随笔為你收集整理的【深度学习】基于 Alluxio 数据缓存的性能优化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。