Amazon EFS 性能 - Amazon Elastic File System

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

Amazon EFS 性能

以下各節提供 Amazon EFS 效能概觀,並說明檔案系統組態如何影響關鍵效能維度。我們也提供一些重要的提示和建議,用來優化檔案系統效能。

效能摘要

檔案系統效能通常是使用延遲、輸送量和每秒輸入/輸出作業 (IOPS) 的維度來衡量。這些維度的 Amazon EFS 效能取決於檔案系統的組態。下列組態會影響 Amazon EFS 檔案系統的效能:

  • 檔案系統類型:區域性或單區域

  • 效能模式:一般用途或最大 I/O

    重要

    最大 I/O 效能模式的每個操作延遲時間高於「一般用途」效能模式的延遲時間。為獲得更快效能,我們建議您始終使用「一般用途」效能模式。如需詳細資訊,請參閱 效能模式

  • 輸送量模式:彈性、佈建或爆量

下表概述使用「一般用途」效能模式之檔案系統的效能規格,以及檔案系統類型和輸送量模式的可能不同組合。

使用一般用途效能模式之檔案系統的效能規格
儲存和輸送量組態 Latency (延遲) 最大值 IOPS 最大輸送量

檔案系統類型

輸送量模式

讀取操作

寫入操作

讀取操作

寫入操作

P er-file-system 讀取 1

P er-file-system 寫 1

每個客戶端讀/寫

區域性

彈性

低至 250 微秒 (µs)

低至 2.7 毫秒(毫秒) 90,000—25 萬 2 50,000

每秒 3—30 吉位元組 () GiBps

1—5 GiBps

每秒 1,500 兆字節 () 3 MiBps

區域性

佈建

低至 250 µs

低至 2.7 毫秒 55,000 25,000

3—10 GiBps

1—3.33 GiBps

500 MiBps

區域性

爆量

低至 250 µs

低至 2.7 毫秒 35,000 7,000

3—5 GiBps

1—3 GiBps

500 MiBps

單區域

彈性、佈建、爆裂

低至 250 µs

低至 1.6 毫秒

35,000 7,000

3 GiBps 4

1 GiBps 4

500 MiBps
注意

註腳:

  1. 最大讀取和寫入輸送量取決於 AWS 區域。超過最大 AWS 區域區域最大輸送量的輸送量需要增加輸送量配額。Amazon EFS 服務團隊會考慮任何額外輸送量的要求。 case-by-case 核准可能取決於您的工作負載類型。若要進一步了解請求提高配額的信息,請參閱 Amazon EFS 配額

  2. 使用彈性輸送量的檔案系統最多可以為不常存取的資料驅動 90,000 次讀取,而IOPS針對經常存取的資料驅動 250,000 次讀取。IOPS適用其他建議以達到最大值。IOPS如需詳細資訊,請參閱最佳化需要高輸送量和 IOPS

  3. 對於使用彈性輸送量的檔案系統,並使用 2.0 版或更新版本的 Amazon 用EFS戶端 (amazon-efs-utils 版本) 或 Amazon EFS CSI 驅動程式 () 裝載,最大的合併讀取和寫入輸送量 MiBps 為 1,500。aws-efs-csi-driver對於所有其他檔案系統,輸送量限制為 500 MiBps。如需 Amazon EFS 用戶端的詳細資訊,請參閱 安裝 Amazon EFS 客戶端

  4. 使用大量批次輸送量的一個區域檔案系統可以驅動與區域檔案系統相同的 per-file-system 讀取和寫入輸送量 (讀取的最大讀取量 GiBps 為 5,寫入 GiBps 為 3)。

儲存類別

Amazon EFS 儲存類別專為最有效的儲存而設計,具體取決於使用案例。

  • EFS標準儲存類別使用固態硬碟 (SSD) 儲存體,為經常存取的檔案提供最低的延遲層級。此儲存類別提供讀取時間低至 250 微秒的第一個位元組延遲,而寫入則為 2.7 毫秒。

  • EFS不常存取 (IA) 和EFS封存儲存體類別會儲存較少存取的資料,這些資料不需要經常存取資料所需的延遲效能。這些儲存類別提供几十毫秒的第一個位元組延遲。

