針對 Azure 檔案儲存體效能問題進行疑難排解

注意

本文所參考的 CentOS 是一種 Linux 發行版，且將到達生命周期結束（EOL）。 請根據您的使用方式進行規劃。 如需詳細資訊，請參閱 CentOS 生命週期結束指引。

本文列出與 Azure 檔案共用效能相關的常見問題，並提供潛在原因和因應措施。 若要充分利用此疑難排解指南，建議您先閱讀了解 Azure 檔案儲存體的效能。

適用於

檔案共用類型	SMB	NFS
標準檔案共用 (GPv2)、LRS/ZRS
標準檔案共用 (GPv2)、GRS/GZRS
進階檔案共用 (FileStorage)、LRS/ZRS

一般效能疑難排解

首先，排除您可能遇到效能問題的一些常見原因。

您執行舊版作業系統

如果您的用戶端虛擬機器 (VM) 執行 Windows 8.1 或 Windows Server 2012 R2，或舊版 Linux 發行版本或核心，則存取 Azure 檔案共用時可能會遇到效能問題。 請升級您的用戶端 OS 或套用下列修正程式。

Windows 作業系統

Windows 8.1 和 Windows Server 2012 R2 的考量

執行 Windows 8.1 或 Windows Server 2012 R2 的用戶端，在存取 Azure 檔案共用進行 I/O 密集型工作負載時，可能會看到高於預期的延遲。 請確定已安裝 KB3114025 Hotfix。 此 Hotfix 可改善建立和關閉控制代碼的效能。

您可以執行下列指令碼來檢查是否已安裝此 Hotfix：

reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies

如果已安裝此 Hotfix，則會顯示下列輸出︰

HKEY_Local_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies {96c345ef-3cac-477b-8fcd-bea1a564241c} REG_DWORD 0x1

注意

自 2015 年 12 月起，Azure Marketplace 中的 Windows Server 2012 R2 映像預設已安裝 Hotfix KB3114025。

Linux

CentOS Linux 或 RHEL 上的 IOPS 偏低

原因

舊版 CentOS Linux 或 RHEL 不支援大於 1 的 I/O 深度。

因應措施

• 請升級至 CentOS Linux 8.6+ 或 RHEL 8.6+。
• 變更為 Ubuntu。
• 對於其他 Linux VM，請將核心升級至 5.0 或更新版本。

工作負載正在進行節流

在達到檔案共用的每秒 I/O 作業 (IOPS)、輸入或輸出限制時，就會對要求進行節流。 例如，如果客戶端超過基準 IOPS，Azure 檔案儲存體服務就會對客戶端進行節流。 節流可能會導致用戶端效能不佳。

若要了解標準和進階檔案共用的限制，請參閱檔案共用和檔案調整目標。 根據您的工作負載，通常可藉由從標準切換至高級 Azure 檔案共享來避免節流。

若要深入了解共用層級或儲存體帳戶層級的節流如何造成高延遲、低輸送量和一般效能問題，請參閱共用或儲存體帳戶正在進行節流。

高延遲、低輸送量或低 IOPS

原因 1：分享或儲存體帳戶正在受到限制

若要確認您的共用或儲存體帳戶是否正在進行節流，您可以在入口網站中存取和使用 Azure 計量。 您也可以建立警示，當分享的資源被限制或即將被限制時通知您。 請參閱藉由建立警示對 Azure 檔案儲存體進行疑難排解。

重要

針對標準記憶體帳戶，節流會在記憶體帳戶層級進行。 針對進階檔案共享，節流會在共用層級進行。

1. 在 Azure 入口網站中，移至您的儲存體帳戶。

2. 在左窗格的 [監視] 底下，選取 [計量]。

3. 選取 [檔案] 作為儲存體帳戶範圍的計量命名空間。

4. 選取 [交易] 作為計量。

