本文介紹NAS SMB/NFS協議檔案系統效能相關的常見問題及解決方案。
NAS的效能與儲存容量之間的關係是什嗎？
NAS的效能與目錄大小之間的關係是什麼？
在執行目錄遍曆操作時，以下情況可能導致響應速度變慢：
目錄正在被修改：例如，建立、刪除或重新命名檔案時，緩衝可能頻繁失效。
目錄體量過大：對大目錄執行目錄遍曆操作時，由於緩衝淘汰導致響應非常慢。
解決方案：
避免目錄體量過大，控制單目錄下檔案數量小於1萬個。
執行目錄遍曆操作時，不要頻繁對目錄進行修改。
對於大目錄遍曆，若不需頻繁修改，可考慮使用NFS v3協議掛載並添加nordirplus參數，以提升效率，請您驗證後使用。
掛載參數對NAS效能有什麼影響？
掛載參數對NAS效能有顯著的影響，以下是掛載參數對效能的具體影響：
rsize 和 wsize：
影響：這兩個參數定義了用戶端與伺服器之間資料交換的塊大小。較大的塊大小可以減少網路請求的次數，進而提高輸送量，特別是在處理大檔案時。
建議值：1048576（1 MB）。建議您儘可能使用最大值。較小的塊大小可能導致更多的網路開銷，從而降低效能。
hard：
影響：啟用該選項後，如果Apsara File Storage NAS不可用，用戶端會不斷重試請求，直到檔案系統恢複。這確保了資料的完整性和一致性。
建議：啟用。該參數有助於避免資料丟失，但可能導致應用程式暫時掛起。因此，適用於對可用性要求較高的情境。
timeo：
影響：這個參數定義了用戶端在重試之前的等待回應時間。設定過短的逾時可能會導致頻繁請求重試，從而降低效能，尤其是在網路不穩定的情況下。
建議值：600（60秒）。以確保網路有足夠的時間恢複，從而減少重試次數。
retrans：
影響：該參數定義了NFS用戶端在請求失敗後重試的次數。更高的重試次數可以增加成功請求的可能性，但也可能導致延遲。
建議值：2。平衡效能與資料可靠性。
noresvport：
影響：啟用該選項後，網路重連時將使用新的TCP連接埠，從而確保在網路故障恢複期間不會中斷串連。以提高網路的可靠性。
建議：啟用。該參數保障網路連接的穩定性。
不建議使用soft選項，有資料一致性風險。如果您要使用soft選項，相關風險需由您自行承擔。
避免設定不同於預設值的任何其他掛載選項。如果更改讀或寫緩衝區大小或禁用屬性緩衝，可能會導致效能下降。
Elastic Compute Service執行個體的頻寬對NAS效能有何限制？
輸送量最大不會超過ECS內網頻寬，如果內網頻寬太小，則輸送量會受到流量控制。
讀寫吞吐超過閾值會有什麼影響？
如果您或應用程式發出的請求輸送量超過閾值時，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。
操作步驟
為什麼使用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，導致開啟檔案失敗。
解決方案：
首次訪問SMB檔案系統時，請ping掛載點，查看計算節點和檔案系統連通性，以及時延是否在正常範圍。
如果執行ping命令失敗，請檢查您的網路設定，確保網路連接正常。
如果延時較長，請ping掛載IP。當ping IP比ping DNS延時小很多，判斷可能是DNS問題，請檢查您的DNS伺服器配置。
如果已安裝NFS用戶端，且用不到NFS服務，請刪除NFS用戶端。
禁用WebClient服務。
查看註冊表配置項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至少要有一次網路互動，雖然每次訪問的時間長度很短，但是多次訪問時間長度疊加可能會造成用戶端響應總時間較長。
解決方案：
請您使用SMB重新導向器組件，進行最佳化。具體操作，請參見SMB2 Client Redirector Caches Explained。
其中，註冊表路徑為HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters。請將如下三個配置項調至600及以上。
FileInfoCacheLifetime
FileNotFoundCacheLifetime
DirectoryCacheLifetime
說明如果三個註冊表配置項都不存在：
請確認使用的是SMB檔案系統。
確認Windows版本是否支援這三個登錄機碼配置項。如果Windows版本支援而註冊表配置項不存在，請手動建立。具體操作，請參見Performance tuning for file servers。
建議把IIS訪問頻繁的JS/CSS等網頁程式相關的內容存放在本地。
如果當前IIS讀寫效能無法滿足您的業務需求，請提交工單處理。
為什麼執行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"