如需EFS儲存類別的詳細資訊,請參閱EFS 儲存體方案

效能模式

Amazon EFS 提供兩種性能模式,一般用途和最大 I/O。

  • 一般用途模式的每個作業延遲最低,而且是檔案系統的預設效能模式。一個區域檔案系統一律使用「一般用途」效能模式。為獲得更快效能,我們建議您始終使用「一般用途」效能模式。

  • 最大 I/O 模式是上一代效能類型,專為高度平行化的工作負載而設計,可用於比「一般用途」模式更高的延遲。單區域檔案系統或使用彈性輸送量的檔案系統不支援最大 I/O 模式。

    重要

    由於最大 I/O 的每個操作延遲較高,我們建議所有檔案系統使用「一般用途」效能模式。

若要協助確保您的工作負載維持在使用「一般目的」效能模式的檔案系統可用的IOPS限制內,您可以監督PercentIOLimit CloudWatch 測量結果。如需詳細資訊,請參閱CloudWatch Amazon 的指標 EFS

應用程式可以IOPS彈性地擴充到與效能模式相關的極限。您不需要個別收費IOPS;它們包含在檔案系統的輸送量帳戶中。每個網路檔案系統 (NFS) 要求會計為 4 KB 的輸送量,或其實際要求和回應大小 (以較大者為準)。

輸送量模式

檔案系統的輸送量模式會決定檔案系統可用的輸送量。Amazon EFS 提供三種輸送量模式:彈性、佈建和爆量分解。讀取輸送量有折扣,可讓您獲得比寫入輸送量更高的讀取輸送量。每個輸送量模式可用的最大輸送量取決於所在 AWS 區域區域。如需關於不同區域中檔案系統輸送量上限的詳細資訊,請參閱 Amazon EFS 配額

您的檔案系統可以實現讀取和寫入輸送量綜合為 100%。例如,如果您的檔案系統使用其讀取輸送量限制的 33%,檔案系統可以同時達到其寫入輸送量限制的 67%。在主控台的檔案系統詳細資訊頁面上,您可以在其輸送量使用率 (%)圖表中監視檔案系統的輸送量使用量。如需詳細資訊,請參閱監視輸送量效能

選擇正確的檔案系統輸送量模式。

根據工作負載的效能需求,為檔案系統選擇正確的輸送量模式。

  • 彈性輸送量 (建議) — 如果您的工作負載和效能需求極高或無法預測,或應用程式以 5% 或更低的 average-to-peak 比率驅動輸送量,請使用預設的彈性輸送量。如需詳細資訊,請參閱彈性輸送量

  • 佈建輸送量 — 如果您知道工作負載的效能需求,或應用程式以 5% 或更高的 average-to-peak 比率驅動輸送量,請使用佈建的輸送量。如需詳細資訊,請參閱佈建輸送量

  • 量批量輸送量 — 當您想要隨檔案系統儲存量調整的輸送量時,請使用突增輸送量。

    如果在使用大量批量輸送量之後,您發現應用程式受到輸送量限制 (例如,它使用的允許輸送量的 80% 以上,或者您已使用所有的突發積分),則應使用彈性或佈建輸送量。如需詳細資訊,請參閱爆量吞吐量

您可以使用 Amazon CloudWatch 透過 average-to-peak 比較指標與MeteredIOBytes指標來確定工作負載的比率。PermittedThroughput如需 Amazon EFS 指標的詳細資訊,請參閱CloudWatch Amazon 的指標 EFS

彈性輸送量

對於使用彈性輸送量的檔案系統,Amazon EFS 會自動擴展或縮減輸送量效能,以符合工作負載活動的需求。對於效能需求難以預測的尖峰或無法預測的工作負載,或是將輸送量平均提高 5% 或以下的應用程式 ( average-to-peak比率),彈性輸送量是最佳輸送量模式。

由於具有彈性輸送量的檔案系統的輸送量效能會自動調整,因此您不需要指定或佈建輸送量容量來滿足您的應用程式需求。您只需為讀取或寫入的中繼資料和資料量付費,而且在使用彈性輸送量時,不會累積或消耗突發積分。

注意

彈性輸送量僅適用於使用一般目的效能模式的檔案系統。

如需各區域彈性輸送量限制的相關資訊,請參閱您可以增加的 Amazon EFS 配額