5. 新增 [回應類型] 的篩選器，然後確認是否已對任何要求進行節流。

   針對標準檔案共用，如果要求在用戶端帳戶層級進行節流，則會記錄下列回應類型：

   • 客戶帳號請求限流錯誤
   • 用戶帳號頻寬限制錯誤

   對於高級檔案共用，如果在共用層級對要求進行節流，會記錄下列回應類型：

   • SuccessWithShareEgressThrottling
   • 使用共享入口流量限制成功
   • 共享IOPS限制成功
   • ClientShareEgressThrottlingError
   • 客戶共享入口節流錯誤 (ClientShareIngressThrottlingError)
   • 客戶共享Iops限制錯誤

   如果節流要求已使用 Kerberos 進行驗證，您可能會看到一個指出驗證通訊協定的前置詞，例如：

   • Kerberos成功與共享出口節流
   • Kerberos成功共享入口限制

   若要深入了解每個回應類型，請參閱計量維度。

   

解決方案

如果您使用進階檔案共用，請增加佈建的檔案共用大小，以提高 IOPS 限制。 若要深入了解，請參閱了解進階檔案共用的佈建。

原因 2：中繼資料或命名空間的工作負載過重

如果您大部分的要求都是以中繼資料為中心 (例如 createfile、openfile、closefile、queryinfo 或 querydirectory)，延遲會比讀取/寫入作業還嚴重。

若要確認您的要求是否大多以中繼資料為中心，請先依照先前在原因 1 中列出的步驟 1-4 操作。 在步驟 5 中，請新增 API 名稱的屬性篩選，而不要新增回應類型的篩選。 如需詳細資訊，請參閱 依元數據 IOPS 監視使用率。

因應措施

• 查看是否可以修改應用程式，以減少中繼資料作業的數目。

• 如果您使用高階 SMB Azure 檔案共用，請使用中繼資料快取。

• 將檔案共用分成相同儲存體帳戶內的多個檔案共用。

• 在檔案共用上新增虛擬硬碟 (VHD)，並從用戶端掛接 VHD，以對資料執行檔案作業。 這種方法適用於單一寫入者/讀取者的情境，或是有多個讀取者而沒有任何寫入者的情境。 由於檔案系統由用戶端 (而非 Azure 檔案儲存體) 所擁有，因此中繼資料作業可在本機進行。 此配置提供的效能類似於本機直接連接的儲存裝置。 不過，由於資料位於 VHD 中，因此無法透過 SMB 掛接以外的任何其他方式進行存取，例如 REST API 或透過 Azure 入口網站。

  1. 在需要存取 Azure 檔案共用的機器上，使用儲存體帳戶金鑰掛接檔案共用，然後將其對應至可用的網路磁碟機 (例如 Z:)。
  2. 移至 [磁碟管理]，然後選取 [動作] > [建立 VHD]。
  3. 將 [位置] 設定為 Azure 檔案共用所對應的網路磁碟機，視需要設定 [虛擬硬碟大小]，然後選取 [固定大小]。
  4. 選擇 [確定]。 VHD 建立完成後會自動掛載，並出現新的未分配磁碟。
  5. 以滑鼠右鍵按一下新的未知磁碟，然後選取 [初始化磁碟]。
  6. 以滑鼠右鍵按一下未配置的區域，然後建立新的簡單磁碟區。
  7. 您應該會看到新的磁碟機代號出現在 [磁碟管理] 中，表示此 VHD 具有讀取/寫入存取權 (例如 E:)。 在 [檔案總管] 中，在對應的 Azure 檔案共用網路磁碟機 (在此範例中為 Z:)，您應該會看到新的 VHD。 清楚的說法是，有兩個磁碟機代號存在：對應 Z: 的標準 Azure 檔案共用網路；對應 E: 磁碟機的 VHD。
  8. 與 Azure 檔案共用對應的磁碟機 (Z:) 相比，在 VHD 對應的磁碟機 (E:) 上對檔案進行繁重的中繼資料操作應該會有更好的效能。 若有需要，應可斷開映射的網路磁碟機 (Z:) 連線，仍然可以存取掛載的 VHD 磁碟機 (E:)。
  • 若要在 Windows 用戶端上掛接 VHD，您也可以使用 Mount-DiskImage PowerShell Cmdlet。
  • 若要在 Linux 作業系統上掛載 VHD，請參閱您的 Linux 散發版相關的文件。 以下是範例。

