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

每個客戶端讀/寫

區域性

 彈性

低至 250 微秒 (µs)

 低至 2.7 毫秒 （ms） 90，000–250，0002 50,000

每秒 10–60 GB （GiBps）

1–5 GiBps

每秒 1，500 MB （MiBps）3

區域性

 佈建

低至 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 GiBps4

1 GiBps4

 500 MiBps
注意

註腳：

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

  2. 使用 Elastic 輸送量的檔案系統可IOPS針對不常存取的資料驅動最多 90，000 個讀取，以及IOPS針對經常存取的資料驅動最多 250，000 個讀取。其他建議適用於達到最多 IOPS。如需詳細資訊，請參閱最佳化需要高輸送量和 的工作負載 IOPS。

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

  4. 使用爆量輸送量的單區域檔案系統，可以使用爆量輸送量驅動與區域檔案系統相同的 per-file-system讀取和寫入輸送量量 （最多 5 個 GiBps 用於讀取，3 個 GiBps 用於寫入）。

儲存類別

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 （KB） 的輸送量，或其實際請求和回應大小，以較大者為準。

輸送量模式

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

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

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

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

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

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

  • 高載輸送量 – 當您想要隨著檔案系統中的儲存量而擴展的輸送量時，請使用高載輸送量。

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

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

彈性輸送量

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

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

注意

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

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

佈建輸送量

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

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

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

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

高載輸送量

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

當有爆量額度可用時，檔案系統每個 TiB 的儲存容量最多可以驅動 100 MiBps 個，最高 AWS 區域 限制，最低 100 個 MiBps。如果沒有爆量點數可用，檔案系統最多可以驅動 50 MiBps 個 TiB 的儲存體，其中至少 1 個儲存體 MiBps。

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

了解 Amazon EFS爆量額度

透過爆量輸送量，每個檔案系統都會以基準速率獲得爆量額度，而基準速率取決於儲存在EFS標準儲存類別中的檔案系統大小。基準速率為 50 MiBps 每 tebibyte TiB 】 儲存體 （相當於 50 KiBps 每 GiB 儲存體）。Amazon EFS儀表讀取操作速率高達寫入操作速率的三分之一，允許檔案系統驅動基準速率高達 150 KiBps per GiB 的讀取輸送量，或 50 KiBps per GiB 的寫入輸送量。

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

例如，標準儲存類別中具有 100 GiB 計量資料的檔案系統，其基準輸送量為 5 MiBps。在 24 小時無活動期間，檔案系統獲得 432，000 MiB 的額度 （5 MiB × 86，400 秒 = 432，000 MiB），可用於在 100 時爆量 MiBps 72 分鐘 （432，000 MiB ÷ 100 MiBps = 72 分鐘）。

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

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

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

  • 每天最多 72 分鐘的爆量為 300 （MiBps） 唯讀，或

  • 每天最多 72 分鐘的爆量為 100 次僅限 MiBps 寫入

  • 持續驅動最多 15 MiBps 個唯讀

  • 持續最多 5 個僅限 MiBps 寫入的磁碟機
標準儲存中 1 TiB 的計量資料

  • 每天爆量為 300 MiBps 個唯讀 12 小時，或

  • 每天爆量為 100 只 MiBps 寫入 12 小時

  • 持續驅動 150 MiBps 唯讀

  • 持續驅動 50 僅限 MiBps 寫入
標準儲存中 10 TiB 的計量資料

  • 每天爆量為 3 GiBps 個唯讀 12 小時，或

  • 每天爆量為 12 小時僅限 GiBps 寫入

  • 持續驅動 1.5 GiBps 唯讀

  • 持續驅動 500 僅限 MiBps 寫入
通常，較大的文件系統

  • 每天 12 小時每個 TiB 的儲存爆量為 300 MiBps 個唯讀，或

  • 每天 12 小時每個 TiB 的儲存爆量為 100 個僅限 MiBps 寫入

  • 持續每個儲存 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 EFS 檔案系統同時掛載到數千個 Amazon EC2和其他 AWS 運算執行個體。如果可以跨更多執行個體來平行執行應用程式，您就能跨運算執行個體提高檔案系統上的總輸送量。

請求模型

如果您啟用非同步寫入檔案系統，Amazon EC2執行個體上會緩衝等待中的寫入操作，然後再以EFS非同步方式寫入 Amazon。非同步寫入作業的延遲通常較低。執行非同步寫入時，核心會使用額外的記憶體來進行快取。

已啟用同步寫入或使用繞過快取的選項開啟檔案的檔案系統 （例如 O_DIRECT），會向 Amazon 發出同步請求EFS。每個操作都會在用戶端和 Amazon 之間進行往返EFS。

注意

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

NFS 用戶端掛載設定

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

在 Amazon EC2執行個體上安裝檔案系統時，Amazon EFS支援 Network File System 4.0 版和 4.1 （NFSv4） 通訊協定。NFSv4.1 為平行小型檔案讀取操作 （每秒超過 10，000 個檔案） 提供比 NFSv4.0 （每秒少於 1，000 個檔案） 更好的效能。對於執行 EC2 macOS Big Sur 的 Amazon 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 核心在循序讀取操作期間預先讀取或預先擷取的 KB 數。

對於 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掛載協助程式會在掛載檔案系統後，自動將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"