Troubleshooting bei Azure Files-Leistungsproblemen

In diesem Artikel werden häufige Probleme im Zusammenhang mit der Leistung von Azure-Dateifreigaben aufgeführt und mögliche Ursachen und Problemumgehungen bereitgestellt. Um den größten Nutzen aus diesem Leitfaden zur Problembehandlung zu erhalten, sollten Sie zuerst Grundlagen der Azure Files-Leistung lesen.

Gilt für:

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

Behandeln allgemeiner Leistungsprobleme

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

Sie führen ein altes Betriebssystem aus

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

Ihre Workload wird gedrosselt

Anforderungen werden gedrosselt, wenn die E/A-Vorgänge pro Sekunde (I/O Operations Per Second, IOPS) und Grenzwerte für „eingehend“ oder „ausgehend“ für eine Dateifreigabe erreicht werden. Wenn der Client z. B. den IOPS-Grundwert überschreitet, wird er vom Azure Files-Dienst gedrosselt. Die Drosselung kann dazu führen, dass der Client eine schlechte Leistung aufweist.

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

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

Hohe Latenz, geringer Durchsatz oder niedrige IOPS

Ursache 1: Freigabe- oder Speicherkonto wird gedrosselt

Wenn Sie überprüfen möchten, ob Ihr Freigabe- oder Speicherkonto gerade gedrosselt wird, können Sie im Portal auf Azure-Metriken zugreifen und sie verwenden. Sie können auch Warnungen erstellen, die Sie benachrichtigen, wenn eine Freigabe gedrosselt wird oder dies bevorsteht. Siehe Problembehandlung bei Azure Files durch Erstellen von Warnungen.

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.

   Bei Standarddateifreigaben 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.

   

Lösung

Wenn Sie eine Premium-Dateifreigabe verwenden, erhöhen Sie die Größe der bereitgestellten Dateifreigabe, um den IOPS-Grenzwert heraufzusetzen. Weitere Informationen finden Sie unter Grundlegendes zur Bereitstellung für Premium-Dateifreigaben.

Ursache 2: Hohe Arbeitsauslastung bei Metadaten oder Namespace

Wenn der größte Teil Ihrer Anforderungen metadatenzentriert ist (z. B. createfile, openfile, closefile, queryinfo oder querydirectory), wird die Latenz schlimmer als diejenige von Lese-/Schreibvorgängen sein.

Wenn Sie ermitteln möchten, ob die meisten Ihrer Anforderungen metadatenzentriert sind, beginnen Sie mit der Ausführung der Schritte 1–4, wie oben in „Ursache 1“ beschrieben. Wenn Sie in Schritt 5 keinen Filter für Antworttyp hinzufügen möchten, fügen Sie stattdessen einen Eigenschaftsfilter für API-Name hinzu.

Problemumgehungen

• Überprüfen Sie, ob die Anwendung so geändert werden kann, dass sich die Anzahl von Metadatenvorgängen verringert.

• Wenn Sie Premium-SMB Azure-Dateifreigaben verwenden, verwenden Sie die Zwischenspeicherung von Metadaten.

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

• Fügen Sie eine virtuelle Festplatte (Virtual Hard Disk, VHD) für die Dateifreigabe hinzu, und binden Sie die VHD vom Client ein, um Dateivorgänge für die Daten durchzuführen. Dieser Ansatz funktioniert bei Szenarios mit einem einzelnen Writer/Reader oder bei Szenarios mit mehreren Readern und keinen Writern. Weil das Dateisystem im Besitz des Clients (und nicht von Azure Files) ist, dürfen Metadatenvorgänge lokal sein. Das Setup bietet eine ähnliche Leistung wie bei einem lokalen, direkt angeschlossenen Speicher. Da sich die Daten jedoch in einer VHD befinden, kann auf sie nur über den SMB-Bereitstellungspunkt zugegriffen werden, z. B. über die REST-API oder über das Azure-Portal.

  1. Binden Sie die Dateifreigabe von dem Computer aus ein, der auf die Azure-Dateifreigabe zugreifen soll. Verwenden Sie dazu den Schlüssel des Speicherkontos, und ordnen Sie die Dateifreigabe 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 als Standort das Netzlaufwerk fest, dem die Azure-Dateifreigabe zugeordnet ist, geben Sie die benötigte Größe der virtuellen Festplatte an, und wählen Sie Feste Größe aus.
  4. Klicken Sie auf OK. Sobald die Erstellung der VHD abgeschlossen ist, wird sie automatisch eingebunden, und es wird eine neue, nicht zugeordnete Festplatte 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:“). Im Datei-Explorer sollte die neue VHD auf dem Netzwerklaufwerk der zugeordneten Azure-Dateifreigabe (in diesem Beispiel „Z:“) angezeigt werden. Zur Verdeutlichung: Es sollten zwei Laufwerkbuchstaben vorhanden sein – die standardmäßige Netzwerkzuordnung der Azure-Dateifreigabe auf „Z:“ und die VHD-Zuordnung auf dem Laufwerk „E:“.
  8. Die Leistung bei umfangreichen Metadatenvorgängen für Dateien auf dem VHD-Laufwerk (E:) sollte deutlich besser sein als auf dem Laufwerk der Azure-Dateifreigabe (Z:). Bei Bedarf sollte es möglich sein, das zugeordnete Netzlaufwerk (Z:) zu trennen und trotzdem auf das eingebundene VHD-Laufwerk (E:) zuzugreifen.
  • Sie können zum Einbinden einer VHD auf einem Windows-Client auch das PowerShell-Cmdlet Mount-DiskImage verwenden.
  • Informationen zum Einbinden einer VHD unter Linux finden Sie in der Dokumentation für Ihre Linux-Distribution. Ein entsprechendes Beispiel finden Sie hier.

