Behandeln von Azure Files Leistungsproblemen

  • Artikel

Hinweis

CentOS, auf das in diesem Artikel verwiesen wird, ist eine Linux-Distribution und erreicht das Ende der Lebensdauer (End Of Life, EOL). Berücksichtigen Sie Ihre Verwendung, und planen Sie sie entsprechend. Weitere Informationen finden Sie unter Leitfaden zum Ende der Lebensdauer von CentOS.

Dieser Artikel listet häufige Probleme im Zusammenhang mit der Leistung von Azure-Dateifreigaben auf und enthält mögliche Ursachen und Problemumgehungen. Um den größtmöglichen Nutzen aus diesem Leitfaden zur Problembehandlung zu erhalten, empfiehlt es sich, zunächst grundlegendes Azure Files Leistung zu lesen.

Gilt für

Dateifreigabetyp SMB NFS
Standarddateifreigaben (GPv2), LRS/ZRS
Standarddateifreigaben (GPv2), GRS/GZRS
Premium-Dateifreigaben (FileStorage), LRS/ZRS

Allgemeine Leistungsproblembehandlung

Schließen Sie zunächst einige häufige Gründe für Leistungsprobleme aus.

Sie verwenden ein altes Betriebssystem

Wenn Auf Ihrem virtuellen Clientcomputer (VM) Windows 8.1 oder Windows Server 2012 R2 oder eine ältere Linux-Distribution oder ein älteren Linux-Kernel ausgeführt wird, können beim Zugriff auf Azure-Dateifreigaben Leistungsprobleme auftreten. Aktualisieren Sie entweder Ihr Clientbetriebssystem, oder wenden Sie die unten angegebenen Korrekturen an.

Überlegungen zu Windows 8.1 und Windows Server 2012 R2

Bei Clients, auf denen Windows 8.1 oder Windows Server 2012 R2 ausgeführt wird, kann beim Zugriff auf Azure-Dateifreigaben für E/A-intensive Workloads eine höhere Latenz als erwartet auftreten. Stellen Sie sicher, dass der KB3114025 Hotfix installiert ist. Dieser Hotfix verbessert die Leistung von Handles zum Erstellen und Schließen.

Sie können das folgende Skript ausführen, um zu überprüfen, ob der Hotfix installiert wurde:

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

Wenn der Hotfix installiert ist, wird die folgende Ausgabe angezeigt:

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

Hinweis

Windows Server 2012 R2-Images in Azure Marketplace ab Dezember 2015 standardmäßig hotfix KB3114025 installiert.

Ihre Workload wird gedrosselt.

Anforderungen werden gedrosselt, wenn die E/A-Vorgänge pro Sekunde (IOPS), eingangs- oder ausgangsgrenzwerte für eine Dateifreigabe erreicht werden. Wenn der Client beispielsweise die Baseline-IOPS überschreitet, wird er vom Azure Files-Dienst gedrosselt. Eine Drosselung kann dazu führen, dass die Leistung des Clients beeinträchtigt wird.

Informationen zu den Grenzwerten für Standard- und Premium-Dateifreigaben finden Sie unter Dateifreigabe- und Dateiskalierungsziele. Abhängig von Ihrer Workload kann eine Drosselung häufig vermieden werden, indem Sie von Standard- zu Premium-Azure-Dateifreigaben wechseln.

Weitere Informationen dazu, wie eine Drosselung auf Freigabe- oder Speicherkontoebene zu hohen Latenzzeiten, geringem Durchsatz und allgemeinen Leistungsproblemen führen kann, finden Sie unter Freigabe oder Speicherkonto wird gedrosselt.

Hohe Latenz, niedriger Durchsatz oder niedrige IOPS

Ursache 1: Freigabe- oder Speicherkonto wird gedrosselt

