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

# Amazon EFS 效能秘訣
<a name="performance-tips"></a>

使用 Amazon EFS 時，請記住下列效能秘訣：

## 平均 I/O 大小
<a name="efs-perf-avg-io-size"></a>

Amazon EFS 的分散式本質，實現了高度的可用性、持久性與可擴展性。這種分散式架構讓每個檔案作業只會產生些許的延遲負擔。由於每個作業的低延遲，因此整體輸送量通常會隨著平均 I/O 大小的增加而提高，因為延遲負擔會由大量的資料分攤。

## 優化工作負載需要較高的輸送量和 IOPS
<a name="recs-intensive-workloads"></a>

對於需要高輸送量和 IOPS 的工作負載，請使用以一般用途效能模式和彈性輸送量設定的區域檔案系統。

**注意**  
若要達到經常存取資料的讀取 IOPS 上限，檔案系統必須使用彈性輸送量。

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

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

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

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

## 同時連接
<a name="efs-perf-sim-connections"></a>

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

## 請求模型
<a name="efs-perf-request-model"></a>

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

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

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

## NFS 用戶端掛載設定
<a name="efs-perf-nfs-client-mnt-settings"></a>

確定您正在使用建議的掛載選項 (如 [掛載 EFS 檔案系統](mounting-fs.md) 和 [Linux 的掛載考量](mounting-fs-mount-cmd-general.md) 中所述)。

當您在 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。

## 優化小型檔案效能
<a name="optimize-open-close"></a>

您可以盡可能減少檔案重新開啟、增加平行處理，以及盡量綁定參考檔案，以改善小型檔案的效能。
+ 減少到伺服器的往返次數。

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

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

  每次往返 (文件開啓，文件關閉) 時間與讀取或寫入批量資料的時間相同。更有效的方法是在計算工作開始時，一次性打開輸入或輸出文件，并在整個計算工作期間保持打開狀態。
+ 使用平行處理原則來減少往返時間的影響。
+ 將參考檔案綁定在一個 `.zip` 檔案中。某些應用程式會使用大量小型參考文件，這些文件大部分為只讀。將這些文件綁定在 `.zip` 檔案中，以便您可以一次打開關閉多個檔案。

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

## 優化磁碟效能
<a name="optimize-directories"></a>

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

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

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

## 優化 NFS read\_ahead\_kb 大小
<a name="efs-perf-optimize-nfs-read-ahead"></a>

NFS `read_ahead_kb` 屬性定義了 Linux 內核在連續讀取操作期間預先讀取或預取的千位元組數。

對於 5.4.\* 之前的 Linux 核心版本，`read_ahead_kb` 值的設定方式為 `NFS_MAX_READAHEAD` 乘以 `rsize` (在掛載選項中設定的用戶端設定讀取緩衝區大小) 的值。使用[建議掛載選項](mounting-fs-mount-cmd-general.md)時，此公式會將 `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"
```