Ursache 3: Singlethread-Anwendung

Wenn die von Ihnen verwendete Anwendung eine Singlethread-Anwendung ist, kann dieses Setup dazu führen, dass der IOPS-Durchsatz deutlich niedriger ist als derjenige, der je nach Ihrer bereitgestellten Freigabegröße maximal möglich wäre.

Lösung

• Erhöhen Sie die Parallelität Ihrer Anwendung, indem Sie die Anzahl von Threads erhöhen.
• Wechseln Sie zu Anwendungen, in denen Parallelität möglich ist. Für Kopiervorgänge könnten Sie beispielsweise „AzCopy“ oder „RoboCopy“ von Windows-Clients oder den Befehl parallel von Linux-Clients verwenden.

Ursache 4: mehr als vier SMB-Kanäle

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

Lösung

Legen Sie unter Windows die NIC-Einstellung für SMB fest, damit die Gesamtanzahl der Kanäle vier nicht überschreitet. Wenn Sie beispielsweise über zwei NICs verfügen, können Sie die maximale Anzahl pro NIC mithilfe des folgenden PowerShell-Cmdlets auf zwei festlegen: Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Ursache 5: Die Lesegröße ist zu klein (nur NFS)

Ab Linux Kernel Version 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-Kernelgeräte-Manager, hinzufügen. Führen Sie folgende Schritte aus:

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 neu 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

Der virtuelle Clientcomputer kann sich in einer anderen Region als die Dateifreigabe befinden. Eine andere mögliche Ursache für hohe Wartezeit kann die client- oder netzwerkbedingte Wartezeit 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 im Azure-Portal. Eine große Differenz zwischen den Metriken „SuccessE2ELatency“ und „SuccessServerLatency“ deutet auf Wartezeit hin, die wahrscheinlich durch das Netzwerk oder den Client verursacht wird. Weitere Informationen finden Sie in der Referenz zur Überwachung von Daten in Azure Files unter Transaktionsmetriken.

Client kann den maximalen Durchsatz des Netzwerks nicht erreichen

Ursache

Eine mögliche Ursache ist das Fehlen von SMB-Unterstützung für mehrere Kanäle bei Standarddateifreigaben. Zurzeit unterstützt Azure Files für Standarddateifreigaben nur Einkanalübertragung, sodass es nur eine einzige Verbindung zwischen dem virtuellen Clientcomputer und dem Server gibt. Diese einzelne Verbindung ist an einen einzelnen Kern auf dem virtuellen Clientcomputer gebunden, weshalb der maximal erreichbare Durchsatz für den virtuellen Computer durch den einzelnen Kern beschränkt ist.

Problemumgehung

• Aktivieren Sie für Premium-Dateifreigaben SMB Multichannel.
• Durch Bereitstellen eines virtuellen Computers mit einem größeren Kern könnte der Durchsatz möglicherweise erhöht werden.
• Durch Ausführen der Clientanwendung auf mehreren virtuellen Computern wird der Durchsatz erhöht.
• Verwenden Sie nach Möglichkeit REST-APIs.
• Für NFS-Azure-Dateifreigaben ist nconnect verfügbar. Weitere Informationen finden Sie unter Verbessern der NFS-Azure-Dateifreigabeleistung mit nconnect.