Um zu überprüfen, ob Ihre Freigabe oder Ihr Speicherkonto gedrosselt wird, können Sie im Portal auf Azure-Metriken zugreifen und diese verwenden. Sie können auch Warnungen erstellen, die Sie benachrichtigen, wenn eine Freigabe gedrosselt oder gedrosselt wird. Weitere Informationen finden Sie unter Problembehandlung bei Azure Files durch Erstellen von Warnungen.

Wichtig

Bei Standardspeicherkonten mit aktivierten großen Dateifreigaben (LFS) erfolgt die Drosselung auf Kontoebene. Bei Premium-Dateifreigaben und Standarddateifreigaben ohne aktivierte LFS erfolgt die Drosselung auf Freigabeebene.

  1. Wechseln Sie im Azure-Portal zu Ihrem Speicherkonto.

  2. Wählen Sie im linken Bereich unter Überwachung die Option Metriken aus.

  3. Wählen Sie Datei als Metriknamespace für Ihren Speicherkontobereich aus.

  4. Wählen Sie Transaktionen als Metrik aus.

  5. Fügen Sie einen Filter für den Antworttyp hinzu, und überprüfen Sie dann, ob Anforderungen gedrosselt wurden.

    Für Standarddateifreigaben, für die keine großen Dateifreigaben aktiviert sind, werden die folgenden Antworttypen protokolliert, wenn eine Anforderung auf Freigabeebene gedrosselt wird:

    • SuccessWithThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareIopsThrottlingError

    Für Standarddateifreigaben, für die große Dateifreigaben aktiviert sind, werden die folgenden Antworttypen protokolliert, wenn eine Anforderung auf Clientkontoebene gedrosselt wird:

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    Bei Premium-Dateifreigaben werden die folgenden Antworttypen protokolliert, wenn eine Anforderung auf Freigabeebene gedrosselt wird:

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

    Wenn eine gedrosselte Anforderung mit Kerberos authentifiziert wurde, wird möglicherweise ein Präfix angezeigt, das das Authentifizierungsprotokoll angibt, z. B.:

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

    Weitere Informationen zu den einzelnen Antworttypen finden Sie unter Metrikdimensionen.

    Screenshot: Eigenschaftenfilter

Lösung

Ursache 2: Hohe Metadaten- oder Namespaceauslastung

Wenn die Meisten Ihrer Anforderungen metadatenzentriert sind (z createfile. B. , openfile, closefile, queryinfooder querydirectory), ist die Latenz schlechter als bei Lese-/Schreibvorgängen.

Um zu ermitteln, ob die meisten Ihrer Anforderungen metadatenorientiert sind, führen Sie zunächst die Schritte 1 bis 4 aus, wie zuvor in Ursache 1 beschrieben. Fügen Sie in Schritt 5 anstelle eines Filters für den Antworttyp einen Eigenschaftenfilter für den API-Namen hinzu.

Screenshot: Eigenschaftenfilter

