Udostępnij za pośrednictwem

Rozwiązywanie problemów z wydajnością Azure Files

  • Artykuł

Uwaga

CentOS, do którego odwołuje się ten artykuł, jest dystrybucją systemu Linux i osiągnie koniec życia (EOL). Rozważ użycie i odpowiednio zaplanuj. Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące końca życia systemu CentOS.

W tym artykule wymieniono typowe problemy związane z wydajnością udziału plików platformy Azure oraz przedstawiono potencjalne przyczyny i obejścia. Aby uzyskać jak największą wartość z tego przewodnika rozwiązywania problemów, zalecamy przeczytanie pierwszego czytania opisu wydajności Azure Files.

Informacje zawarte w tym artykule dotyczą

Typ udziału plików SMB NFS
Standardowe udziały plików (GPv2), LRS/ZRS
Standardowe udziały plików (GPv2), GRS/GZRS
Udziały plików Premium (FileStorage), LRS/ZRS

Ogólne rozwiązywanie problemów z wydajnością

Najpierw należy wykluczyć niektóre typowe przyczyny problemów z wydajnością.

Używasz starego systemu operacyjnego

Jeśli na maszynie wirtualnej klienta działa Windows 8.1 lub Windows Server 2012 R2 albo starsza dystrybucja lub jądro systemu Linux, podczas uzyskiwania dostępu do udziałów plików platformy Azure mogą wystąpić problemy z wydajnością. Uaktualnij system operacyjny klienta lub zastosuj poniższe poprawki.

Zagadnienia dotyczące Windows 8.1 i Windows Server 2012 R2

Klienci z systemem Windows 8.1 lub Windows Server 2012 R2 mogą mieć większe niż oczekiwano opóźnienie podczas uzyskiwania dostępu do udziałów plików platformy Azure dla obciążeń intensywnie korzystających z operacji we/wy. Upewnij się, że zainstalowano poprawkę KB3114025 . Ta poprawka poprawia wydajność tworzenia i zamykania dojść.

Możesz uruchomić następujący skrypt, aby sprawdzić, czy poprawka została zainstalowana:

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

Jeśli poprawka jest zainstalowana, zostaną wyświetlone następujące dane wyjściowe:

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

Uwaga

Windows Server 2012 obrazy R2 w Azure Marketplace mają domyślnie zainstalowaną poprawkę KB3114025, począwszy od grudnia 2015 r.

Obciążenie jest ograniczane

Żądania są ograniczane po osiągnięciu limitów operacji we/wy na sekundę (IOPS), ruchu przychodzącego lub ruchu wychodzącego dla udziału plików. Jeśli na przykład klient przekroczy liczbę operacji we/wy na sekundę punktu odniesienia, zostanie on ograniczony przez usługę Azure Files. Ograniczanie przepustowości może spowodować, że klient będzie miał niską wydajność.

Aby zrozumieć limity standardowych i premium udziałów plików, zobacz Udział plików i cele skalowania plików. W zależności od obciążenia ograniczanie przepustowości można często uniknąć, przechodząc ze standardowych do udziałów plików platformy Azure w warstwie Premium.

Aby dowiedzieć się więcej o tym, jak ograniczanie przepustowości na poziomie udziału lub na poziomie konta magazynu może powodować duże opóźnienia, niską przepływność i ogólne problemy z wydajnością, zobacz Udostępnianie lub ograniczanie konta magazynu.

Duże opóźnienie, niska przepływność lub niska liczba operacji we/wy na sekundę

Przyczyna 1. Ograniczanie udziału lub konta magazynu

Aby potwierdzić, czy twoje konto udziału lub magazynu jest ograniczane, możesz uzyskać dostęp do metryk platformy Azure i korzystać z nich w portalu. Można również tworzyć alerty, które będą powiadamiać o ograniczaniu lub ograniczaniu udziału. Zobacz Rozwiązywanie problemów z Azure Files przez utworzenie alertów.

Ważna

