Amazon EFS 效能 - Amazon Elastic File System
效能摘要儲存類別效能模式輸送量模式效能秘訣

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

Amazon EFS 效能

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

主題

效能摘要

檔案系統效能通常使用從延遲、輸送量以及每秒讀寫次數 (IOPS) 這幾個維度來衡量。Amazon EFS 在這些維度上的效能取決於檔案系統的組態。下列組態會影響 Amazon EFS 檔案系統效能：

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

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

    重要

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

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

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

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

檔案系統類型

輸送量模式

讀取操作

寫入操作

讀取操作

寫入操作

Per-file-system讀取1

Per-file-system寫入1

每個客戶端讀/寫

區域性

 Elastic

低至 250 微秒 (µs)

 As low as 2.7 milliseconds (ms) 900,000–2,500,0002 500,0002

每秒 10–60 GB (GiBps)

1–5 GiBps

每秒 1，500 MB (MiBps)3

區域性

 Provisioned

低至 250 µs

 As low as 2.7 ms 55,000 25,000

3 - 10 GiB/s

1 - 3.33 GiB/s

 500 MiBps

區域性

 Bursting

低至 250 µs

 As low as 2.7 ms 35,000 7,000

3 - 5 GiB/s

1 - 3 GiB/s

 500 MiBps

單區域

 Elastic, Provisioned, Bursting

低至 250 µs

低至 1.6 毫秒

 35,000 7,000

3 GiBps4

1 GiBps4

 500 MiBps
注意

註腳：

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

  2. 根據預設，使用彈性輸送量的檔案系統，不常存取的資料最多讀取 IOPS 為 90，000、經常存取的資料最多讀取 IOPS 為 250，000，以及寫入 IOPS 為 50，000。如果您的工作負載需要更多 IOPS，則您可以請求增加最多 10 倍的這些數字。如需詳細資訊，請參閱您可以提高的 Amazon EFS 配額。其他建議適用於實現最大 IOPS。如需詳細資訊，請參閱優化工作負載需要較高的輸送量和 IOPS。

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

  4. 使用爆量輸送量的單區域檔案系統，可以使用爆量輸送量驅動與區域檔案系統相同的per-file-system讀取和寫入輸送量量 （讀取速度上限為 5 GiBps，寫入速度上限為 3 GiBps)。

儲存類別

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

  • EFS 標準儲存體類別使用固態硬碟 (SSD) 儲存為經常存取的檔案提供最低延遲等級。此儲存類別提供第一位元組延遲，讀取最低可達 250 微秒，寫入最低可達 2.7 毫秒。

  • EFS 不常存取 (IA) 和 EFS Archive 儲存類別可存放存取頻率較低的資料，而不需要經常存取的資料所需的延遲效能。這些儲存類別提供几十毫秒的第一個位元組延遲。

如需 EFS 儲存類別的詳細資訊，請參閱EFS 儲存類別。

效能模式

Amazon EFS 提供以下兩種效能模式：一般用途和最大 I/O。

  • 一般用途模式具有最低的每次操作延遲，並且是檔案系統的預設效能模式。單區域檔案系統一律使用一般用途效能模式。為獲得更快效能，我們建議您始終使用「一般用途」效能模式。

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

    重要

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

若要協助確保您的工作負載保持在一般用途效能模式的檔案系統可用的 IOPS 限制內，您可以監控 PercentIOLimit CloudWatch 指標。如需詳細資訊，請參閱Amazon EFS 的 CloudWatch 指標。

應用程式可彈性地擴展 IOPS，達到與效能模式相關的極限。IOPS 不會單獨向您收費；其費用計入檔案系統的輸送量帳戶中。每個網路檔案系統 (NFS) 請求都會按 4 KB 輸送量計費，或按其實際請求和回應中較大的輸送量計費。

輸送量模式

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

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

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

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

  • 彈性輸送量 （建議） – 當您的工作負載和效能需求繁多或無法預測，難以預測，或應用程式以average-to-peak比率 5% 或更低的速度驅動輸送量時，請使用預設的彈性輸送量。如需詳細資訊，請參閱彈性輸送量。

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

  • 爆量輸送量 – 當您希望輸送量隨著檔案系統中的儲存量而擴展時，請使用爆量輸送量。

    如果在使用爆量輸送量之後，發現您的應用程式受到輸送量限制 （例如，它使用超過 80% 的允許輸送量，或您已使用所有爆量額度），則您應該使用彈性或佈建的輸送量。如需詳細資訊，請參閱爆量輸送量。

通過比較 MeteredIOBytes 指標和 PermittedThroughput 指標，與指標進行比較，您可以使用 Amazon CloudWatch 來判斷工作負載的平均與峰值比率。如需 Amazon EFS 請求指標的詳細資訊，請參閱 Amazon EFS 的 CloudWatch 指標。

彈性輸送量

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

由於具有彈性輸送量的檔案系統的輸送量效能會自動擴展，因此您不需要指定或佈建輸送量容量，即可滿足您的應用程式需求。您只需支付中繼資料和資料讀取或寫入的數量，而且在使用彈性輸送量時不會累積或消耗爆量額度。

注意

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

如需每個區域彈性輸送量限制的相關資訊，請參閱您可以提高的 Amazon EFS 配額。

佈建輸送量

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

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