Problemumgehungen

  • Überprüfen Sie, ob die Anwendung geändert werden kann, um die Anzahl der Metadatenvorgänge zu reduzieren.

  • Trennen Sie die Dateifreigabe in mehrere Dateifreigaben innerhalb desselben Speicherkontos.

  • Fügen Sie der Dateifreigabe eine virtuelle Festplatte (VHD) hinzu, und stellen Sie die VHD vom Client bereit, um Dateivorgänge für die Daten auszuführen. Dieser Ansatz funktioniert für Szenarien mit einzelnen Writer/Lesern oder Szenarien mit mehreren Lesern und ohne Writer. Da sich das Dateisystem im Besitz des Clients und nicht Azure Files befindet, können Metadatenvorgänge auf diese Weise lokal ausgeführt werden. Das Setup bietet eine Leistung, die der leistung des lokalen direkt angefügten Speichers ähnelt. Da sich die Daten jedoch in einer VHD befindet, kann auf sie nicht über andere Wege als die SMB-Einbindung zugegriffen werden, z. B. über die REST-API oder über die Azure-Portal.

    1. Binden Sie auf dem Computer, der auf die Azure-Dateifreigabe zugreifen muss, die Dateifreigabe mithilfe des Speicherkontoschlüssels ein, und ordnen Sie sie einem verfügbaren Netzlaufwerk zu (z. B. Z:).
    2. Wechseln Sie zu Datenträgerverwaltung , und wählen Sie Aktion > VHD erstellen aus.
    3. Legen Sie Speicherort auf das Netzlaufwerk fest, dem die Azure-Dateifreigabe zugeordnet ist, legen Sie die Größe der virtuellen Festplatte nach Bedarf fest, und wählen Sie Feste Größe aus.
    4. Wählen Sie OK aus. Sobald die VHD-Erstellung abgeschlossen ist, wird sie automatisch eingebunden, und ein neuer nicht zugeordneter Datenträger wird angezeigt.
    5. Klicken Sie mit der rechten Maustaste auf den neuen unbekannten Datenträger, und wählen Sie Datenträger initialisieren aus.
    6. Klicken Sie mit der rechten Maustaste auf den nicht zugeordneten Bereich, und erstellen Sie ein neues einfaches Volume.
    7. In der Datenträgerverwaltung sollte ein neuer Laufwerkbuchstabe angezeigt werden, der diese VHD mit Lese-/Schreibzugriff darstellt (z. B. E:). In Explorer sollte die neue VHD auf dem Netzlaufwerk der zugeordneten Azure-Dateifreigabe (Z: in diesem Beispiel) angezeigt werden. Um es klar zu machen, sollten zwei Laufwerkbuchstaben vorhanden sein: die Standardmäßige Azure-Dateifreigabe-Netzwerkzuordnung auf Z: und die VHD-Zuordnung auf dem Laufwerk E: .
    8. Es sollte eine viel bessere Leistung bei umfangreichen Metadatenvorgängen für Dateien auf dem zugeordneten VHD-Laufwerk (E:) im Vergleich zum zugeordneten Azure-Dateifreigabelaufwerk (Z:) geben. Wenn gewünscht, sollte es möglich sein, das zugeordnete Netzlaufwerk (Z:) zu trennen und trotzdem auf das eingebundene VHD-Laufwerk (E:) zuzugreifen.
    • Zum Einbinden einer VHD auf einem Windows-Client können Sie auch das Mount-DiskImage PowerShell-Cmdlet verwenden.
    • Informationen zum Einbinden einer VHD unter Linux finden Sie in der Dokumentation für Ihre Linux-Distribution. Hier sehen Sie ein Beispiel.

Ursache 3: Singlethread-Anwendung

Wenn die Anwendung, die Sie verwenden, singlethreaded ist, kann dieses Setup abhängig von der Größe Der bereitgestellten Freigabe zu einem erheblich niedrigeren IOPS-Durchsatz führen als der maximal mögliche Durchsatz.

Lösung

  • Erhöhen Sie die Anwendungsparallelität, indem Sie die Anzahl der Threads erhöhen.
  • Wechseln Sie zu Anwendungen, in denen Parallelität möglich ist. Beispielsweise können Sie für Kopiervorgänge AzCopy oder RoboCopy von Windows-Clients oder den parallelen Befehl von Linux-Clients verwenden.

Ursache 4: Die Anzahl der SMB-Kanäle überschreitet vier.

Wenn Sie SMB MultiChannel verwenden und die Anzahl ihrer Kanäle vier überschreitet, führt dies zu einer schlechten Leistung. Verwenden Sie das PowerShell-Cmdlet get-SmbClientConfiguration , um die aktuellen Einstellungen für die Verbindungsanzahl anzuzeigen, um festzustellen, ob ihre Verbindungsanzahl vier überschreitet.

Lösung

Legen Sie die Einstellung Windows pro NIC für SMB so fest, dass die Gesamtkanäle vier nicht überschreiten. Wenn Sie beispielsweise über zwei NICs verfügen, können Sie den Höchstwert pro NIC mit dem folgenden PowerShell-Cmdlet auf zwei festlegen: Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Ursache 5: Read-Ahead-Größe ist zu klein (nur NFS)