原因 3：單一執行緒應用程式

如果您使用的應用程式是單一執行緒的，此設定可能會導致 IOPS 輸送量遠低於最大可能輸送量，視您佈建的共用大小而定。

解決方案

• 藉由增加執行緒數目來提高應用程式的平行性。
• 切換至可以平行處理的應用程式。 例如，對於複製作業，您可以從 Windows 用戶端使用 AzCopy 或 RoboCopy，或從 Linux 用戶端使用 parallel 命令。

原因 4：SMB 通道數目超過四個

如果您使用 SMB 多重通道，且通道數目超過四個，則會導致效能不佳。 若要確認您的連線計數是否超過四個，請使用 PowerShell Cmdlet get-SmbClientConfiguration 來檢視目前的連線計數設定。

解決方案

為 SMB 設定每個 NIC 的 Windows 設定，使通道總數不超過四個。 例如，如果您有兩個 NIC，您可以使用下列 PowerShell Cmdlet，將每個 NIC 的最大值設定為兩個：Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2。

原因 5：預先讀取大小太小（僅限 NFS）

從 Linux 核心 5.4 版開始，Linux NFS 用戶端會使用預設值 128 KiB（千字節）。 這個較小的值可能會減少大型檔案的讀取輸送量。

解決方案

我們建議您將 read_ahead_kb 核心參數值增加到 15 個字節（MiB）。 若要變更此值，請在 Linux 核心設備管理員 udev 中新增規則，以持續設定預先讀取大小。 執行下列步驟:

1. 在文字編輯器中，輸入並儲存下列文字，以建立 /etc/udev/rules.d/99-nfs.rules 檔案：

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. 在控制台中，執行 udevadm 命令作為超級使用者並重新載入規則檔案和其他資料庫，以套用 udev 規則。 若要讓 udev 知道新的檔案，您只需要執行此命令一次。

   sudo udevadm control --reload
   

非常高的要求延遲

原因

用戶端 VM 可能位於與檔案共用不同的區域中。 高延遲也有可能肇因於用戶端或網路所造成的延遲。

解決方案

• 從與檔案共用位於相同區域的 VM 執行應用程式。
• 針對您的儲存體帳戶，透過 Azure 入口網站中的 Azure 監視器檢閱交易計量 SuccessE2ELatency 和 SuccessServerLatency。 若 SuccessE2ELatency 與 SuccessServerLatency 計量值有很大的差異，表示延遲可能是網路或用戶端所造成的。 請參閱 Azure 檔案儲存體監視資料參考中的交易計量。

用戶端無法達到網路所支援的最大輸送量

原因

可能原因之一是缺少標準檔案共用的 SMB 多重通道支援。 Azure 檔案儲存體目前僅支援標準檔案共用的單一通道，因此只有一個從用戶端 VM 到伺服器的連線。 這個單一連線限定為用戶端 VM 上的單一核心，因此可從 VM 達到的最大輸送量會受限於單一核心。

因應措施

• 針對進階檔案共享， 啟用SMB多重通道。
• 取得具有較大核心的 VM，可能有助於提升輸送量。
• 從多個 VM 執行用戶端應用程式，會增加輸送量。
• 盡可能使用 REST API。
• 若是 NFS Azure 檔案共用，可以使用 nconnect。 請參閱使用 nconnect 改善 NFS Azure 檔案共用效能。

掛接在 Linux VM 上的 Azure 檔案共用效能緩慢

原因 1：快取

效能變慢可能的一個原因是已停用快取。 如果您要重複存取檔案，快取會相當有用。 否則，可能會產生額外負荷。 在停用之前，請檢查您是否使用快取。

原因 1 的解決方案

若要查看是否停用快取，請尋找 cache= 項目。

