解決 Amazon EFS 效能問題 - Amazon Elastic File System
無法建立EFS檔案系統拒絕訪問文件系統上允許的NFS文件訪問 Amazon EFS 控制台時出現錯誤Amazon EC2 實例掛起應用程式撰寫大量資料造成的停止回應同步開啟太多檔案而造成效能不佳自訂NFS設定造成寫入延遲使用 Oracle Recovery Manager 建立備份比較慢

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

解決 Amazon EFS 效能問題

一般而言，如果您在 Amazon EFS 遇到無法解決的問題，請確認您使用的是最新的 Linux 核心。如果您使用的是企業 Linux 發行版本，我們建議下列事項：

  • 具有核心 4.3 或更新版本的 Amazon Linux 2

  • Amazon Linux 2015.09 或更新版本

  • RHEL7.3 或更新版本

  • Ubuntu 16.04 的所有版本

  • Ubuntu 14.04 含核心 3.13.0-83 或更新版本

  • SLES12 集或更高版本

如果您使用的是另一個發行版本或自訂核心，建議使用核心版本 4.3 或更新版本。

注意

RHEL6.9 對於某些工作負載來說可能不理想，原因是. 同步開啟太多檔案而造成效能不佳

無法建立EFS檔案系統

建立EFS檔案系統的要求失敗，並顯示下列訊息：

User: arn:aws:iam::111122223333:user/username is not authorized to
perform: elasticfilesystem:CreateFileSystem on the specified resource.
採取動作

檢查您的 AWS Identity and Access Management (IAM) 策略以確認您已獲得使用指定資源條EFS件建立檔案系統的授權。如需詳細資訊，請參閱 Amazon 的身分和存取管理 EFS。

拒絕訪問文件系統上允許的NFS文件

當指派超過 16 個存取群組 IDs (GIDs) 的使用者嘗試在NFS檔案系統上執行作業時，可能會拒絕他們存取檔案系統上允許的檔案。之所以發生這個問題，是因為GIDs每位使用者最多支援 16 個NFS通訊協定，而且任何其他任何額外的GIDs都會從用NFS戶端要求截斷 (如 RFC55 31 中所定義)。

採取動作

重新建構您的NFS使用者和群組對應，讓每位使用者指定的存取群組不超過 16 個 (GIDs)。

訪問 Amazon EFS 控制台時出現錯誤

本節說明使用者在存取 Amazon EFS 管理主控台時可能遇到的錯誤。

驗證 ec2:DescribeVPCs 憑證時發生錯誤

存取 Amazon EFS 主控台時，會顯示下列錯誤訊息：

AuthFailure: An error occurred authenticating your credentials for ec2:DescribeVPCs.

此錯誤表示您的登入認證未成功透過 Amazon EC2 服務進行驗證。在您選擇的檔案系統中建立EFS檔案系統時，Amazon EFS 主控台會代表您呼叫 Amazon EC2 服務。VPC

採取動作

確保用戶端存取 Amazon EFS 主控台的時間已正確設定。

Amazon EC2 實例掛起

Amazon EC2 執行個體可能會當機，因為您在未先卸載檔案系統的情況下刪除了檔案系統掛載目標。

採取動作

刪除掛載目標前，請先卸載檔案系統。如需卸載 Amazon EFS 檔案系統的詳細資訊，請參閱卸載檔案系統。

應用程式撰寫大量資料造成的停止回應

將大量資料寫入 Amazon 的應用程式會EFS當機，並導致執行個體重新開機。

採取動作

如果應用程式花費太長時間將其所有資料寫入 AmazonEFS，Linux 可能會重新啟動，因為程序似乎沒有回應。此行為之定義由 kernel.hung_task_panic 與 kernel.hung_task_timeout_secs 這兩種核心組態參數負責。

在以下例子中，ps 命令會在執行個體重新啟動前將停止回應程序的狀態回報為 D，代表該程序正在等待 I/O。

$ ps aux | grep large_io.py
root 33253 0.5 0.0 126652 5020 pts/3 D+ 18:22 0:00 python large_io.py
/efs/large_file

為避免重新啟動，請提高偵測到停止回應任務時的逾時時間或停用核心錯誤。以下命令可在大多數的 Linux 系統上停用停止回應的任務核心錯誤。

$ sudo sysctl -w kernel.hung_task_panic=0

同步開啟太多檔案而造成效能不佳

同時開啟多個檔案的應用程式無法如預期般提高 I/O 平行效能。

採取動作

網路檔案系統版本 4 (NFSv4) 用戶端和 RHEL 6 個使用 NFSv4 .1 的用戶端上會發生這個問題，因為這些用NFS戶端序列化NFSOPEN和CLOSE作業。請使用NFS通訊協定 4.1 版，以及其中一個沒有此問題的建議 Linux 發行版。

如果您無法使用 NFSv4 .1，請注意 Linux NFSv4 .0 用戶端會依使用者 ID 和群組序列化開啟和關閉要求。IDs即使多個程序或多個執行緒同時發出請求，序列化依然會進行。客戶端一次只發送一個打開或關閉操作到NFS服務器，當所有的IDs匹配。若要解決這些問題，您可以執行下列任何動作：

  • 您可以在同一個 Amazon 執行個EC2體上從不同的使用者 ID 執行每個程序。

  • 您可以在所有開啟的要求IDs中讓使用者保持相同狀態，並改為修IDs改群組集。

  • 您可以從單獨的 Amazon 執行個EC2體執行每個程序。

自訂NFS設定造成寫入延遲

您擁有自訂NFS用戶端設定，Amazon 執行個體最多需要三秒鐘的時間才能看到從另一個 Amazon EC2 執行個體在檔案系統上執行的寫入操作。EC2

採取動作

如果您遭遇此問題，您可以使用下列其中一種方法解決：

  • 如果讀取資料之 Amazon EC2 執行個體上的NFS用戶端已啟用屬性快取，請卸載檔案系統。然後透過 noac 選項將其重新掛載，以停用屬性快取。依預設，會啟用 NFSv4 .1 中的屬性快取。

    注意

    停用用戶端快取可能會降低應用程式效能。

  • 您也可以使用與NFS程序相容的程式設計語言，視需要清除屬性快取。若要執行此操作，您可以在讀取請求之前立即傳送 ACCESS 程序請求。

    例如，使用 Python 程式設計語言，您可以建構下列呼叫。

    # Does an NFS ACCESS procedure request to clear the attribute cache, given a path to the file
import os
os.access(path, os.W_OK)

使用 Oracle Recovery Manager 建立備份比較慢

如果 Oracle Recovery Manager 在開始備份任務之前暫停了 120 秒，則使用 Oracle Recovery Manager 建立備份可能較慢。

採取動作

如果您遇到此問題，請停用「Oracle Direct」NFS，如在「Oracle 說明中心」中啟用與停用直接用NFS戶端控制中所述。NFS

注意

Amazon EFS 不支持甲骨文直接NFS。