Ab Linux-Kernelversion 5.4 verwendet der Linux NFS-Client einen Standardwert read_ahead_kb von 128 Kibibytes (KiB). Dieser kleine Wert kann den Lesedurchsatz für große Dateien verringern.

Lösung

Es wird empfohlen, den read_ahead_kb Kernelparameterwert auf 15 Mebibytes (MiB) zu erhöhen. Um diesen Wert zu ändern, legen Sie die Read-Ahead-Größe dauerhaft fest, indem Sie eine Regel in udev, einem Linux-Kernel-Geräte-Manager, hinzufügen. Gehen Sie folgendermaßen vor:

  1. Erstellen Sie in einem Text-Editor die Datei /etc/udev/rules.d/99-nfs.rules , indem Sie den folgenden Text eingeben und speichern:

    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. Wenden Sie in einer Konsole die udev-Regel an, indem Sie den Befehl udevadm als Superuser ausführen und die Regeldateien und andere Datenbanken erneut laden. Um udev auf die neue Datei aufmerksam zu machen, müssen Sie diesen Befehl nur einmal ausführen.

    sudo udevadm control --reload

Sehr hohe Latenz für Anforderungen

Ursache

Die Client-VM kann sich in einer anderen Region als die Dateifreigabe befinden. Ein weiterer Grund für eine hohe Latenz kann die durch den Client oder das Netzwerk verursachte Latenz sein.

Lösung

  • Führen Sie die Anwendung auf einem virtuellen Computer aus, der sich in derselben Region wie die Dateifreigabe befindet.
  • Überprüfen Sie für Ihr Speicherkonto die Transaktionsmetriken SuccessE2ELatency und SuccessServerLatency über Azure Monitor in Azure-Portal. Ein hoher Unterschied zwischen den Metrikwerten successE2ELatency und SuccessServerLatency ist ein Hinweis auf die Latenz, die wahrscheinlich durch das Netzwerk oder den Client verursacht wird. Weitere Informationen finden Sie unter Transaktionsmetriken in Azure Files Referenz zu Überwachungsdaten.

Client kann den maximalen Durchsatz nicht erreichen, der vom Netzwerk unterstützt wird

Ursache

Eine mögliche Ursache ist ein Mangel an SMB-Multi-Channel-Unterstützung für Standarddateifreigaben. Derzeit unterstützt Azure Files nur einen einzelnen Kanal für Standarddateifreigaben, sodass nur eine Verbindung zwischen der Client-VM und dem Server besteht. Diese einzelne Verbindung ist an einen einzelnen Kern auf der Client-VM gebunden, sodass der von einem virtuellen Computer erreichbare maximale Durchsatz an einen einzelnen Kern gebunden ist.

Problemumgehung

  • Aktivieren Sie für Premium-Dateifreigaben SMB Multichannel.
  • Das Abrufen eines virtuellen Computers mit einem größeren Kern kann dazu beitragen, den Durchsatz zu verbessern.
  • Das Ausführen der Clientanwendung auf mehreren virtuellen Computern erhöht den Durchsatz.
  • Verwenden Sie nach Möglichkeit REST-APIs.
  • Für NFS-Azure-Dateifreigaben nconnect ist verfügbar. Weitere Informationen finden Sie unter Verbessern der Leistung von NFS-Azure-Dateifreigaben mit nconnect.

Langsame Leistung auf einer Azure-Dateifreigabe, die auf einem virtuellen Linux-Computer eingebunden ist

Ursache 1: Zwischenspeichern

Eine mögliche Ursache für eine langsame Leistung ist die deaktivierte Zwischenspeicherung. Das Zwischenspeichern kann nützlich sein, wenn Sie wiederholt auf eine Datei zugreifen. Andernfalls kann es zu einem Mehraufwand kommen. Überprüfen Sie, ob Sie den Cache verwenden, bevor Sie ihn deaktivieren.

Lösung für Ursache 1

