NAS效能常見問題 - Apsara File Storage NAS

本文介紹NAS SMB/NFS協議檔案系統效能相關的常見問題及解決方案。

檔案系統的讀寫吞吐閾值與什麼相關？

通用型NAS
單個檔案系統的讀寫效能上限（峰值）與檔案系統的當前使用容量線性相關且成正比例關係，即使用容量越大，吞吐效能上限（峰值）越高。更多資訊，請參見通用型NAS。
極速型NAS
單個檔案系統的讀寫效能隨配置容量的增長呈階梯式增長。更多資訊，請參見極速型NAS。

什麼是IOPS？IOPS與吞吐、讀寫塊大小、時延有什麼關係？

IOPS（Input/Output Per Second）即每秒IO操作的次數（讀寫次數）。

讀寫塊大小、IOPS、輸送量、寫入次數和時延的關係公式為：

輸送量=IOPS*讀寫塊大小；IOPS=讀寫次數/任務整體時延

例如，容量型NAS檔案系統1 MiB寫時延約為100 ms，8 KiB寫時延約為15 ms，4 KiB寫時延約為10 ms，最大支援128個並發任務。當您需要1s內寫1 MiB資料時，可以有多種寫入方案，如下列舉其中幾種：

序號	讀寫塊大小	並發數	寫入次數	任務整體時延	IOPS	輸送量	說明
方案一	4 KiB	1	250	10 ms*250=2.5s	250/2.5s=100	4 KiB*100=400 KiB/s	小塊讀寫加上低並發數，導致吞吐和時延效能都很差，無法達到1 MiB/s的吞吐目標。
方案二	1 MiB	1	1	100 ms	1/0.1s=10	1 MiB*10=10 MiB/s	相較方案一僅提高讀寫塊大小，吞吐和時延效能有提升，達到了1 MiB/s的吞吐目標，但任務整體時延較長。
方案三	4 KiB	125	250	10 ms*（250/125）=20 ms	250/0.02s=12500	4 KiB*12500≈49 MiB/s	相較方案一僅提高任務並發數，吞吐和時延效能有提升，達到了1 MiB/s的吞吐目標，任務整體時延也很短，但IOPS較高，容易觸及檔案系統的IOPS上限。
方案四	8 KiB	125	125	15 ms*（125/125）=15 ms	125/0.015s≈8333	8 KiB*8333≈65 MiB/s	相較方案一同時提高讀寫塊大小和任務並發數，吞吐和時延效能有提升，達到了1 MiB/s的吞吐目標，任務整體延時最短，IOPS較低，不容易觸及檔案系統的IOPS上限。

讀寫吞吐超過閾值會有什麼影響？

如果您或應用程式發出的請求吞吐超過閾值時，NAS會自動對該請求限速，進而導致延遲增高。

通用型NAS可以通過Truncate命令提升吞吐閾值。具體操作，請參見如何提升通用型NAS檔案系統的讀寫吞吐閾值？。

極速型NAS可以通過擴容檔案系統提升吞吐閾值。具體操作，請參見極速型NAS擴容。

關於通用型NAS檔案系統和極速型NAS檔案系統的吞吐閾值，請參見通用型NAS效能指標和極速型NAS效能指標。

如何提升通用型NAS檔案系統的讀寫吞吐閾值？

通用型NAS檔案系統的讀寫吞吐隨檔案系統的使用容量線性增長。檔案系統讀寫吞吐與使用容量的關係，請參見通用型NAS產品規格。

通過在檔案系統寫入空洞檔案或使用Truncate命令產生一個檔案來增加檔案系統使用容量，從而提升檔案系統的讀寫吞吐。同時，空洞檔案和Truncate命令產生的檔案在阿里雲NAS上佔用實際容量，按實際大小計費。更多資訊，請參見通用型NAS計費。

例如在容量型檔案系統寫入1 TiB檔案，其讀寫吞吐可提升150 MB/s；在效能型檔案系統寫入1 TiB檔案，其讀寫吞吐可提升600 MB/s。

Linux
支援使用Truncate命令組建檔案提升讀寫吞吐。
```
sudo truncate --size=1TB /mnt/sparse_file.txt
```
其中，/mnt為檔案系統在計算節點上的掛載路徑。
Windows
支援通過在檔案系統寫入空洞檔案提升讀寫吞吐。
```
fsutil file createnew Z:\sparse_file.txt 1099511627776
```
其中，Z:\為檔案系統在計算節點上的掛載路徑。