W przypadku standardowych kont magazynu ograniczanie przepustowości odbywa się na poziomie konta magazynu. W przypadku udziałów plików w warstwie Premium ograniczanie przepustowości odbywa się na poziomie udziału.

  1. W Azure Portal przejdź do konta magazynu.

  2. W okienku po lewej stronie w obszarze Monitorowanie wybierz pozycję Metryki.

  3. Wybierz pozycję Plik jako przestrzeń nazw metryki dla zakresu konta magazynu.

  4. Wybierz pozycję Transakcje jako metrykę.

  5. Dodaj filtr dla typu odpowiedzi, a następnie sprawdź, czy jakiekolwiek żądania zostały ograniczone.

    W przypadku standardowych udziałów plików następujące typy odpowiedzi są rejestrowane, jeśli żądanie jest ograniczone na poziomie konta klienta:

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    W przypadku udziałów plików w warstwie Premium następujące typy odpowiedzi są rejestrowane, jeśli żądanie jest ograniczone na poziomie udziału:

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

    Jeśli żądanie ograniczone zostało uwierzytelnione za pomocą protokołu Kerberos, może zostać wyświetlony prefiks wskazujący protokół uwierzytelniania, taki jak:

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

    Aby dowiedzieć się więcej o poszczególnych typach odpowiedzi, zobacz Wymiary metryk.

    Zrzut ekranu przedstawiający filtr właściwości

Rozwiązanie

Jeśli używasz udziału plików w warstwie Premium, zwiększ rozmiar aprowizowanego udziału plików, aby zwiększyć limit liczby operacji we/wy na sekundę. Aby dowiedzieć się więcej, zobacz Opis aprowizacji udziałów plików w warstwie Premium.

Przyczyna 2. Duże obciążenie metadanych lub przestrzeni nazw

Jeśli większość żądań jest zorientowana na metadane (na przykład createfile, , openfileclosefile, , queryinfolub querydirectory), opóźnienie będzie gorsze niż w przypadku operacji odczytu/zapisu.

Aby ustalić, czy większość żądań jest zorientowana na metadane, rozpocznij od kroków 1–4 zgodnie z wcześniejszym opisem w temacie Przyczyna 1. W kroku 5, zamiast dodawać filtr dla typu odpowiedź, dodaj filtr właściwości dla nazwy interfejsu API.

Zrzut ekranu przedstawiający filtr właściwości

Obejścia

  • Sprawdź, czy można zmodyfikować aplikację w celu zmniejszenia liczby operacji metadanych.

  • Jeśli używasz udziałów plików platformy Azure SMB w warstwie Premium, użyj buforowania metadanych.

  • Oddziel udział plików na wiele udziałów plików na tym samym koncie magazynu.

  • Dodaj wirtualny dysk twardy (VHD) do udziału plików i zainstaluj dysk VHD z klienta, aby wykonywać operacje na plikach względem danych. Takie podejście działa w przypadku scenariuszy lub scenariuszy z pojedynczym zapisem/czytelnikiem z wieloma czytelnikami i bez składników zapisywania. Ponieważ system plików jest własnością klienta, a nie Azure Files, pozwala to na lokalne operacje metadanych. Konfiguracja oferuje wydajność podobną do wydajności lokalnego magazynu bezpośrednio dołączonego. Jednak ponieważ dane są w wirtualnym dysku twardym, nie można uzyskać do nich dostępu za pośrednictwem innych środków niż instalacja SMB, na przykład interfejs API REST lub za pośrednictwem Azure Portal.

    1. Na maszynie, która musi uzyskać dostęp do udziału plików platformy Azure, zainstaluj udział plików przy użyciu klucza konta magazynu i zamapuj go na dostępny dysk sieciowy (na przykład Z:).
    2. Przejdź do pozycji Zarządzanie dyskami i wybierz pozycję Akcja > Twórca dysku VHD.
    3. Ustaw pozycję Lokalizacja na dysk sieciowy, na który jest mapowany udział plików platformy Azure, ustaw rozmiar wirtualnego dysku twardego zgodnie z potrzebami, a następnie wybierz pozycję Stały rozmiar.
    4. Wybierz przycisk OK. Po zakończeniu tworzenia dysku VHD zostanie on automatycznie zainstalowany i zostanie wyświetlony nowy nieprzydzielony dysk.
    5. Kliknij prawym przyciskiem myszy nowy nieznany dysk i wybierz pozycję Inicjuj dysk.
    6. Kliknij prawym przyciskiem myszy obszar nieprzydzielony i utwórz nowy wolumin prosty.
    7. W usłudze Zarządzanie dyskami powinna zostać wyświetlona nowa litera dysku reprezentująca ten wirtualny dysk twardy z dostępem do odczytu/zapisu (na przykład E:). W Eksplorator plików nowy dysk VHD powinien zostać wyświetlony na zamapowanym dysku sieciowym udziału plików platformy Azure (Z: w tym przykładzie). Aby było jasne, powinny istnieć dwie litery dysku: standardowe mapowanie sieci udziału plików platformy Azure na Z:i mapowanie dysku VHD na dysku E: .
    8. W przypadku dużych operacji metadanych na plikach na dysku VHD (E:) powinna istnieć znacznie lepsza wydajność w przypadku dużych operacji na metadanych w porównaniu z dyskiem zamapowanym udziału plików platformy Azure (Z:). W razie potrzeby powinno być możliwe odłączenie zamapowanego dysku sieciowego (Z:) i uzyskanie dostępu do zainstalowanego dysku VHD (E:).
    • Aby zainstalować dysk VHD na kliencie systemu Windows, można również użyć Mount-DiskImage polecenia cmdlet programu PowerShell.
    • Aby zainstalować dysk VHD w systemie Linux, zapoznaj się z dokumentacją dystrybucji systemu Linux. Oto przykład.