Langsame Leistung in einer Azure-Dateifreigabe, die in einer Linux-VM bereit gestellt ist

Ursache 1: Caching

Eine mögliche Ursache der langsamen Leistung ist der deaktivierte Cache. Das Zwischenspeichern kann nützlich sein, wenn Sie wiederholt auf eine Datei zugreifen. Andernfalls kann dies ein Overhead sein. Ü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 mithilfe des Standardmäßigen Bereitstellungsbefehls erneut bereit, oder fügen Sie explizit die cache=strict Option zum Bereitstellungsbefehl hinzu, um sicherzustellen, dass der standardmäßige Cache- oder "strict"-Cachemodus aktiviert ist.

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

//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 die Ausgabe überprüfen. Nachfolgend sehen Sie 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 serverino nicht vorhanden ist, heben Sie die cache=strict Bereitstellung von Azure Files erneut auf, indem Sie den Bereitstellungsbefehl aus der Dokumentation ausführen. Überprüfen Sie dann erneut, ob der /etc/fstab-Eintrag die richtigen Optionen hat.

Ursache 2: Drosselung

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

Lösung für Ursache 2

Stellen Sie sicher, dass sich Ihre App innerhalb der Skalierbarkeitsziele für Azure Files befindet. Wenn Sie Azure-Standarddateifreigaben verwenden, sollten Sie zu Premium wechseln.

Der Durchsatz auf Linux-Clients ist geringer als auf Windows-Clients

Ursache

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

Problemumgehung

• Verteilen Sie die Last auf mehrere virtuelle Computer.
• Verwenden Sie auf demselben virtuellen Computer mehrere Bereitstellungspunkte mit der Option nosharesock, und verteilen Sie die Last auf diese Punkte.
• Versuchen Sie unter Linux, die Einbindung mit einer Option nostrictsync durchzuführen, um eine SMB-Leerung bei jedem Aufruf von fsync zu vermeiden. Bei Azure Files beeinträchtigt diese Option nicht die Datenkonsistenz. Sie könnte aber in Verzeichnisauflistungen zu veralteten Dateimetadaten (Befehl ls -l) führen. Durch direktes Abfragen von Dateimetadaten mit dem Befehl stat werden die aktuellsten Dateimetadaten zurückgegeben.

Hohe Latenzen bei metadatenorientierten hohen Arbeitslasten, die sich aus umfangreichen Öffnen-/Schließen-Vorgängen ergeben

Ursache

Es werden keine Verzeichnis-Leasedauern unterstützt.

Problemumgehung

• Vermeiden Sie nach Möglichkeit, dass Öffnen-/Schließen-Vorgänge in demselben Verzeichnis innerhalb kurzer Zeit verarbeitet werden müssen.
• Erhöhen Sie bei virtuellen Linux-Computern das Cachetimeout für Verzeichniseinträge, indem Sie die Einbindungsoption actimeo=<sec> angeben. Standardmäßig beträgt das Timeout 1 Sekunde, also kann ein größerer Wert, z. B. 30 oder 5 Sekunden, hilfreich sein.
• Aktualisieren Sie das System bei virtuellen CentOS Linux- oder Red Hat Enterprise Linux (RHEL)-Computern auf CentOS Linux 8.2 bzw. RHEL 8.2. Aktualisieren Sie bei anderen Linux-Distributionen den Kernel auf mindestens 5.0.

Langsame Enumeration von Dateien und Ordnern

Ursache

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

Lösung

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

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

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

Langsames Kopieren von Dateien in und aus Azure-Dateifreigaben

Die Geschwindigkeit ist möglicherweise gering, wenn Sie versuchen, Dateien in den Azure Files-Dienst zu übertragen. Wenn Sie keine bestimmte Anforderung für die Mindest-E/A-Größe haben, empfehlen wir Ihnen für eine optimale Leistung die Verwendung von 1 MiB als E/A-Größe.

Übermäßig viele DirectoryOpen/DirectoryClose-Aufrufe

Ursache

Wenn sich die Anzahl von DirectoryOpen/DirectoryClose-Aufrufen unter den häufigsten API-Aufrufen befindet und Sie nicht erwarten, dass der Client so viele Aufrufe ausführt, könnte die Problemursache die auf dem virtuellen Azure-Client installierte Antivirensoftware sein.