如何解決Linux作業系統上訪問NAS效能不好？

方案一：通過nconnect參數提升單台ECS訪問NAS的吞吐
nconnect參數是NFS用戶端Linux掛載選項，通過在用戶端和伺服器之間建立更多的TCP傳輸串連來提高吞吐效能。經過測試，使用nconnect參數可以將單ECS訪問NAS的吞吐提升3倍~6倍，達到3 GB/s。
適用情境
單ECS上多並發I/O讀寫（並發大於16）。
前提條件
Linux核心版本需5.3及以上版本。
操作步驟
在mount命令中增加nconnect參數，建議nconnect=4，命令樣本如下。
```
sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,nconnect=4 
```
重要
nconnect提高的是單個ECS訪問NAS的吞吐能力，並不會提高NAS檔案系統自身的吞吐閾值。對於單並發，小資料區塊，延遲敏感型業務，開啟nconnect會引起延遲增加，不建議開啟。
方案二：通過修改sunrpc.tcp_slot_table_entries提升單台ECS訪問NAS的吞吐
Linux kernel中sunrpc決定了NFS單個連結內的通訊slot數量。不同的Linux版本採用了不同的配置。slot配置過高可能引起延遲增加，配置過低會引起吞吐不足。當您需要大吞吐時，建議slot配置為128。需要較低延遲時，slot配置為16及以下。
說明
調整sunrpc.tcp_slot_table_entries的配置效果遠差於nconnect。建議5.3及以上核心作業系統使用nconnect參數進行調節。
適用情境
單ECS上多並發I/O讀寫，且核心版本低於3.10。
操作步驟
請參見如何修改同時發起的NFS請求數量？。

為什麼使用Nginx寫日誌到檔案系統耗時很長？

背景資訊：
與Nginx日誌相關的指令有兩條。log_format用來設定日誌的格式，access_log用來指定記錄檔的存放路徑、格式的名稱和緩衝大小。
問題描述：
Nginx寫日誌到檔案系統耗時很長，寫入效能差。
問題原因：
access_log指令中的記錄檔路徑包含變數，每次寫日誌時都會重新開啟檔案，再寫入日誌，然後關閉檔案。NAS為了保證資料的可見度，會在關閉檔案時將資料寫回服務端，效能消耗較大。
解決方案：
- 方案一：刪除access_log指令中的變數，使用固定路徑儲存記錄檔。
- 方案二：使用open_log_file_cache指令設定經常被使用的記錄檔描述符緩衝，提高包含變數的記錄檔存放路徑的效能。具體配置，請參見open_log_file_cache。
  建議配置：
```
open_log_file_cache max=1000 inactive=1m valid=3m min_uses=2;
```

為什麼SMB協議檔案系統執行IO操作會延遲？

問題描述：
通過掛載點直接存取SMB協議檔案系統，在執行IO操作會有幾分鐘的等待時間。
問題原因：
- 安裝了NFS用戶端，實際業務不使用，產生等待時間。
- 啟用了WebClient服務，導致Internet檔案伺服器登入SMB協議檔案系統失敗。
- 註冊表配置項中包含了NFS許可權Nfsnp，導致開啟檔案失敗。
解決方案：
1. 首次訪問SMB檔案系統時，請ping掛載點，查看計算節點和檔案系統連通性，以及時延是否在正常範圍。
  - 如果執行ping命令失敗，請檢查您的網路設定，確保網路連接正常。
  - 如果延時較長，請ping掛載IP。當ping IP比ping DNS延時小很多，判斷可能是DNS問題，請檢查您的DNS伺服器配置。
2. 如果已安裝NFS用戶端，且用不到NFS服務，請刪除NFS用戶端。
3. 禁用WebClient服務。
4. 查看註冊表配置項HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder，如果註冊值包含Nfsnp，請刪除Nfsnp，然後重啟執行個體。

說明

您可以使用fio工具，查看效能指標是否異常。

fio.exe --name=./iotest1 --direct=1 --rwmixread=0 --rw=write --bs=4K --numjobs=1 --thread --iodepth=128 --runtime=300 --group_reporting --size=5G --verify=md5 --randrepeat=0 --norandommap --refill_buffers --filename=\\<mount point dns>\myshare\testfio1