Przyczyna 3. Aplikacja jednowątkowa

Jeśli używana aplikacja jest jednowątkowa, ta konfiguracja może spowodować znacznie mniejszą przepływność operacji we/wy na sekundę niż maksymalna możliwa przepływność, w zależności od rozmiaru aprowizowanego udziału.

Rozwiązanie

  • Zwiększ równoległość aplikacji, zwiększając liczbę wątków.
  • Przełącz się do aplikacji, w których możliwe jest równoległość. Na przykład w przypadku operacji kopiowania można użyć narzędzia AzCopy lub RoboCopy z klientów systemu Windows lub polecenia równoległego z klientów systemu Linux.

Przyczyna 4. Liczba kanałów SMB przekracza cztery

Jeśli używasz protokołu SMB MultiChannel, a liczba kanałów przekracza cztery, spowoduje to niską wydajność. Aby określić, czy liczba połączeń przekracza cztery, użyj polecenia cmdlet get-SmbClientConfiguration programu PowerShell, aby wyświetlić bieżące ustawienia liczby połączeń.

Rozwiązanie

Ustaw ustawienie Dla karty sieciowej systemu Windows dla protokołu SMB, aby łączna liczba kanałów nie przekraczała czterech. Jeśli na przykład masz dwie karty sieciowe, możesz ustawić maksymalną liczbę kart sieciowych na dwie przy użyciu następującego polecenia cmdlet programu PowerShell: Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Przyczyna 5. Rozmiar odczytu z wyprzedzeniem jest zbyt mały (tylko system plików NFS)

Począwszy od jądra systemu Linux w wersji 5.4, klient systemu Linux NFS używa domyślnej read_ahead_kb wartości 128 kibibytes (KiB). Ta mała wartość może zmniejszyć przepływność odczytu dla dużych plików.

Rozwiązanie

Zalecamy zwiększenie wartości parametru read_ahead_kb jądra do 15 mebibytów (MiB). Aby zmienić tę wartość, ustaw trwały rozmiar odczytu z wyprzedzeniem, dodając regułę w udev, menedżerze urządzeń jądra systemu Linux. Wykonaj następujące czynności:

  1. W edytorze tekstów utwórz plik /etc/udev/rules.d/99-nfs.rules , wprowadzając i zapisując następujący tekst:

    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. W konsoli zastosuj regułę udev, uruchamiając polecenie udevadm jako superużytkownik i ponownie ładując pliki reguł i inne bazy danych. Aby umożliwić udev zapoznanie się z nowym plikiem, wystarczy uruchomić to polecenie tylko raz.

    sudo udevadm control --reload

Bardzo duże opóźnienie żądań

Przyczyna

Maszyna wirtualna klienta może znajdować się w innym regionie niż udział plików. Inną przyczyną dużego opóźnienia może być opóźnienie spowodowane przez klienta lub sieć.