Um zu überprüfen, ob die Zwischenspeicherung deaktiviert ist, suchen Sie nach dem cache= Eintrag.

Cache=none gibt an, dass die Zwischenspeicherung deaktiviert ist. Stellen Sie die Freigabe erneut bereit, indem Sie den Standardeinbindungsbefehl verwenden oder explizit die cache=strict Option zum Einbindungsbefehl hinzufügen, um sicherzustellen, dass die Standardzwischenspeicherung oder der "strenge" Cachemodus aktiviert ist.

In einigen Szenarien kann die Einbindungsoption serverino dazu führen, dass der ls Befehl für jeden Verzeichniseintrag ausgeführt wird stat . Dieses Verhalten führt zu Leistungseinbußen, wenn Sie ein großes Verzeichnis auflisten. Sie können die Einbindungsoptionen in Ihrem /etc/fstab-Eintrag überprüfen:

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

Sie können auch überprüfen, ob die richtigen Optionen verwendet werden, indem Sie den sudo mount | grep cifs Befehl ausführen und dessen Ausgabe überprüfen. Es folgt eine Beispielausgabe:

//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)

Wenn die Option oder serverino nicht vorhanden ist, heben Sie die cache=strict Bereitstellung auf, und binden Sie Azure Files erneut ein, indem Sie den Bereitstellungsbefehl aus der Dokumentation ausführen. Überprüfen Sie dann erneut, ob der Eintrag /etc/fstab über die richtigen Optionen verfügt.

Ursache 2: Drosselung

Es ist möglich, dass eine Drosselung auftritt und Ihre Anforderungen an eine Warteschlange gesendet werden. Sie können dies überprüfen, indem Sie Azure Storage-Metriken in Azure Monitor nutzen. Sie können auch Warnungen erstellen, die Sie benachrichtigen, wenn eine Freigabe gedrosselt oder gedrosselt wird. Weitere Informationen finden Sie unter Problembehandlung bei Azure Files durch Erstellen von Warnungen.

Lösung für Ursache 2

Stellen Sie sicher, dass sich Ihre App innerhalb der Azure Files Skalierungsziele befindet. Wenn Sie Standard-Azure-Dateifreigaben verwenden, sollten Sie zu Premium wechseln.

Der Durchsatz auf Linux-Clients ist niedriger als der von Windows-Clients.

Ursache

Dies ist ein bekanntes Problem bei der Implementierung des SMB-Clients unter Linux.

Problemumgehung

  • Verteilen Sie die Last auf mehrere VMs.
  • Verwenden Sie auf derselben VM mehrere Bereitstellungspunkte mit einer nosharesock Option, und verteilen Sie die Last auf diese Bereitstellungspunkte.
  • Versuchen Sie unter Linux die Einbindung mit einer nostrictsync Option, um zu vermeiden, dass bei jedem fsync Aufruf eine SMB-Leerung erzwungen wird. Für Azure Files beeinträchtigt diese Option die Datenkonsistenz nicht, kann jedoch zu veralteten Dateimetadaten in Verzeichnisauflistungen (ls -l Befehl) führen. Durch direktes Abfragen von Dateimetadaten mit dem stat Befehl werden die aktuellsten Dateimetadaten zurückgegeben.

Hohe Latenzen für metadatenintensive Workloads mit umfangreichen Open/Close-Vorgängen

Ursache

Fehlende Unterstützung für Verzeichnisleases.

Problemumgehung

  • Vermeiden Sie nach Möglichkeit die Verwendung eines übermäßigen Öffnens/Schließenshandles für dasselbe Verzeichnis innerhalb eines kurzen Zeitraums.
  • Erhöhen Sie für Linux-VMs das Timeout für den Verzeichniseintragscache, indem Sie als Bereitstellungsoption angeben actimeo=<sec> . Standardmäßig beträgt das Timeout 1 Sekunde, sodass ein größerer Wert, z. B. 30 Sekunden, hilfreich sein kann.
  • Für CentOS Linux- oder Red Hat Enterprise Linux-VMs (RHEL) führen Sie ein Upgrade des Systems auf CentOS Linux 8.2 oder RHEL 8.2 durch. Für andere Linux-Distributionen aktualisieren Sie den Kernel auf 5.0 oder höher.