Cache=none 表示快取已停用。 使用預設的 mount 命令，或明確地為 mount 命令加上 cache=strict 選項以重新掛接共用，確保啟用預設的快取或「嚴格」快取模式。

在某些情況下，serverino 掛載選項可能導致 ls 命令對每個目錄項目執行 stat。 當您要列出大型目錄時，這個行為會導致效能降低。 您可以檢查 /etc/fstab 項目中的掛接選項：

//azureuser.file.core.windows.net/cifs /cifs cifs vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777

您也可以執行 sudo mount | grep cifs 命令並檢查其輸出，來檢查是否使用正確的選項。 以下是範例輸出：

//azureuser.file.core.windows.net/cifs on /cifs type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.1,file_mode=0777, dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,actimeo=1)

如果沒有 cache=strict 或 serverino 選項，請執行文件中的掛接命令，將 Azure 檔案服務卸載並再次掛接。 然後，重新檢查 /etc/fstab 項目是否有正確的選項。

原因 2：節流

您可能遭遇限流，這導致您的要求被傳送至佇列。 您可以利用 Azure 監視器中的 Azure 儲存體計量來確認這一點。 您也可以建立通知，當共用正在被限制流量或即將被限制時提醒您。 請參閱藉由建立警示對 Azure 檔案儲存體進行疑難排解。

原因 2 的解決方案

確定您的應用程式位於 Azure 檔案調整規模目標內。 如果您使用標準 Azure 檔案共用，請考慮切換至進階。

原因 3：Azure 檔案共享達到其容量上限

如果 Azure 檔案共用接近達到其容量，一個重要步驟是識別最大的檔案和目錄，以優化記憶體。 此步驟可協助您瞭解哪些檔案和資料夾使用最多的空間。

因應措施

若要全面檢視整個共享的儲存空間使用量，請掛載共用的根目錄。 此動作可讓您徹底檢查檔案和目錄大小。 在檔案共用的根目錄中，執行下列命令來識別最大的檔案和目錄：

	cd /path/to/mount/point
	du -ah --max-depth=1 | sort -rh | head -n 20

此命令會以大小遞減順序顯示 20 個最大的檔案和目錄。 此顯示提供記憶體耗用量的清楚概觀。

如果您無法掛接共用的根目錄，請使用 Azure 記憶體總管或第三方工具來分析記憶體使用量。 這些工具提供檔案和目錄大小的類似資訊，而不需要您掛載共享資源。

Linux 用戶端上的輸送量低於 Windows 用戶端的輸送量

原因

這是會影響在Linux上實作SMB用戶端的已知問題。

因應措施

• 將負載分散到多個 VM。
• 在相同的 VM 上，使用具有 nosharesock 選項的多個裝入點，並將負載分散到這些裝入點。
• 在 Linux 上，請嘗試使用 nostrictsync 選項進行掛接，以避免在每個 fsync 呼叫上強制 SMB 排清。 針對 Azure 檔案服務，此選項不會干擾數據一致性，但可能會導致目錄清單 （ls -l 命令） 上的過時檔案元數據。 使用 stat 命令直接查詢檔案元數據會傳回最多 up-to日期檔案元數據。

涉及大量開啟/關閉作業的中繼資料密集的工作負載延遲偏高

原因

缺少目錄租用的支援。

因應措施

• 可能的話，請避免在短時間內於相同目錄中使用過多的開啟/關閉控制代碼。
• 對於 Linux VM，請指定 actimeo=<sec> 作為掛接選項，以增加目錄項目快取逾時。 預設的逾時為 1 秒，因此較大的值 (例如 30 秒) 可能會有幫助。
• 對於 CentOS Linux 或 Red Hat Enterprise Linux (RHEL) VM，請將系統升級至 CentOS Linux 8.2 或 RHEL 8.2。 若是其他的 Linux 發行版本，請將核心升級至 5.0 或更新版本。

列舉檔案和資料夾的速度太慢

如果用戶端計算機上沒有足夠的快取或記憶體供大型目錄使用，就可能發生此問題。

Windows 作業系統