Rozwiązanie

  • Uruchom aplikację z maszyny wirtualnej znajdującej się w tym samym regionie co udział plików.
  • W przypadku konta magazynu przejrzyj metryki transakcji SuccessE2ELatency i SuccessServerLatency za pośrednictwem usługi Azure Monitor w Azure Portal. Duża różnica między wartościami metryk SuccessE2ELatency i SuccessServerLatency jest wskazaniem opóźnienia, które jest prawdopodobnie spowodowane przez sieć lub klienta. Zobacz Metryki transakcji w dokumentacji danych monitorowania Azure Files.

Klient nie może osiągnąć maksymalnej przepływności obsługiwanej przez sieć

Przyczyna

Jedną z potencjalnych przyczyn jest brak obsługi wielu kanałów SMB dla standardowych udziałów plików. Obecnie Azure Files obsługuje tylko jeden kanał dla standardowych udziałów plików, więc istnieje tylko jedno połączenie z maszyną wirtualną klienta z serwerem. To pojedyncze połączenie jest powiązane z pojedynczym rdzeniem na maszynie wirtualnej klienta, więc maksymalna przepływność osiągalna z maszyny wirtualnej jest powiązana jednym rdzeniem.

Obejście problemu

Niska wydajność udziału plików platformy Azure zainstalowanego na maszynie wirtualnej z systemem Linux

Przyczyna 1. Buforowanie

Jedną z możliwych przyczyn niskiej wydajności jest wyłączone buforowanie. Buforowanie może być przydatne w przypadku wielokrotnego uzyskiwania dostępu do pliku. W przeciwnym razie może to być obciążenie. Sprawdź, czy używasz pamięci podręcznej przed jej wyłączeniem.

Rozwiązanie przyczyny 1

Aby sprawdzić, czy buforowanie jest wyłączone, poszukaj wpisu cache= .

Cache=none wskazuje, że buforowanie jest wyłączone. Zainstaluj ponownie udział przy użyciu domyślnego polecenia instalacji lub jawnie dodając cache=strict opcję do polecenia instalacji, aby upewnić się, że domyślny tryb buforowania lub "ścisły" tryb buforowania jest włączony.

W niektórych scenariuszach serverino opcja instalacji może spowodować uruchomienie stat polecenia względem każdego wpisu ls katalogu. To zachowanie powoduje obniżenie wydajności podczas wyświetlania dużego katalogu. Opcje instalacji można sprawdzić we wpisie /etc/fstab :

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

Możesz również sprawdzić, czy są używane odpowiednie opcje, uruchamiając sudo mount | grep cifs polecenie i sprawdzając jego dane wyjściowe. Poniżej przedstawiono przykładowe dane wyjściowe:

//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 Jeśli nie ma opcji lubserverino, odinstaluj i zainstaluj Azure Files ponownie, uruchamiając polecenie instalacji z dokumentacji. Następnie sprawdź ponownie, czy wpis /etc/fstab ma poprawne opcje.

Przyczyna 2. Ograniczanie przepustowości

Możliwe, że występuje ograniczanie przepustowości, a żądania są wysyłane do kolejki. Możesz to sprawdzić, korzystając z metryk usługi Azure Storage w usłudze Azure Monitor. Można również tworzyć alerty, które powiadamiają o ograniczaniu lub ograniczaniu udziału. Zobacz Rozwiązywanie problemów z Azure Files przez utworzenie alertów.

Rozwiązanie przyczyny 2

Upewnij się, że aplikacja znajduje się w Azure Files celach skalowania. Jeśli używasz standardowych udziałów plików platformy Azure, rozważ przejście na warstwę Premium.

Przepływność na klientach z systemem Linux jest niższa niż w przypadku klientów systemu Windows

Przyczyna

Jest to znany problem z implementowaniem klienta SMB w systemie Linux.

Obejście problemu

  • Rozłożenie obciążenia na wiele maszyn wirtualnych.
  • Na tej samej maszynie wirtualnej użyj wielu punktów instalacji z opcją nosharesock i rozłóż obciążenie na tych punktach instalacji.
  • W systemie Linux spróbuj zostać instalowany z opcją nostrictsync , aby uniknąć wymuszania opróżniania protokołu SMB przy każdym fsync wywołaniu. W przypadku Azure Files ta opcja nie zakłóca spójności danych, ale może spowodować nieaktualne metadane plików na listach katalogów (ls -lpolecenie). Bezpośrednie wykonywanie zapytań dotyczących metadanych pliku przy użyciu stat polecenia spowoduje zwrócenie najbardziej aktualnych metadanych pliku.