Langsame Enumeration von Dateien und Ordnern

Ursache

Dieses Problem kann auftreten, wenn auf dem Clientcomputer nicht genügend Cache für große Verzeichnisse vorhanden ist.

Lösung

Um dieses Problem zu beheben, passen Sie den Registrierungswert an, um das DirectoryCacheEntrySizeMax Zwischenspeichern größerer Verzeichnisauflistungen auf dem Clientcomputer zu ermöglichen:

  • Lage: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
  • Wertname: DirectoryCacheEntrySizeMax
  • Werttyp: DWORD

Sie können sie beispielsweise auf 0x100000 festlegen und überprüfen, ob sich die Leistung verbessert.

Langsames Kopieren von Dateien in und aus Azure-Dateifreigaben

Möglicherweise tritt eine langsame Leistung auf, wenn Sie versuchen, Dateien an den Azure Files-Dienst zu übertragen. Wenn Sie keine bestimmte Mindestanforderung für die E/A-Größe haben, wird empfohlen, 1 MiB als E/A-Größe zu verwenden, um eine optimale Leistung zu erzielen.

Langsames Kopieren von Dateien in und aus Azure Files in Windows

  • Wenn Sie die endgültige Größe einer Datei kennen, die Sie mit Schreibvorgängen erweitern, und Ihre Software keine Kompatibilitätsprobleme aufweist, wenn das ungeschriebene Tail in der Datei Nullen enthält, legen Sie die Dateigröße im Voraus fest, anstatt jeden Schreibvorgang zu einem erweiterten Schreibvorgang zu machen.

  • Verwenden Sie die richtige Kopiermethode:

    • Verwenden Sie AzCopy für jede Übertragung zwischen zwei Dateifreigaben.
    • Verwenden Sie Robocopy zwischen Dateifreigaben auf einem lokalen Computer.

Übermäßige DirectoryOpen/DirectoryClose-Aufrufe

Ursache

Wenn die Anzahl der DirectoryOpen/DirectoryClose-Aufrufe zu den häufigsten API-Aufrufen gehört und Sie nicht erwarten, dass der Client so viele Aufrufe durchführt, kann das Problem durch die Antivirensoftware verursacht werden, die auf der Azure-Client-VM installiert ist.

Problemumgehung

Eine Lösung für dieses Problem ist im April-Plattformupdate für Windows verfügbar.

SMB Multichannel wird nicht ausgelöst

Ursache

Letzte Änderungen an den SMB Multichannel-Konfigurationseinstellungen ohne erneute Bereitstellung.

Lösung

  • Nach änderungen an den SMB-Konfigurationseinstellungen des Windows SMB-Clients oder -Kontos müssen Sie die Bereitstellung der Freigabe aufheben, 60 Sekunden warten und die Freigabe erneut bereitstellen, um den Multichannel-Kanal auszulösen.
  • Generieren Sie für das Windows-Clientbetriebssystem E/A-Last mit hoher Warteschlangentiefe, z. B. QD=8, indem Sie eine Datei kopieren, um SMB Multichannel auszulösen. Für Serverbetriebssysteme wird SMB Multichannel mit QD=1 ausgelöst, d. h., sobald Sie eine E/A für die Freigabe starten.

Langsame Leistung beim Entpacken von Dateien

