為什麼我的 EFS 檔案系統效能變慢？

簡短描述

Amazon EFS 的分散式多可用區域架構可讓每個檔案作業產生較小的延遲開銷。整體輸送量通常會隨著平均輸入/輸出大小的增加而增加，因為開銷分攤到大量的資料上。

Amazon EFS 效能取決於多個因素，包括下列各項：

• EFS 的儲存類別。
• 效能和輸送量模式。
• 在 EFS 上執行的作業類型 (例如中繼資料密集等)。
• 存放在 EFS 中的資料屬性 (例如檔案大小和數目)。
• 掛載選項。
• 用戶端的限制。

解決方案

EFS 的儲存類別

如需詳細資訊，請參閱效能摘要。

效能和輸送量模式

效能模式

Amazon EFS 提供兩種效能模式：一般用途和最大輸入/輸出。應用程式可彈性地擴充 IOPS，達到與效能模式相關的極限。若要判斷要使用的效能模式，請參閱 Amazon EFS 中的一般用途和最大輸入/輸出效能模式有何區別？

輸送量模式

以檔案為基礎的工作負載通常有尖峰，會在短時間內推動高輸送量，但在較長的時間內推動較低的輸送量。Amazon EFS 的設計可在一段時間內高載到高輸送量水準。

設定的輸送量和 IOPS 會影響 Amazon EFS 的效能。最佳實務是對工作負載進行基準測試，以協助您選擇適當的輸送量和效能模式。選取佈建的輸送量時，請選取可適當符合您工作負載需求的值。在高載輸送量模式的情況下，您可以使用虛擬檔案增加 Amazon EFS 的大小，以增加基準輸送量。若要分析檔案系統所使用的輸送量和 IOPS，請參閱使用指標數學搭配 Amazon EFS。

Amazon EFS 也可縱向擴展至 PB 等級的儲存量，且具有兩種輸送量模式：高載和佈建。在高載模式中，EFS 檔案系統的大小越大，輸送量擴展就越高。至於佈建模式，檔案系統的輸送量是以 MB/s 為單位設定，與資料量無關。如需輸送量模式的詳細資訊，請參閱 Amazon EFS 高載抵用金如何運作？

在 EC2 執行個體上執行的作業類型

中繼資料輸入/輸出作業

在下列情況下，EFS 效能會受到影響：

• 檔案大小很小時，因為這是分散式系統。這種分散式架構使每個檔案操作只會產生些許的延遲。由於每個作業延遲很低，因此整體輸送量通常會隨著平均輸入/輸出大小的增加而增加，因為開銷分攤到大量的資料上。
• 如果工作負載或作業依序產生許多小型檔案，則共用檔案系統的效能會受到影響。這會導致每個作業的開銷增加。
• 如果您的應用程式執行中繼資料密集型的作業，例如「ls」、「rm」、「mkdir」、「rmdir」、「rmdir」、「lookup」、「getattr」或「setattr」等作業，就會發生中繼資料輸入/輸出。任何需要系統擷取特定區塊位址的作業，都會被視為中繼資料密集型工作負載。如需詳細資訊，請參閱下列內容：
  計量：Amazon EFS 如何報告檔案系統和物件大小。
  最佳化小檔案效能。

掛載選項

• 如果您使用 amazon-efs-utils 掛載檔案系統，則預設會套用建議的掛載選項。
• 使用非預設的掛載選項，可能會降低效能。例如，使用較低的 rsize 和 wsize，會降低或關閉屬性快取。您可以檢查 mount 命令的輸出，以查看目前設定的掛載選項：

如需詳細資訊，請參閱在 EC2 執行個體上掛載檔案系統並進行測試。

命令範例

>> mount

輸出範例

fs-EXAMPLE3f75f.efs.us-east-1.amazonaws.com:/ on /home/ec2-user/efs type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,noresvport,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=<EXAMPLEIP>,local_lock=none,addr=<EXAMPLEIP>)

NFS 用戶端版本

相較於 NFSv4.0 (每秒少於 1,000 個檔案)，網路檔案系統 (NFS) 4.1 版 (NFSv4) 通訊協定可為平行小型檔案讀取作業提供更好的效能 (每秒超過 10,000 個檔案)。

如需詳細資訊，請參閱 NFS 用戶端掛載設定。

用戶端限制

EC2 執行個體的瓶頸

如果使用檔案系統的應用程式無法驅動 EFS 的預期效能，請將應用程式最佳化。同時，也對應用程式託管的主機或服務進行基準測試，例如 Amazon EC2、AWS Lambda 等。EC2 執行個體上的資源短缺可能會影響應用程式有效使用 EFS 的能力。

若要檢查 EC2 針對您的應用程式需求是否佈建不足，請監控 Amazon EC2 CloudWatch 指標，例如 CPU、Amazon Elastic Block Store (Amazon EBS) 等。分析應用程式架構和資源需求的各種指標，可協助您判斷是否應根據需求來重新設定應用程式或執行個體。

使用 4.0 以上的 Linux 核心版本

為了獲得最佳效能並避免各種已知的 NFS 用戶端錯誤，最佳實務是使用具有 Linux 核心 4.0 或更新版本的 AMI。

此規則的例外情況是 RHEL 和 CentOS 7.3 及更新版本。這些作業系統的核心收到了適用於 NFS v4.1 的修正程式和增強功能的向後移植版本。如需詳細資訊，請參閱 NFS 支援。

複製檔案

使用 cp 命令複製檔案時，您可能會遇到緩慢的情況。這是因為 copy 命令是序列作業，意思是一次複製一個檔案。如果每個檔案的檔案大小都很小，則傳送該檔案的輸送量會很小。

傳送檔案時，您可能也會注意到延遲。EFS 的分散式特性表示其必須複寫到所有掛載點，因此每個檔案作業都會產生開銷。所以，傳送檔案的延遲是預期的行為。

建議

最佳實務是執行平行輸入/輸出作業 (例如使用 rsync)。如果您使用 rsync，請注意 cp 和 rsync 在序列 (單一執行緒) 作業中工作，而不是平行作業。這會使複製速度變慢。使用工具，例如 fpart 或 NU Parallel。Fpart 這種工具可協助您對檔案樹進行排序並將其封裝到「分區」中。Fpart 附帶一個名為 fpsync 的 Shell 指令碼，此指令碼會包裝 fpart 和 rsync 以平行啟動多個 rsync。Fpsync 提供自己的嵌入式排程器。這樣做，可讓您比使用更常見的序列方法更快地完成這些任務。

如需詳細資訊，請參閱 Amazon EFS 效能秘訣。

---

相關資訊

NFS 用戶端的配額