Duże opóźnienia dla obciążeń o dużej ilości metadanych obejmujących rozległe operacje otwierania/zamykania

Przyczyna

Brak obsługi dzierżaw katalogów.

Obejście problemu

  • Jeśli to możliwe, unikaj używania nadmiernego dojścia otwierania/zamykania w tym samym katalogu w krótkim czasie.
  • W przypadku maszyn wirtualnych z systemem Linux zwiększ limit czasu pamięci podręcznej wpisu katalogu, określając actimeo=<sec> jako opcję instalacji. Domyślnie limit czasu wynosi 1 sekundę, więc większa wartość, taka jak 30 sekund, może pomóc.
  • W przypadku maszyn wirtualnych z systemem CentOS Linux lub Red Hat Enterprise Linux (RHEL) uaktualnij system do systemu CentOS Linux 8.2 lub RHEL 8.2. W przypadku innych dystrybucji systemu Linux uaktualnij jądro do wersji 5.0 lub nowszej.

Powolne wyliczanie plików i folderów

Przyczyna

Ten problem może wystąpić, jeśli na maszynie klienckiej nie ma wystarczającej ilości pamięci podręcznej dla dużych katalogów.

Rozwiązanie

Aby rozwiązać ten problem, dostosuj DirectoryCacheEntrySizeMax wartość rejestru, aby umożliwić buforowanie większych list katalogów na maszynie klienckiej:

  • Lokalizacji: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
  • Nazwa wartości: DirectoryCacheEntrySizeMax
  • Typ wartości: DWORD

Możesz na przykład ustawić go na 0x100000 wartość i sprawdzić, czy wydajność się poprawia.

Powolne kopiowanie plików do i z udziałów plików platformy Azure

Podczas próby przeniesienia plików do usługi Azure Files może wystąpić niska wydajność. Jeśli nie masz określonego minimalnego wymagania dotyczącego rozmiaru operacji we/wy, zalecamy użycie 1 mb jako rozmiaru we/wy w celu uzyskania optymalnej wydajności.

Powolne kopiowanie plików do i z Azure Files w systemie Windows

  • Jeśli znasz ostateczny rozmiar pliku rozszerzanego za pomocą zapisów, a oprogramowanie nie ma problemów ze zgodnością, gdy niepisany ogon w pliku zawiera zera, ustaw rozmiar pliku z wyprzedzeniem, zamiast tworzyć każdy zapis rozszerzający zapis.

  • Użyj właściwej metody kopiowania:

    • Użyj narzędzia AzCopy do dowolnego transferu między dwoma udziałami plików.
    • Użyj narzędzia Robocopy między udziałami plików na komputerze lokalnym.

Nadmierna ilość wywołań DirectoryOpen/DirectoryClose

Przyczyna

Jeśli liczba wywołań DirectoryOpen/DirectoryClose należy do najpopularniejszych wywołań interfejsu API i nie oczekujesz, że klient wywoła tak wiele wywołań, problem może być spowodowany przez oprogramowanie antywirusowe zainstalowane na maszynie wirtualnej klienta platformy Azure.

Obejście problemu

Rozwiązanie tego problemu jest dostępne w kwietniowej aktualizacji platformy dla systemu Windows.

Protokół SMB Multichannel nie jest wyzwalany

Przyczyna

Ostatnie zmiany ustawień konfiguracji SMB Multichannel bez ponownej instalacji.

Rozwiązanie

  • Po wprowadzeniu jakichkolwiek zmian w ustawieniach konfiguracji wielokanałowej protokołu SMB systemu Windows, należy odinstalować udział, odczekać 60 sekund i ponownie instalować udział, aby wyzwolić wielokanałowy.
  • W przypadku systemu operacyjnego klienta systemu Windows wygeneruj obciążenie we/wy z dużą głębokością kolejki na przykład QD=8, na przykład kopiując plik w celu wyzwolenia funkcji SMB Multichannel. W przypadku systemu operacyjnego serwera funkcja SMB Multichannel jest wyzwalana za pomocą wartości QD=1, co oznacza, że natychmiast po uruchomieniu operacji we/wy w udziale.

