本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 對 Amazon EFS 效能問題進行故障診斷
一般而言，如果您在解決 Amazon EFS 問題時遇到困難，請確認您使用的是最新的 Linux 核心。如果您使用的是企業 Linux 發行版本，我們建議下列事項：
+ 具有核心 4.3 或更新版本的 Amazon Linux 2
+ Amazon Linux 2015.09 或更新版本
+ RHEL 7.3 或更新版本
+ Ubuntu 16.04 的所有版本
+ Ubuntu 14.04 含核心 3.13.0-83 或更新版本
+ SLES 12 Sp2 或更新版本
如果您使用的是另一個發行版本或自訂核心，建議使用核心版本 4.3 或更新版本。
**注意**
由於[同步開啟太多檔案而造成效能不佳](#open-close-operations-serialized)，就特定的工作負載而言，RHEL 6.9 可能是次佳選擇。
**Topics**
+ [無法建立 EFS 檔案系統](#cant-create-filesystem)
+ [拒絕在 NFS 檔案系統上存取允許的檔案](#nfs-16-group-limit)
+ [存取 Amazon EFS 主控台時發生錯誤](#efs-console-access-errors)
+ [Amazon EC2 執行個體停止回應](#ec2-instance-hangs)
+ [應用程式撰寫大量資料造成的停止回應](#application-large-data-hangs)
+ [同步開啟太多檔案而造成效能不佳](#open-close-operations-serialized)
+ [自訂 NFS 設定造成寫入延遲](#custom-nfs-settings-write-delays)
+ [使用 Oracle Recovery Manager 建立備份比較慢](#oracle-backup-slow)
## 無法建立 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 的身分和存取管理](security-iam.md)。
## 拒絕在 NFS 檔案系統上存取允許的檔案
當指派給使用者的存取群組 ID (GID) 超過 16 個時，使用者嘗試在 NFS 檔案系統上執行操作，可能被拒绝对檔案系统上允许的文件进行存取。這類問題發生的原因是 NFS 通訊協定對每位使用者最多支援 16 個 GID，并且任何超出的 GID 會從 NFS 用戶端請求処截斷，具體可見 [RFC 5531](https://www.rfc-editor.org/rfc/rfc5531) 中的定義。
**採取動作**
可以重新架構 NFS 使用者和群組對應，以便指定給每位使用者的存取群組 (GID) 數不超過 16 個。
## 存取 Amazon EFS 主控台時發生錯誤
本區段說明使用者在存取 Amazon EFS 管理主控台時可能遇到的錯誤。
### 驗證 `ec2:DescribeVPCs` 憑證時發生錯誤
存取 Amazon EFS 主控台時，系統會顯示下列錯誤訊息：
```
AuthFailure: An error occurred authenticating your credentials for ec2:DescribeVPCs.
```
此錯誤表示您的登入憑證未成功通過 Amazon EC2 服務驗證。在您選擇的 VPC 中建立 EFS 檔案系統時，Amazon EFS 主控台會代表您呼叫 Amazon EC2 服務。
**採取動作**
確保正確設定用戶端存取 Amazon EFS 主控台的時間。
## Amazon EC2 執行個體停止回應
若您在刪除檔案系統掛載目標前未先行卸載該檔案系統，Amazon EC2 執行個體可能會因此停止回應。
**採取動作**
刪除掛載目標前，請先卸載檔案系統。如需卸載 Amazon EFS 檔案系統的詳細資訊，請參閱 [卸載檔案系統](unmounting-fs.md)。
## 應用程式撰寫大量資料造成的停止回應
撰寫大量資料至 Amazon EFS 的應用程式停止回應並造成該執行個體重新啟動。
**採取動作**
如果應用程式需要很長的時間才能將所有資料寫入至 Amazon EFS，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) 協定，以及使用 NFSv4.1 的 RHEL 6 用戶端上，因為這些 NFS 用戶端序列化 NFS OPEN 和 CLOSE 操作。使用 NFS 通訊協定第 4.1 版，以及建議使用、無此問題發生的一種 [Linux 發行版本](#recommend.linux.dist)。
如果您無法使用 NFSv4.1，請注意 Linux NFSv4.0 用戶端會依使用者 ID 和群組 ID 順序開啟和關閉請求。即使多個程序或多個執行緒同時發出請求，序列化依然會進行。當所有 ID 相符時，用戶端一次只會傳送一個開啟或關閉操作到 NFS 伺服器。若要解決這些問題，您可以執行下列任何動作：
+ 您可以在同一個 Amazon EC2 執行個體上以不同的使用者 ID 執行個別程序。
+ 您可以將所有開啟請求中的使用者 ID 保持不變，並改為修改一組群組 ID。
+ 您可以從單獨的 Amazon EC2 執行個體執行每個程序。
## 自訂 NFS 設定造成寫入延遲
您擁有自訂的 NFS 用戶端設定，而 Amazon EC2 執行個體最多需要三秒鐘才能查看從另一個 Amazon 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 說明中心 (Oracle Help Center) 中的[啟用和停用 NFS 的 Direct NFS 用戶端控制](https://docs.oracle.com/database/122/HPDBI/enabling-and-disabling-direct-nfs-client-control-of-nfs.htm)來停用 Oracle Direct NFS。
**注意**
Amazon EFS 不支援 Oracle Direct NFS。