針對 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. 新增 [回應類型] 的篩選器，然後確認是否已對任何要求進行節流。

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

   • ClientAccountRequestThrottlingError
   • ClientAccountBandwidthThrottlingError

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

   • SuccessWithShareEgressThrottling
   • SuccessWithShareIngressThrottling
   • SuccessWithShareIopsThrottling
   • ClientShareEgressThrottlingError
   • ClientShareIngressThrottlingError
   • ClientShareIopsThrottlingError

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

   • KerberosSuccessWithShareEgressThrottling
   • KerberosSuccessWithShareIngressThrottling

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

   

解決方案

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

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

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

若要確認您的要求是否大多以中繼資料為中心，請先依照先前在原因 1 中列出的步驟 1-4 操作。 在步驟 5 中，請新增 API 名稱的屬性篩選，而不要新增回應類型的篩選。

因應措施

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

• 如果您使用進階 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 用戶端會使用預設值 read_ahead_kb 128 kibibytes （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 表示快取已停用。 使用預設掛接命令重新掛接共用，或明確將 選項新增 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 檔案共用，請考慮切換至進階。

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

原因

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

因應措施

• 將負載分散到多個 VM。
• 在相同的 VM 上，使用多個掛接點搭配 nosharesock 選項，並將負載分散到這些掛接點上。
• 在 Linux 上，請嘗試以 nostrictsync 選項掛接，以避免在每次呼叫 fsync 時都強制執行 SMB 排清。 對於 Azure 檔案儲存體，此選項並不會干擾資料一致性，但可能會導致目錄清單 (ls -l 命令) 中出現過時的檔案中繼資料。 使用 stat 命令直接查詢檔案中繼資料，將會傳回最新的檔案中繼資料。

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

原因

缺少目錄租用的支援。

因應措施

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

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

原因

如果用戶端機器上沒有足夠的快取可供大型目錄使用，就會發生此問題。

解決方案

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

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

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

進出 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 平行。 - 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 的篩選條件，並檢查是否有任何要求具有 （適用於 SMB 或 NFS） 或 ClientThrottlingError （針對 REST） 的回應碼SuccessWithThrottling。

解決方案

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

  • 藉由更新 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 檔案，請針對allowSubDirConfig虛擬目錄上的 屬性指定 false 。 在 這裡可以找到更多詳細資訊。

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

另請參閱

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

與我們連絡，以取得說明

如果您有問題或需要相關協助，請建立支援要求，或詢問 Azure community 支援。 您也可以向 Azure 意見反應社群提交產品意見反應。