Niska wydajność podczas rozpakowywania plików

W zależności od dokładnej metody kompresji i używanej operacji rozpakowywania operacje dekompresji mogą działać wolniej w udziale plików platformy Azure niż na dysku lokalnym. Dzieje się tak często dlatego, że narzędzia do rozdzielania wykonują wiele operacji metadanych w procesie dekompresji skompresowanego archiwum. Aby uzyskać najlepszą wydajność, zalecamy skopiowanie skompresowanego archiwum z udziału plików platformy Azure na dysk lokalny, rozpakowanie go, a następnie użycie narzędzia do kopiowania, takiego jak Robocopy (lub AzCopy), aby skopiować z powrotem do udziału plików platformy Azure. Użycie narzędzia do kopiowania, takiego jak Robocopy, może zrekompensować zmniejszoną wydajność operacji metadanych w Azure Files względem dysku lokalnego, używając wielu wątków do równoległego kopiowania danych.

Duże opóźnienia w witrynach sieci Web hostowanych w udziałach plików

Przyczyna

Powiadomienie o zmianie pliku o dużej liczbie w udziałach plików może spowodować duże opóźnienia. Zwykle dzieje się tak w przypadku witryn sieci Web hostowanych w udziałach plików z głęboko zagnieżdżoną strukturą katalogów. Typowym scenariuszem jest aplikacja internetowa hostowana przez usługi IIS, w której dla każdego katalogu w konfiguracji domyślnej jest skonfigurowane powiadomienie o zmianie pliku. Każda zmiana (ReadDirectoryChangesW) w udziale zarejestrowanym przez klienta na potrzeby wypychania powiadomienia o zmianie z usługi plików do klienta, która pobiera zasoby systemowe, a problem pogarsza się wraz z liczbą zmian. Może to spowodować ograniczanie udziału, a tym samym spowodować większe opóźnienie po stronie klienta.

Aby to potwierdzić, możesz użyć metryk platformy Azure w portalu.

  1. W Azure Portal przejdź do konta magazynu.
  2. W menu po lewej stronie w obszarze Monitorowanie wybierz pozycję Metryki.
  3. Wybierz pozycję Plik jako przestrzeń nazw metryki dla zakresu konta magazynu.
  4. Wybierz pozycję Transakcje jako metrykę.
  5. Dodaj filtr responsetype i sprawdź, czy jakiekolwiek żądania mają kod SuccessWithThrottling odpowiedzi (dla protokołu SMB lub NFS) lub ClientThrottlingError (dla interfejsu REST).

Rozwiązanie

  • Jeśli powiadomienie o zmianie pliku nie jest używane, wyłącz powiadomienie o zmianie pliku (preferowane).

  • Zwiększ częstotliwość interwału sondowania powiadomień o zmianie pliku, aby zmniejszyć ilość.

    Zaktualizuj interwał sondowania procesów roboczych W3WP do wyższej wartości (na przykład 10 lub 30 minut) na podstawie wymagań. Ustaw HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSecondsw rejestrze i uruchom ponownie proces W3WP.

  • Jeśli zamapowany katalog fizyczny witryny internetowej ma zagnieżdżoną strukturę katalogów, możesz spróbować ograniczyć zakres powiadomień o zmianie pliku, aby zmniejszyć ilość powiadomień. Domyślnie usługi IIS używają konfiguracji z plikówWeb.config w katalogu fizycznym, do którego jest mapowany katalog wirtualny, a także w dowolnych katalogach podrzędnych w tym katalogu fizycznym. Jeśli nie chcesz używać plikówWeb.config w katalogach podrzędnych, określ falseallowSubDirConfig atrybut w katalogu wirtualnym. Więcej szczegółów można znaleźć tutaj.

    Ustaw ustawienie katalogu allowSubDirConfig wirtualnego usług IIS w Web.Config , aby wykluczyć false z zakresu zamapowane fizyczne katalogi podrzędne.

Zobacz też

Skontaktuj się z nami, aby uzyskać pomoc

Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii platformy Azure.