佈建輸送量

使用佈建輸送量,您可以指定檔案系統可以驅動的輸送量層級,而不受檔案系統的大小或突發積分餘額影響。如果您知道工作負載的效能需求,或者應用程式的輸送量達到 5% 或更高的 average-to-peak 比率,請使用佈建輸送量。

對於使用佈建輸送量的檔案系統,您需要支付為檔案系統啟用的輸送量量。按月收費的輸送量總量根據超出文件檔案標準儲存基礎線輸送量的輸送量配送,且在 AWS 區域區域上限為現行爆量基礎線輸送量。

如果檔案系統的基準輸送量超過佈建輸送量量,它會自動使用檔案系統允許的大量批量輸送量 (最多達到該中現行的\ 大量基準輸送量限制)。 AWS 區域

如需每RegionProvisioned 輸送量限制的相關資訊,請參閱您可以增加的 Amazon EFS 配額

爆量吞吐量

對於需要隨檔案系統儲存容量調整的輸送量的工作負載,建議使用大量輸送量。使用大量輸送量時,基本輸送量與標準儲存類別中檔案系統的大小成比例,速率為 KiBps 每個 GiB 儲存體 50。檔案系統消耗低於其基本輸送量率時,會累積爆量額度,並在輸送量超過基本速率時扣除。

當突發積分可用時,檔案系統最多可以將 MiBps每 TiB 儲存的輸送量提高至 100,最高可達 100 個上 AWS 區域 限,最少為 100 MiBps。如果沒有可用的突發點數,檔案系統最多可以為 MiBps 每 TiB 的儲存磁碟機 50 個,最少 1 MiBps 個。

如需每個區域大量批量輸送量的相關資訊,請參閱。General resource quotas that cannot be changed

了解 Amazon EFS 爆發積分

使用大量批次輸送量時,每個檔案系統都會根據儲存在標準儲存類別中的檔案系統大小決定的基EFS準速率,隨著時間的推移獲得突發積分。基準速率為 MiBps 每 TB [TiB] 儲存空間 50 (相當於 KiBps 每 GiB 的儲存裝置 50)。Amazon EFS 計量的讀取操作速率高達寫入作業的三分之一,允許檔案系統提高每 GiB 讀取輸送量的基準速率最高可達 150 個,或 KiBps 每 GiB 的寫入輸送量提高 50 KiBps 個。

檔案系統可以持續以其基準計量速率來驅動輸送量。每當檔案系統不活躍或驅動輸送量低於其基準計量速率時,就會纍計爆量額度。累積的爆量額度讓檔案系統能夠將輸送量提高到超過其基準傳輸率。

例如,在標準儲存類別中具有 100 GiB 計量資料的檔案系統,其基準輸送量為 5。 MiBps在 24 小時的閒置期間,檔案系統可獲得價值 432,000 MiB 的信用額度 (5 MiB × 86,400 秒 = 432,000 MiB),可用來以 100 的速度爆發 72 分鐘 (432,000 miB ÷ 100 MiBps = 72 分鐘)。 MiBps

大於 1 TiB 的檔案系統,如果在剩下 50% 的時間都處於閒置狀態,就能隨時在最多 50% 的時間中爆量增加。

下表提供爆量動作的範例。

檔案系統大小 爆量輸送量 基準輸送量
標準儲存中 100 GiB 的計量資料
  • 突發為 300 (MiBps) 唯讀狀態,每天最多 72 分鐘,或

  • 突發到 100 MiBps 只寫,每天最多 72 分鐘

  • 連續磁碟機最多 15 個 MiBps 唯讀

  • 連續驅動多達 5 個 MiBps 唯寫

標準儲存中 1 TiB 的計量資料
  • 突發為每天 300 個 MiBps 只讀,持續 12 小時,或

  • 突發到 100 MiBps 只寫,每天 12 小時

  • 磁碟機 150 連續 MiBps 唯讀

  • 連續磁碟機 50 只 MiBps 寫

標準儲存中 10 TiB 的計量資料
  • 突發為 3 GiBps 只讀,每天 12 小時,或

  • 每天突發為 1 次 GiBps 只寫 12 小時

  • 磁碟機 1.5 連續 GiBps 唯讀

  • 連續磁碟機 500 只 MiBps 寫

