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

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

使用 Amazon FSx for Lustre 時，請記住下列效能秘訣。如需服務限制，請參閱 [Amazon FSx for Lustre 的服務配額](limits.md)。
+ **平均 I/O 大小** – 由於 Amazon FSx for Lustre 是網路檔案系統，因此每個檔案操作都會在用戶端和 Amazon FSx for Lustre 之間進行往返，因而產生少量的延遲額外負荷。由於每個作業的低延遲，因此整體傳輸量通常會隨著平均 I/O 大小的增加而提高，因為延遲負擔會由大量的資料分攤。
+ **請求模型** – 透過啟用對檔案系統的非同步寫入，等待中的寫入操作會在 Amazon EC2 執行個體上緩衝，然後再以非同步方式寫入 Amazon FSx for Lustre。非同步寫入作業的延遲通常較低。執行非同步寫入時，核心會使用額外的記憶體來進行快取。已啟用同步寫入的檔案系統會向 Amazon FSx for Lustre 發出同步請求。每個操作都會經過用戶端和 Amazon FSx for Lustre 之間的往返。
**注意**  
您所選擇的請求模型，必須在一致性 (如果使用多個 Amazon EC2 執行個體) 和速度之間權衡折衷。
+ **限制目錄大小** – 若要在持久性 2 FSx for Lustre 檔案系統上獲得最佳中繼資料效能，請將每個目錄限制在小於 100K 個檔案。限制目錄中的檔案數量可減少檔案系統在父目錄上取得鎖定所需的時間。
+ **Amazon EC2 執行個體** – 執行大量讀取和寫入操作的應用程式可能需要比不需要的應用程式更多的記憶體或運算容量。為運算密集型工作負載啟動 Amazon EC2 執行個體時，請選擇具有應用程式所需資源數量的執行個體類型。Amazon FSx for Lustre 檔案系統的效能特性不取決於 Amazon EBS 最佳化執行個體的使用。
+ **建議用戶端執行個體調校，以獲得最佳效能**

  1. 對於記憶體超過 64 GiB 的用戶端執行個體類型，我們建議套用下列調校：

     ```
     sudo lctl set_param ldlm.namespaces.*.lru_max_age=600000
     sudo lctl set_param ldlm.namespaces.*.lru_size=<100 * number_of_CPUs>
     ```

  1. 對於具有超過 64 個 vCPU 核心的用戶端執行個體類型，我們建議套用下列調校：

     ```
     echo "options ptlrpc ptlrpcd_per_cpt_max=32" >> /etc/modprobe.d/modprobe.conf
     echo "options ksocklnd credits=2560" >> /etc/modprobe.d/modprobe.conf
                 
     # reload all kernel modules to apply the above two settings
     sudo reboot
     ```

     掛載用戶端之後，需要套用下列調校：

     ```
     sudo lctl set_param osc.*OST*.max_rpcs_in_flight=32
     sudo lctl set_param mdc.*.max_rpcs_in_flight=64
     sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=50
     ```

  1. 若要最佳化目錄清單 (ls) 的效能，需要套用下列調校：

     ```
     sudo lctl set_param llite.*.statahead_max=512
     sudo lctl set_param llite.*.statahead_agl=1
     if sudo lctl get_param llite.*.statahead_xattr > /dev/null 2>&1; then
         sudo lctl set_param llite.*.statahead_xattr=1
     else
         echo "Warning: Xattr statahead is not supported on this Lustre client. Please upgrade to the latest Lustre 2.15 client to apply this tuning"
     fi
     ```

  請注意， `lctl set_param` 已知不會在重新開機時保留。由於這些參數無法從用戶端永久設定，因此建議您實作開機 Cron 任務，以使用建議的調校來設定組態。
+ **跨 OSTs工作負載平衡** – 在某些情況下，您的工作負載不會驅動檔案系統可提供的彙總輸送量 （每個 TiB 儲存體 200 MBps)。若是如此，您可以使用 CloudWatch 指標來疑難排解工作負載 I/O 模式的不平衡是否會影響效能。若要識別是否為原因，請查看 Amazon FSx for Lustre 的 CloudWatch 指標上限。

  在某些情況下，此統計資料會顯示輸送量達到或超過 240 MBps 的負載 （單一 1.2-TiB Amazon FSx for Lustre 磁碟的輸送量容量）。在這種情況下，您的工作負載不會平均分散到磁碟。如果是這種情況，您可以使用 `lfs setstripe`命令來修改工作負載最常存取之檔案的分割。為了獲得最佳效能，請在包含檔案系統的所有 OSTs 間分割具有高輸送量需求的檔案。

  如果您的檔案是從資料儲存庫匯入，您可以採取另一種方法，將高輸送量檔案平均分割至 OSTs。若要這樣做，您可以在建立下一個 Amazon FSx for Lustre 檔案系統時修改 `ImportedFileChunkSize` 參數。

  例如，假設您的工作負載使用 7.0-TiB 檔案系統 （由 6x 1.17-TiB OSTs 組成），且需要跨 2.4-GiB 檔案驅動高輸送量。在這種情況下，您可以將 `ImportedFileChunkSize`值設定為 ，`(2.4 GiB / 6 OSTs) = 400 MiB`讓您的檔案平均分散到檔案系統的 OSTs。
+ **Lustre 中繼資料 IOPS 的 用戶端** – 如果您的檔案系統已指定中繼資料組態，我們建議您安裝 Lustre 2.15 用戶端或 Lustre 2.12 用戶端，其中包含下列其中一個作業系統版本：Amazon Linux 2023；Amazon Linux 2；Red Hat/Rocky Linux 8.9、8.10 或 9.x；CentOS 8.9 或 8.10；Ubuntu 22\$1 搭配 6.2、6.5 或 6.8 核心；或 Ubuntu 20。

## Intelligent-Tiering 效能考量事項
<a name="intelligent-tiering-performance-considerations"></a>

以下是使用 Intelligent-Tiering 儲存類別處理檔案系統時的一些重要效能考量：
+ 由於智慧型分層儲存層的延遲較高，讀取較小 I/O 大小資料的工作負載需要更高的並行性，並會產生更多請求成本，才能達到與使用大型 I/O 大小的工作負載相同的輸送量。我們建議您設定夠大的 SSD 讀取快取，以便在使用較小的 IO 大小時支援更高的並行和輸送量。
+ 用戶端可以使用 Intelligent-Tiering 檔案系統驅動的最大磁碟 IOPS，取決於工作負載的特定存取模式，以及您是否已佈建 SSD 讀取快取。對於具有隨機存取的工作負載，如果資料快取在 SSD 讀取快取中，用戶端通常會驅動比資料不在快取中高出許多的 IOPS。
+ Intelligent-Tiering 儲存類別支援預先讀取，以最佳化循序讀取請求的效能。我們建議您盡可能依序設定資料存取模式，以允許預先擷取資料和提高效能。