若要解決此問題，請調整 DirectoryCacheEntrySizeMax 登錄值，以允許在用戶端機器快取較大型的目錄清單：

• 位置：HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
• 值名稱：DirectoryCacheEntrySizeMax
• 值類型︰DWORD

例如，您可以設定為 0x100000，查看效能是否改善。

Linux

可用的記憶體數量會影響系統擁有的 inode 哈希值區數目，這會影響並改善大型目錄的列舉效能。 您可以修改系統中的 inode 哈希桶數量，以減少大型列舉工作負載期間可能發生的哈希衝突。 如需說明，請參閱 增加哈希桶的數量。

進出 Azure 檔案共用的檔案複製速度緩慢

當您嘗試將檔案傳輸至 Azure 檔案服務時，可能會看到效能變慢。 如果您沒有特定的 I/O 大小需求下限，建議您使用 1 MB 的 I/O 大小以獲得最佳效能。

Windows 作業系統

在 Windows 中將檔案複製到 Azure 檔案或從中複製檔案時速度緩慢

• 如果您知道擴充寫入檔案的最終大小，而且當檔案上未寫入的結尾中有零時您的軟體不會產生相容性問題，則請事先設定檔案大小，而不是將每次寫入設為擴充寫入。

• 使用正確的複製方法：

  • 使用 AzCopy 進行兩個檔案共用之間的任何傳輸。
  • 在內部部署的電腦上，於檔案共用之間使用Robocopy。

Linux

在 Linux 中對 Azure 文件儲存體進行檔案複製或從中複製檔案的速度緩慢。

• 使用正確的複製方法：

  • 使用 AzCopy 進行兩個檔案共用之間的任何傳輸。
  • 搭配平行使用 cp 或 dd 可改善複製速度。 線程數目取決於您的使用案例和工作負載。 下列範例使用六個：
    • cp 範例 (cp 將使用檔案系統的預設區塊大小作為區塊大小)：find * -type f | parallel --will-cite -j 6 cp {} /mntpremium/ &。
    • dd 範例 (此命令會將區塊大小明確設定為 1 MiB)：find * -type f | parallel --will-cite-j 6 dd if={} of=/mnt/share/{} bs=1M
  • 開放原始碼的協力廠商工具，例如：- GNU Parallel。 - Fpart - 排序檔案，並將其封裝到磁碟分割中。 - Fpsync - 使用 Fpart 和複製工具來產生多個執行個體，以將資料從 src_dir 遷移至 dst_url。 - 多重 - 多執行緒的 cp 和 md5sum (以 GNU coreutils 為基礎)。

• 若事先設定檔案大小，而不是將每次寫入作為擴充寫入，則可在已知檔案大小的情況下，協助改善複製速度。 如果需要避免擴充寫入，您可以使用 truncate --size <size> <file> 命令來設定目的地檔案大小。 之後，dd if=<source> of=<target> bs=1M conv=notrunc 命令會複製原始程式檔，而不需要重複更新目標檔案的大小。 例如，您可以設定您要複製之每個檔案的目標檔案大小（假設共享掛載在/mnt/share 底下）：

  for i in `` find * -type f``; do truncate --size ``stat -c%s $i`` /mnt/share/$i; done

  然後，在不以平行方式擴充寫入的情況下複製檔案。

  find * -type f | parallel -j6 dd if={} of =/mnt/share/{} bs=1M conv=notrunc

過多的 DirectoryOpen/DirectoryClose 呼叫

原因

如果 DirectoryOpen/DirectoryClose 呼叫屬於最頻繁的 API 呼叫，而您未預期用戶端會進行那麼多呼叫，問題可能是由安裝在 Azure 用戶端 VM 上的防毒軟體所引起的。

因應措施

Windows 四月平台更新提供了此問題的修正程式。

SMB 多重通道未被觸發

原因

近期對 SMB 多重通道組態設定進行了變更，但未重新掛接。

解決方案