通常,較大的文件系統
  • 每 TiB 的儲存空間突發為 300 個 MiBps 唯讀狀態,每天 12 小時,或

  • 每 TiB 的儲存空間突增至 100 次 MiBps 唯寫,每天 12 小時

  • 每 TiB 的儲存裝置連續磁碟機 150 個 MiBps 唯讀

  • 每 TiB 的儲存裝置連續磁碟機 50 個 MiBps 唯寫

注意

Amazon MiBps 為所有檔案系統EFS提供 1 的計量輸送量,即使基準速率較低也是如此。

用來決定基準線和成組分解率的檔案系統大小是可透過DescribeFileSystemsAPI作業取得的ValueInStandard計量大小。

檔案系統可獲得額度,小於 1 TiB 的檔案系統,其額度餘額上限為 2.1 TiB,大於 1 TiB 的檔案系統,上限則為每 TiB 儲存容量 2.1 TiB。這個行爲意味著檔案系統可以累積足夠的額度,來連續爆量增加長達 12 小時。

切換輸送量和變更佈建量的限制

您可以切換現有檔案系統的輸送量模式,並變更輸送量縂量。但是,在將輸送量模式切換為佈建輸送量或變更佈建輸送量量之後,下列動作會在 24 小時內限制:

  • 從佈建輸送量模式切換至彈性或大量輸送量模式。

  • 減少佈建輸送量量。

Amazon EFS 性能提示

使用 Amazon 時EFS,請記住以下效能提示。

平均 I/O 大小

Amazon 的分散式特性EFS可實現高度的可用性、耐用性和可擴展性。這種分散式架構讓每個檔案作業只會產生些許的延遲負擔。由於每個作業的低延遲,因此整體輸送量通常會隨著平均 I/O 大小的增加而提高,因為延遲負擔會由大量的資料分攤。

最佳化需要高輸送量和 IOPS

對於需要高輸送量的工作負載IOPS,請使用設定為一般用途效能模式和彈性輸送量的區域檔案系統。

注意

若要IOPS針對經常存取的資料達到最大 250,000 讀取,檔案系統必須使用彈性輸送量。

若要獲得最高效能,您必須依照下列方式設定應用程式或工作負載來充分利用平行處理。

  1. 將工作負載平均分配到所有用戶端和目錄,其目錄數目至少與已使用的用戶端數目相同。

  2. 將單個執行緒不同資料集或文件對齊,最大限度減少爭用。

  3. 將工作負載分配到 10 個以上的用NFS戶端,在單一掛載目標中,每個用戶端至少有 64 個執行緒。

同時連接

您可以同時在多達數千個 Amazon EC2 和其他 AWS 運算執行個體上掛載 Amazon EFS 檔案系統。如果可以跨更多執行個體來平行執行應用程式,您就能跨運算執行個體提高檔案系統上的總輸送量。

請求模型

如果您啟用對檔案系統的非同步寫入,則在非同EFS步寫入 Amazon 之前,Amazon EC2 執行個體會先緩衝擱置的寫入操作。非同步寫入作業的延遲通常較低。執行非同步寫入時,核心會使用額外的記憶體來進行快取。

啟用同步寫入的檔案系統,或使用略過快取的選項 (例如O_DIRECT) 開啟檔案的檔案系統,向 Amazon EFS 發出同步請求。每個操作都經過客戶端和 Amazon 之間的往返EFS。

注意

您選擇的請求模型具有一致性的權衡 (如果您使用多個 Amazon EC2 執行個體) 和速度。使用同步寫入功能可在處理下一個請求之前完成每個寫入要求交易,藉此提高資料一致性。通過緩衝等待的寫入操作來使用非同步寫入可以提高輸送量。

NFS用戶端掛載設定

確定您正在使用建議的掛載選項 (如 掛載EFS檔案系統Linux 的掛載注意事項 中所述)。

在 Amazon EC2 執行個體上掛載檔案系統時,Amazon EFS 支援網路檔案系統版本 4.0 和 4.1 (NFSv4) 協定。NFSv4.1 與 NFSv4 .0 (每秒少於 1,000 個檔案) 相比,parallel 小型檔案讀取作業 (每秒超過 10,000 個檔案) 可提供更好的效能。對於運行 EC2 macOS 大蘇爾的 Amazon macOS 實例,僅支持 NFSv4 .0。

