針對 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 8.1 和 Windows Server 2012 R2 的考慮

針對需要大量 I/O 的工作負載存取 Azure 檔案共用時，執行 Windows 8.1 或 Windows Server 2012 R2 的用戶端可能會看到高於預期的延遲。 請確定已安裝 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

注意事項

Azure Marketplace 中的 Windows Server 2012 R2 映像預設會安裝 Hotfix KB3114025，從 2015 年 12 月開始。

您的工作負載正在進行節流

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

若要瞭解標準和進階檔案共用的限制，請參閱 檔案共用和檔案擴展目標。 視您的工作負載而定，通常可以藉由從標準移至進階 Azure 檔案共用來避免節流。

若要深入瞭解共用層級或記憶體帳戶層級的節流如何導致高延遲、低輸送量和一般效能問題，請參閱 Share 或記憶體帳戶正在進行節流。

高延遲、低輸送量或低 IOPS

原因 1：正在節流共用或記憶體帳戶

若要確認您的共享或記憶體帳戶是否受到節流，您可以在入口網站中存取和使用 Azure 計量。 您也可以建立警示，以在共用受到節流或即將節流時通知您。 請參閱建立警示 Azure 檔案儲存體 疑難解答。

重要事項

針對已啟用 LFS) (大型檔案共用的標準記憶體帳戶，會在帳戶層級進行節流。 對於未啟用 LFS 的進階檔案共享和標準檔案共用，會在共用層級進行節流。

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

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

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

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

  5. 新增 回應類型的篩選，然後檢查是否有任何要求已節流。

    對於未啟用大型檔案共享的標準檔案共用，如果要求在共用層級進行節流，則會記錄下列回應類型：

    • SuccessWithThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareIopsThrottlingError

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

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

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

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

    如果已使用 Kerberos 驗證節流要求，您可能會看到表示驗證通訊協定的前置詞，例如：

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

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

    顯示 [回應類型] 屬性篩選的螢幕快照。

解決方案

原因 2：元數據或命名空間繁重的工作負載

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

若要判斷大部分的要求是否以元數據為中心，請先遵循先前在原因 1 中所述的步驟 1-4。 針對步驟 5，請新增 API 名稱的屬性篩選，而不是新增回應類型的篩選。

顯示 [API 名稱] 屬性篩選器的螢幕快照。

因應措施

  • 檢查應用程式是否可以修改以減少元數據作業的數目。

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

  • 在檔案共用上新增虛擬硬碟 (VHD) ，並從用戶端掛接 VHD，以對數據執行檔案作業。 這種方法適用於單一寫入器/讀取器案例或具有多個讀取器且沒有寫入器的案例。 因為文件系統是由用戶端所擁有，而不是 Azure 檔案儲存體，所以這可讓元數據作業成為本機。 安裝程式提供的效能類似於本機直接連結記憶體的效能。 不過，因為數據位於 VHD 中，所以無法透過 SMB 掛接以外的任何其他方式來存取，例如 REST API 或透過 Azure 入口網站。

    1. 從需要存取 Azure 檔案共用的電腦上，使用記憶體帳戶密鑰掛接檔案共用，並將它對應至可用的網路驅動器機 (例如 Z：) 。
    2. 移至 [ 磁碟管理] ，然後選取 [動作 > 建立 VHD]。
    3. 將 [位置 ] 設定為 Azure 檔案共用所對應的網路驅動器機、視需要設定 [虛擬硬碟大小 ]，然後選取 [ 固定大小]。
    4. 選取 [確定]。 VHD 建立完成後，它會自動掛接，並會出現新的未配置磁碟。
    5. 以滑鼠右鍵按下新的未知磁碟，然後選取 [初始化磁碟]。
    6. 以滑鼠右鍵按鍵按鍵單擊未設定的區域，然後建立 新的簡單磁碟區。
    7. 您應該會在磁 碟管理 中看到新的驅動器號，代表這個具有讀取/寫入存取權的 VHD (例如 E：) 。 在 檔案總管 中，您應該會在對應的 Azure 檔案共用網路驅動器機上看到新的 VHD (Z：在此範例中) 。 為了清楚起步，應該存在兩個驅動器號：Z： 上的標準 Azure 檔案共用網路對應，以及 E： 磁碟驅動器上的 VHD 對應。
    8. 針對 VHD 對應磁碟驅動器上的檔案， (E：) 與 Azure 檔案共用對應磁碟驅動器 (Z：) ，應該會有更好的效能。 如有需要，應該可以將對應的網路驅動器機中斷連線 (Z：) ，並且仍然存取掛接的 VHD 磁碟驅動器 (E：) 。
    • 若要在 Windows 用戶端上掛接 VHD，您也可以使用 Mount-DiskImage PowerShell Cmdlet。
    • 若要在Linux上掛接 VHD，請參閱Linux發行版的檔。 以下是範例。

原因 3：單個線程應用程式

如果您使用的應用程式是單個線程，則此設定可能會導致 IOPS 輸送量大幅低於可能的最大輸送量，視您布建的共用大小而定。

解決方案

  • 藉由增加線程數目來增加應用程式平行處理原則。
  • 切換至可行平行處理原則的應用程式。 例如，針對複製作業，您可以從 Windows 用戶端使用 AzCopy 或 RoboCopy，或使用 Linux 用戶端的 平行 命令。

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

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

解決方案

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

原因 5：只 (NFS 的預先讀取大小太小)

從 Linux 核心 5.4 版開始，Linux NFS 用戶端會使用預設 read_ahead_kb 值 128 kibibytes (KiB) 。 這個小值可能會減少大型檔案的讀取輸送量。

解決方案

建議您 (MiB) 將核心參數值增加到 read_ahead_kb 15 MB。 若要變更此值，請在 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 取得的最大輸送量是由單一核心所系結。

因應措施

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 MiB 作為 I/O 大小，以獲得最佳效能。

在 Windows 中從 Azure 檔案儲存體 複製檔案的速度緩慢

  • 如果您知道要使用寫入擴充的檔案最終大小，而且當檔案上未寫入的結尾包含零時，您的軟體沒有相容性問題，則請事先設定檔案大小，而不是讓每次寫入成為擴充寫入。

  • 使用正確的複製方法：

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

過多的 DirectoryOpen/DirectoryClose 呼叫

原因

如果 DirectoryOpen/DirectoryClose 呼叫數目是 API 呼叫最常用的數目，而且您不預期用戶端會進行太多呼叫，則問題可能是因為 Azure 用戶端 VM 上安裝的防病毒軟體所造成。

因應措施

適用於 Windows 的 4 月平臺更新中提供此問題的修正。

未觸發SMB多重通道

原因

最近對SMB多重通道組態設定所做的變更，但不需重新掛接。

解決方案

  • 對 Windows SMB 用戶端或帳戶 SMB 多重通道組態設定進行任何變更之後，您必須卸除共用、等候 60 秒，然後重新掛接共用以觸發多重通道。
  • 針對 Windows 用戶端 OS，產生具有高佇列深度的 IO 負載，例如 QD=8，例如複製檔案以觸發 SMB 多重通道。 針對伺服器OS，SMB多重通道會使用QD=1觸發，這表示您一啟動共用的任何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 並重新啟動 W3WP 程式，將 IIS 背景工作進程 (W3WP) 輪詢間隔更新為 0。 若要瞭解此設定，請參閱 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 community 支援。 您也可以將產品意見反應提交給 Azure 意應見反社群。