• 對 Windows SMB 用戶端或帳戶 SMB 多重通道組態設定進行任何變更之後，必須取消掛接共用、等候 60 秒，然後重新掛接共用以觸發多重通道。
• 針對 Windows 用戶端作業系統，產生具有高佇列深度 (例如 QD=8) 的 IO 負載，例如，複製檔案以觸發 SMB 多重通道。 針對伺服器作業系統，會使用 QD=1 觸發 SMB 多重通道，這表示會在您對共用啟動任何 IO 後隨即觸發。

解壓縮檔案時效能變慢

根據所使用的確切壓縮方法和解壓縮作業，在 Azure 檔案共用上執行解壓縮作業的速度，可能會比在本機磁碟上慢。 這通常是因為，在對壓縮的封存執行解壓縮的過程中，解壓縮工具會執行許多中繼資料作業。 為了達到最佳效能，建議您將壓縮的封存從 Azure 檔案共用複製到本機磁碟，並在該處解壓縮，然後使用 Robocopy 或 AzCopy 之類的複製工具複製回 Azure 檔案共用。 使用 Robocopy 之類的複製工具，可以使用多個執行緒來平行複製資料，以彌補 Azure 檔案儲存體的中繼資料作業效能相對低於本機磁碟的情況。

託管於檔案共用上的網站延遲過高

原因

檔案共用上的大量檔案變更通知可能會導致高延遲。 這通常發生在裝載在具有深層巢狀目錄結構的檔案共用上的網站。 典型的案例是 IIS 裝載的 Web 應用程式，其中的預設組態是針對每個目錄設定檔案變更通知。 已註冊用戶端的共用上進行的每項變更 (ReadDirectoryChangesW)，都會將變更通知從檔案服務推送至用戶端，而這會佔用系統資源，並且使問題隨著變更的數目而更加嚴重。 這可能會導致共用節流，而致使用戶端延遲升高。

若要確認，您可以在入口網站中使用 Azure 計量。

1. 在 Azure 入口網站中，移至您的儲存體帳戶。
2. 在左側功能表的 [監視] 下方，選取 [計量]。
3. 選取 [檔案] 作為儲存體帳戶範圍的計量命名空間。
4. 選取 [交易] 作為計量。
5. 新增篩選條件以過濾 ResponseType，並檢查是否有任何要求具有 SuccessWithThrottling 或 ClientThrottlingError 的回應碼。

解決方案

• 若未使用檔案變更通知，請停用檔案變更通知 (慣用)。

  • 藉由更新 FCNMode 來停用檔案變更通知。
  • 在登錄中設定 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds，以將 IIS 背景工作處理序 (W3WP) 輪詢間隔更新為 0，然後重新啟動 W3WP 程序。 若要了解此設定，請參閱 IIS 的許多部分使用的通用登錄機碼。

• 增加檔案變更通知輪詢間隔的頻率，以減少負荷。

  根據您的需求，將 W3WP 背景工作進程輪詢間隔更新為較高的值（例如 10 或 30 分鐘）。 在您的登錄中設定 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds，然後重新啟動 W3WP 程式。

• 如果您的網站的對應實體目錄具有巢狀目錄結構，您可以嘗試限制檔案變更通知的範圍，以減少通知量。 根據預設，IIS 會使用 Web.config 檔案的組態，這些檔案位於虛擬目錄所對應的實體目錄中，以及該實體目錄的任何子目錄中。 如果您不想在子目錄中使用 Web.config 檔案，請在虛擬目錄上的 false 屬性指定 allowSubDirConfig。 在 這裡可以找到更多詳細資訊。

  將 Web.ConfigallowSubDirConfigIIS 虛擬目錄設定設定為 false ，以從範圍中排除對應的實體子目錄。

另請參閱

• 針對 Azure 檔案進行疑難排解
• 藉由建立警示對 Azure 檔案儲存體進行疑難排解
• 了解 Azure 檔案儲存體的效能
• Microsoft Azure 中的警示概觀
• Azure 檔案儲存體常見問題集

與我們連絡，以取得說明

如果您有疑問，可以詢問 Azure 社群支援。 您也可以向 Azure 意見反應社群提交產品意見反應。