Abhängig von der genauen verwendeten Komprimierungsmethode und dem verwendeten Entzippenvorgang können Dekomprimierungsvorgänge auf einer Azure-Dateifreigabe langsamer ausgeführt werden als auf Ihrem lokalen Datenträger. Dies liegt häufig daran, dass Entpackungstools eine Reihe von Metadatenvorgängen ausführen, um die Dekomprimierung eines komprimierten Archivs durchzuführen. Um eine optimale Leistung zu erzielen, empfiehlt es sich, das komprimierte Archiv aus der Azure-Dateifreigabe auf Ihren lokalen Datenträger zu kopieren, dort zu entpacken und dann ein Kopiertool wie Robocopy (oder AzCopy) zu verwenden, um zurück in die Azure-Dateifreigabe zu kopieren. Die Verwendung eines Kopiertools wie Robocopy kann die verringerte Leistung von Metadatenvorgängen in Azure Files relativ zu Ihrem lokalen Datenträger ausgleichen, indem mehrere Threads zum parallelen Kopieren von Daten verwendet werden.

Hohe Latenz auf Websites, die auf Dateifreigaben gehostet werden

Ursache

Eine hohe Anzahl von Dateiänderungsbenachrichtigungen auf Dateifreigaben kann zu hohen Latenzen führen. Dies geschieht in der Regel bei Websites, die auf Dateifreigaben mit tief geschachtelter Verzeichnisstruktur gehostet werden. Ein typisches Szenario ist eine von IIS gehostete Webanwendung, bei der die Dateiänderungsbenachrichtigung für jedes Verzeichnis in der Standardkonfiguration eingerichtet ist. Jede Änderung (ReadDirectoryChangesW) auf der Freigabe, für die der Client registriert ist, pusht eine Änderungsbenachrichtigung vom Dateidienst an den Client, der Systemressourcen in Anspruch nimmt, und das Problem wird mit der Anzahl der Änderungen verschlimmert. Dies kann zu einer Drosselung der Freigabe führen und somit zu einer höheren clientseitigen Latenz führen.

Zur Bestätigung können Sie Azure-Metriken im Portal verwenden.

  1. Wechseln Sie im Azure-Portal zu Ihrem Speicherkonto.
  2. Wählen Sie im linken Menü unter Überwachung die Option Metriken aus.
  3. Wählen Sie Datei als Metriknamespace für Ihren Speicherkontobereich aus.
  4. Wählen Sie Transaktionen als Metrik aus.
  5. Fügen Sie einen Filter für ResponseType hinzu, und überprüfen Sie, ob Anforderungen den Antwortcode SuccessWithThrottling (für SMB oder NFS) oder ClientThrottlingError (für REST) aufweisen.

Lösung

  • Wenn die Dateiänderungsbenachrichtigung nicht verwendet wird, deaktivieren Sie die Dateiänderungsbenachrichtigung (bevorzugt).

  • Erhöhen Sie die Häufigkeit des Abrufintervalls für Dateiänderungsbenachrichtigungen, um das Volumen zu reduzieren.

    Aktualisieren Sie das Abrufintervall des W3WP-Arbeitsprozesses basierend auf Ihren Anforderungen auf einen höheren Wert (z. B. 10 oder 30 Minuten). Legen Sie in Ihrer Registrierung festHKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds, und starten Sie den W3WP-Prozess neu.

  • Wenn das zugeordnete physische Verzeichnis Ihrer Website über eine geschachtelte Verzeichnisstruktur verfügt, können Sie versuchen, den Umfang von Dateiänderungsbenachrichtigungen einzuschränken, um das Benachrichtigungsvolumen zu reduzieren. Standardmäßig verwendet IIS die Konfiguration aus Web.config Dateien in dem physischen Verzeichnis, dem das virtuelle Verzeichnis zugeordnet ist, sowie in allen untergeordneten Verzeichnissen in diesem physischen Verzeichnis. Wenn Sie Web.config Dateien in untergeordneten Verzeichnissen nicht verwenden möchten, geben Sie false für das allowSubDirConfig Attribut im virtuellen Verzeichnis an. Weitere Informationen finden Sie hier.

    Legen Sie die Einstellung virtuelles IIS-Verzeichnis allowSubDirConfig in Web.Config auf fest false , um zugeordnete physische untergeordnete Verzeichnisse aus dem Bereich auszuschließen.

Siehe auch

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.