建議您使用巨量資料塊進行IO讀寫操作，如果資料區塊較小，會消耗更多的網路資源。如果不能修改資料區塊大小，可以通過構造BufferedOutputStream，將具有指定緩衝區大小的資料寫入。

為什麼Windows server SMB協議IO操作會延遲？

問題原因：
Windows SMB用戶端預設不開啟large mtu選項，因此影響IO效能的提升。
解決方案：
您可以通過修改註冊表配置項來開啟large mtu選項，註冊表路徑：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters
在該路徑下，增加DWORD類型的鍵，命名為DisableLargeMtu，設定其值為0，重啟後才會生效。

如何提升IIS訪問NAS的效能？

問題原因：
IIS採用NAS Share的方式訪問NAS，在訪問一個檔案時，IIS後台會多次訪問NAS。不同於訪問本地檔案系統，每次訪問NAS至少要有一次網路互動，雖然每次訪問的時間長度很短，但是多次訪問時間長度疊加可能會造成用戶端響應總時間較長。
解決方案：
1. 請您使用SMB重新導向器組件，進行最佳化。具體操作，請參見SMB2 Client Redirector Caches Explained。
  其中，註冊表路徑為HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters。請將如下三個配置項調至600及以上。
  - FileInfoCacheLifetime
  - FileNotFoundCacheLifetime
  - DirectoryCacheLifetime
  說明
  如果三個註冊表配置項都不存在：
  1. 請確認使用的是SMB檔案系統。
  2. 確認Windows版本是否支援這三個登錄機碼配置項。如果Windows版本支援而註冊表配置項不存在，請手動建立。具體操作，請參見Performance tuning for file servers。
2. 建議把IIS訪問頻繁的JS/CSS等網頁程式相關的內容存放在本地。

如果當前IIS讀寫效能無法滿足您的業務需求，請聯絡NAS支援人員進行諮詢。

為什麼執行ls命令時，有卡頓或者無響應？

問題現象
在執行目錄遍曆的操作中出現卡頓或無響應。例如，執行ls命令、包含萬用字元*?的操作、執行rm -rf命令及getdents系統調用等。
原因分析
- 執行目錄遍曆操作時，如果此目錄同時正在被修改（如建立、刪除、重新命名檔案），目錄遍曆會由於緩衝頻繁失效而響應非常慢。
- 對大目錄執行目錄遍曆操作時，目錄遍曆會由於緩衝淘汰而響應非常慢。
解決方案
- 避免目錄體量過大，控制單目錄下檔案數量小於1萬個。
- 執行目錄遍曆操作時，不要頻繁對目錄進行修改。
- 執行目錄遍曆操作時，如果目標目錄體量較大（包含大於1萬個檔案），且不需要頻繁修改目錄，您可以通過NFSv3掛載，並添加nordirplus參數，該措施能在一定程度上提速，請您驗證後使用。更多資訊，請參見掛載參數。

如何提升Linux 5.4及以上版本核心的NFS順序讀取效能？

NFS read_ahead_kb參數定義了Linux核心在順序讀取操作期間要提前讀取或預取的資料大小（以KB為單位）。

對於5.4.* 之前的Linux核心版本，read_ahead_kb參數的值是通過NFS_MAX_READAHEAD乘以rsize（在掛載選項中設定的用戶端讀取資料大小）的值來設定的。從Linux核心版本5.4.*開始，NFS用戶端使用預設的read_ahead_kb值128 KB。因此建議使用推薦的掛載選項時，read_ahead_kb參數的值增加到15 MB。

掛載檔案系統後，可以使用以下命令重設read_ahead_kb參數值。其中，nas-mount-point請替換為掛載檔案系統的本地路徑；read-ahead-kb請替換為所需的讀取或預取的資料大小（以KB為單位）。

device_number=$(stat -c '%d' nas-mount-point)
((major = ($device_number & 0xFFF00) >> 8))
((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00)))
sudo bash -c "echo read-ahead-kb > /sys/class/bdi/$major:$minor/read_ahead_kb"

以下命令以掛載檔案系統的本地路徑為/mnt為例，將read_ahead_kb的讀取或預取資料大小設定為15 MB。

device_number=$(stat -c '%d' /mnt)
((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"