如果檔案系統的基準輸送量超過佈建的輸送量量，則會自動使用檔案系統允許的爆量輸送量 （最多 \爆量中的基準輸送量限制 AWS 區域)。

如需每個RegionProvisioned輸送量限制的相關資訊，請參閱 您可以提高的 Amazon EFS 配額。

爆量輸送量

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

當有爆量額度可用時，檔案系統可驅動每個 TiB 儲存體高達 100 MiBps 的輸送量，最高可達 AWS 區域 限制，最低 100 MiBps。如果無可用爆量額度，檔案系統驅動上限為每 TiB 儲存容量 50 MiB/s，下限為 1 MiB/s。

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

了解 Amazon EFS 爆量額度

透過爆量輸送量，每個檔案系統都會以基準速率獲得爆量額度，而基準速率取決於存放在 EFS 標準儲存類別中的檔案系統大小。每 TiB 儲存容量的基準傳輸率為 50 MiB/s (等同每 GiB 儲存容量 50 KiB/s)。Amazon EFS 對讀取操作計量速率是寫入操作速率的三分之一，允許檔案系統將基準速率提高到每 GiB 讀取輸送量 150 KiBp/s，或每 GiB 寫入輸送量 50 KiB/s。

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

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

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

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

檔案系統大小 爆量輸送量 基準輸送量
標準儲存中 100 GiB 的計量資料

  • 每天最多可以 300 (MiB/s) 只讀傳輸率維持 72 分鐘，或

  • 每天最多可以 100 MiB/s 僅限寫入傳輸率維持 72 分鐘

  • 持續驅動高達 15 MiB/s 只讀傳輸率

  • 持續驅動高達 5 MiB/s 只寫傳輸率
標準儲存中 1 TiB 的計量資料

  • 每天最多可以爆增至 300 MiB/s 只讀傳輸率維持 12 小時，或

  • 每天最多可以爆增至 100 MiB/s 只寫傳輸率維持 12 小時

  • 持續驅動 150 MiB/s 只讀傳輸率

  • 持續驅動 50 MiB/s 只寫傳輸率
標準儲存中 10 TiB 的計量資料

  • 每天最多可以爆增至 3 GiB/s 只讀傳輸率維持 12 小時，或

  • 每天最多可以爆增至 1 GiB/s 只寫傳輸率維持 12 小時

  • 持續驅動 1.5 GiB/s 只讀傳輸率

  • 持續驅動 500 MiB/s 只寫傳輸率
通常，較大的文件系統

  • 每天最多可以爆增至每 TiB 儲存容量 300 MiB/s 只讀傳輸率維持 12 小時，或

  • 每天最多可以爆增至每 TiB 儲存容量 100 MiB/s 只寫傳輸率維持 12 小時

  • 持續驅動每 TiB 儲存容量 150 MiB/s只讀傳輸率

  • 持續驅動每 TiB 儲存容量 50 MiB/s只寫傳輸率
注意

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

在計算基準傳輸率和爆量傳輸率時所使用的檔案系統大小，是透過 DescribeFileSystems 操作所取得的 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 上限，檔案系統必須使用彈性輸送量。

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

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

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

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

同時連接

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

請求模型

如果您啟用非同步寫入檔案系統的功能，則待執行的寫入作業會在非同步寫入 Amazon EFS 之前，先暫存於 Amazon EC2 執行個體上的緩衝區。非同步寫入作業的延遲通常較低。執行非同步寫入時，核心會使用額外的記憶體來進行快取。

檔案系統如果啟用了同步寫入功能，或是使用略過快取的選項 (例如 O_DIRECT) 來開啟檔案，則該檔案系統會向 Amazon EFS 發出同步請求。每項操作都會在用戶端與 Amazon EFS 之間來回往返執行。

注意

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

NFS 用戶端掛載設定

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

當您在 Amazon EC2 執行個體上掛載檔案系統時，Amazon EFS 支援網路檔案系統版本 4.0 與 4.1 (NFSv4) 通訊協定。與 NFSv4.0 (每秒少於 1,000 個檔案) 相比，NFSv4.1 (每秒超過 10,000 個檔案) 可為并行小型檔案讀取操作提供更好的效能。執行 macOS Big Sur 的 Amazon EC2 MacOS 執行個體僅支援 NFSv4.0。

請勿使用下列掛載選項：

  • noac、actimeo=0、acregmax=0、acdirmax=0：這些選項會停用屬性快取，這會對效能造成非常大的影響。

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

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

注意

在掛載檔案系統時，您可以考慮將 NFS 用戶端讀取和寫入緩衝區大小增加到 1 MB。

優化小型檔案效能

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

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

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

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

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

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

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

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

優化磁碟效能

在正修改的大型目錄 (超過 10 萬個檔案) 上同時執行清單 (ls) 時，Linux NFS 用戶端可能會當機，而不會傳回回應。已在核心 5.11 中修正此問題，該核心已移植至 Amazon Linux 2 核心 4.14、5.4 和 5.10。

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

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

優化 NFS read_ahead_kb 大小

NFS read_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。

在 amazon-efs-utils 版本 1.33.2 版及更高版本中可用的 Amazon EFS 掛載協助程式會在掛載檔案系統後，自動將 read_ahead_kb 值修改為等於 15* rsize 或 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"