請勿使用下列掛載選項:

  • noacactimeo=0acregmax=0acdirmax=0:這些選項會停用屬性快取,這會對效能造成非常大的影響。

  • lookupcache=poslookupcache=none:這些選項會停用檔案名稱查閱快取,這會對效能造成非常大的影響。

  • fsc— 此選項可啟用本機檔案快取,但不會變更NFS快取一致性,也不會減少延遲。

注意

掛載檔案系統時,請考慮將NFS用戶端的讀取和寫入緩衝區大小增加到 1 MB。

優化小型檔案效能

您可以盡可能減少檔案重新開啟、增加平行處理,以及盡量綁定參考檔案,以改善小型檔案的效能。

  • 減少到伺服器的往返次數。

    如果稍後在工作流程中需要檔案,非必要不關閉檔案。打開文件描述元可以直接訪問快取中的本地副本。檔案開啟、關閉和中繼資料操作通常無法以非同步方式或透過管線進行。

    讀取或寫入小型文件時,額外的兩次往返非常重要。

    每次往返 (文件開啓,文件關閉) 時間與讀取或寫入批量資料的時間相同。更有效的方法是在計算工作開始時,一次性打開輸入或輸出文件,并在整個計算工作期間保持打開狀態。

  • 使用平行處理原則來減少往返時間的影響。

  • 將參考檔案綁定在一個 .zip 檔案中。某些應用程式會使用大量小型參考文件,這些文件大部分為只讀。將這些文件綁定在 .zip 檔案中,以便您可以一次打開關閉多個檔案。

    .zip 格式允許隨機訪問單個檔案。

優化磁碟效能

在同時修改的非常大的目錄(超過 10 萬個文件)上執行列表()時,Linux NFS 客戶端可以掛起,而不返回響應。ls已在核心 5.11 中修正此問題,該核心已移植至 Amazon Linux 2 核心 4.14、5.4 和 5.10。

如果可能,建議您將檔案系統上的目錄數目保持在 10,000 以下。盡可能使用嵌套子目錄。

列出目錄時,如果不需要文件屬性則避免獲取,因爲這些文件屬性本來就不存儲在目錄中。

最佳化NFS讀取大小

該NFSread_ahead_kb屬性定義了在連續讀取操作期間 Linux 內核預先讀取或預取的千字節數。

對於 5.4.* 之前的 Linux 核心版本,read_ahead_kb 值的設定方式為 NFS_MAX_READAHEAD 乘以 rsize (在掛載選項中設定的用戶端設定讀取緩衝區大小) 的值。使用建議掛載選項時,此公式會將 read_ahead_kb 設定為 15 MB。

注意

從 Linux 核心版本 5.4.* 開始,Linux 用NFS戶端會使用預設read_ahead_kb值 128 KB。我們建議將此值增加到 15 MB。

在 1.33.2 版和更新amazon-efs-utils版本中提供的 Amazon EFS 掛載協助程式會在掛載檔案系統後rsize,自動將read_ahead_kb值修改為等於 15* 或 15 MB。

對於 Linux 核心 5.4 或更高版本,如果您不使用掛載輔助程式來掛載檔案系統,請考慮手動設定 read_ahead_kb 為 15 MB 以改善效能。掛載檔案系統之後,您可以使用下列指令來重設 read_ahead_kb 值。使用此命令之前,請取代下列值:

  • 按所需的大小取代 read-ahead-value-kb (以 KB 為單位)。

  • 用檔案系統的掛載點取代 efs-mount-point

device_number=$(stat -c '%d' efs-mount-point) ((major = ($device_number & 0xFFF00) >> 8)) ((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00))) sudo bash -c "echo read-ahead-value-kb > /sys/class/bdi/$major:$minor/read_ahead_kb"

下列範例將 read_ahead_kb 大小設定為 15 MB。

device_number=$(stat -c '%d' efs) ((major = ($device_number & 0xFFF00) >> 8)) ((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00))) sudo bash -c "echo 15000 > /sys/class/bdi/$major:$minor/read_ahead_kb"