Problemumgehung

Eine Behebung dieses Problems ist im Plattformupdate für Windows aus April verfügbar.

SMB Multichannel wird nicht ausgelöst

Ursache

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

Lösung

• Nach Änderungen an den SMB Multichannel-Konfigurationseinstellungen für den Windows SMB-Client oder das Multichannel-Konto müssen Sie die Bereitstellung der Freigabe aufheben, 60 Sekunden lang warten und dann die Freigabe erneut bereitstellen, um den Multichannel-Vorgang auszulösen.
• Generieren Sie beim Windows-Clientbetriebssystem die E/A-Auslastung mit hoher Warteschlangentiefe (Queue Depth) wie „QD=8“, beispielsweise durch das Kopieren einer Datei zum Auslösen von SMB Multichannel. Beim Serverbetriebssystem wird SMB Multichannel mit „QD=1“ ausgelöst, also sobald Sie eine E/A für die Freigabe starten.

Langsame Leistung beim Entpacken von Dateien

Abhängig von der jeweiligen Komprimierungsmethode und dem verwendeten Entpackungsvorgang können Dekomprimierungsvorgänge in 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 die bestmögliche Leistung zu erzielen, empfiehlt es sich, das komprimierte Archiv aus der Azure-Dateifreigabe auf Ihren lokalen Datenträger zu kopieren, es dort zu entpacken und dann ein Kopiertool wie Robocopy (oder AzCopy) zum Zurückkopieren in die Azure-Dateifreigabe zu verwenden. Die Verwendung eines Kopiertools wie Robocopy kann die verringerte Leistung von Metadatenvorgängen in Azure Files im Vergleich zu Ihrem lokalen Datenträger kompensieren, indem mehrere Threads verwendet werden, um Daten parallel zu kopieren.

Hohe Latenz bei Websites, die auf Dateifreigaben gehostet werden

Ursache

Eine hohe Anzahl von Dateiänderungsbenachrichtigungen für Dateifreigaben kann zu hohen Latenzen führen. Dieses Problem tritt normalerweise bei Websites auf, die auf Dateifreigaben mit einer tief geschachtelten Verzeichnisstruktur gehostet werden. Ein typisches Szenario ist eine IIS-gehostete Webanwendung, bei der eine Dateiänderungsbenachrichtigung für jedes Verzeichnis in der Standardkonfiguration eingerichtet wird. Bei jeder Änderung (ReadDirectoryChangesW) für die Freigabe, für die der Client registriert ist, wird eine Änderungsbenachrichtigung vom Dateidienst mithilfe von Push an den Client übertragen. Dadurch werden Systemressourcen beansprucht, und das Problem verschlimmert sich mit zunehmender Anzahl von Änderungen. Dies kann eine Freigabedrosselung verursachen und folglich zu einer höheren clientseitigen Latenz führen.

Zur Überprüfung können Sie die Azure-Metriken im Portal verwenden.

1. Wechseln Sie im Azure-Portal zu Ihrem Speicherkonto.
2. Klicken Sie links im Menü unter Überwachung auf Metrik.
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 über einen Antwortcode ( SuccessWithThrottling für SMB oder NFS) oder ClientThrottlingError (für REST) verfügen.

Lösung

• Wenn keine Dateiänderungsbenachrichtigung verwendet wird, deaktivieren Sie diese Benachrichtigung (bevorzugt).

  • Deaktivieren Sie die Dateiänderungsbenachrichtigung durch Aktualisieren von „FCNMode“.
  • Aktualisieren Sie das Abrufintervall des IIS-Workerprozesses (W3WP) auf „0“, indem Sie in Ihrer Registrierung HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds festlegen. Starten Sie dann den W3WP-Prozess neu. Informationen zu dieser Einstellung finden Sie unter Common registry keys that are used by many parts of IIS (Allgemeine Registrierungsschlüssel, die von vielen Teilen von IIS verwendet werden).

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

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

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

  Legen Sie die Einstellung für das virtuelle IIS-Verzeichnis allowSubDirConfig in Web.Config fest, um false zugeordnete physische untergeordnete Verzeichnisse aus dem Bereich auszuschließen.

Siehe auch

• Problembehandlung für Azure Files
• Problembehandlung bei Azure Files durch Erstellen von Warnungen
• Grundlegendes zur Leistung für Azure Files
• Überblick über Warnungen in Microsoft Azure
• Häufig gestellte Fragen (FAQ) zu Azure Files

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.