Udostępnij za pośrednictwem

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

  • Artykuł

Uwaga 16.

CentOS, do których odwołuje się ten artykuł, jest dystrybucją systemu Linux i osiągnie koniec życia (EOL). Rozważ odpowiednie użycie i zaplanuj. Aby uzyskać więcej informacji, zobacz CentOS End Of Life guidance (Wskazówki dotyczące zakończenia życia systemu CentOS).

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

Dotyczy

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

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

Najpierw wyklucz niektóre typowe przyczyny problemów z wydajnością.

Korzystasz ze starego systemu operacyjnego

Jeśli maszyna wirtualna klienta korzysta z systemu Windows 8.1 lub Windows Server 2012 R2 lub starszej dystrybucji systemu Linux lub jądra systemu Linux, mogą wystąpić problemy z wydajnością podczas uzyskiwania dostępu do udziałów plików platformy Azure. Uaktualnij system operacyjny klienta lub zastosuj poniższe poprawki.

Zagadnienia dotyczące systemów Windows 8.1 i Windows Server 2012 R2

Klienci z systemem Windows 8.1 lub Windows Server 2012 R2 mogą widzieć 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ść operacji 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 16.

Obrazy systemu Windows Server 2012 R2 w witrynie Azure Marketplace mają domyślnie zainstalowane poprawki KB3114025 począwszy od grudnia 2015 r.

Obciążenie jest ograniczane

Żądania są ograniczane, gdy osiągnięto limity operacji we/wy na sekundę (IOPS), ruchu przychodzącego lub wychodzącego dla udziału plików. Jeśli na przykład klient przekroczy liczbę operacji we/wy na sekundę według planu bazowego, zostanie on ograniczony przez usługę Azure Files. Ograniczanie przepustowości może spowodować, że klient ma niską wydajność.

Aby zrozumieć limity udziałów plików standardowych i premium, zobacz Cele udziału plików i skalowania plików. W zależności od obciążenia ograniczania przepustowości można często uniknąć, przechodząc z udziałów plików standardowych do premium platformy Azure.

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

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

Przyczyna 1. Udostępnianie lub konto magazynu jest ograniczane

Aby sprawdzić, czy udział lub konto magazynu jest ograniczane, możesz uzyskać dostęp do metryk platformy Azure i korzystać z nich w portalu. Możesz również utworzyć alerty, które powiadomią Cię, jeśli udział jest ograniczany lub ma zostać ograniczony. Zobacz Rozwiązywanie problemów z usługą Azure Files, tworząc alerty.

Ważne

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

  1. Przejdź do swojego konta magazynu w witrynie Azure Portal.

  2. W lewym okienku w obszarze Monitorowanie wybierz pozycję Metryki.

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

  4. Wybierz Transakcje jako metrykę.

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

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

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    W przypadku udziałów plików premium, rejestrowane są następujące typy odpowiedzi, jeśli żądanie jest ograniczane 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 metryki.

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

Rozwiązanie

Jeśli używasz udziału plików w warstwie Premium, zwiększ aprowizowany rozmiar 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 skoncentrowana na metadanych (na przykład createfile, openfile, closefile, queryinfo lub querydirectory), opóźnienie będzie większe niż w przypadku operacji odczytu/zapisu.

Aby ustalić, czy większość żądań jest skoncentrowana na metadanych, zacznij od wykonania kroków 1–4 zgodnie z wcześniejszym opisem w sekcji Przyczyna 1. W kroku 5 zamiast dodawania filtru dla typu odpowiedzi 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ę, aby zmniejszyć liczbę operacji metadanych.

  • Jeśli używasz udziałów plików SMB platformy Azure w warstwie Premium, użyj pamięci podręcznej (cache) metadanych.

  • Rozdziel udział plików na wiele udziałów plików w ramach tego samego konta magazynu.

  • Dodaj wirtualny dysk twardy (VHD) w udziale plików i zainstaluj dysk VHD z klienta, aby wykonać operacje na plikach względem danych. Takie podejście działa w przypadku scenariuszy z jednym edytorem/czytelnikiem lub scenariuszy z wieloma czytelnikami i bez edytorów. Ponieważ system plików jest własnością klienta, a nie usługi Azure Files, umożliwia to wykonywanie operacji metadanych na komputerze lokalnym. Konfiguracja oferuje wydajność podobną do lokalnej bezpośrednio dołączonej pamięci masowej. Jednak ze względu na to, że dane są w wirtualnym dysku twardym, nie można uzyskać do nich dostępu za pośrednictwem innych metod niż instalacja protokołu SMB, takich jak interfejs API REST lub witryna Azure Portal.

    1. Z komputera, który 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 > Utwórz dysk 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 i wybierz pozycję Stały rozmiar.
    4. Wybierz przycisk OK. Po zakończeniu tworzenia dysku VHD zostanie on automatycznie zamontowany i pojawi się nowy nieprzydzielony dysk.
    5. Kliknij prawym przyciskiem myszy nowy nieznany dysk i wybierz polecenie Zainicjuj dysk.
    6. Kliknij prawym przyciskiem myszy nieprzydzielony obszar i utwórz nowy wolumin prosty.
    7. W obszarze Zarządzanie dyskami powinna zostać wyświetlona nowa litera dysku reprezentująca ten VHD z dostępem do odczytu/zapisu (na przykład E:). W Eksploratorze plików nowy VHD powinien być widoczny na zmapowanym 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 w systemie Z:i mapowanie wirtualnego dysku twardego na dysku E:.
    8. W przypadku dużych operacji metadanych na dysku zmapowanym VHD (E:) powinna być znacznie wyższa wydajność niż na dysku zmapowanym udziału plików platformy Azure (Z:). W razie potrzeby należy odłączyć zmapowany dysk sieciowy (Z:) i nadal korzystać z zainstalowanego dysku VHD (E:).
    • Aby zainstalować dysk VHD na kliencie systemu Windows, możesz również użyć polecenia cmdlet programu PowerShell Mount-DiskImage.
    • 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 niższą przepływność operacji we/wy na sekundę niż maksymalna możliwa przepływność, w zależności od aprowizowanego rozmiaru 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 jest to możliwe, równoległość. Na przykład w przypadku operacji kopiowania można użyć narzędzia AzCopy lub narzędzia RoboCopy z klientów systemu Windows lub równoległego polecenia z klientów systemu Linux.

Przyczyna 4. Liczba kanałów SMB przekracza cztery

Jeśli używasz protokołu SMB MultiChannel i liczba kanałów, które przekroczyły 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 Systemu Windows na kartę sieciową 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 za mały (tylko system plików NFS)

Począwszy od jądra systemu Linux w wersji 5.4, klient systemu plików NFS systemu Linux używa wartości domyślnej read_ahead_kb 128 kibibajtów (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 mebibajtów (MiB). Aby zmienić tę wartość, należy ustawić rozmiar z wyprzedzeniem odczytu w sposób trwały, dodając regułę w ujściu, menedżera urządzeń jądra systemu Linux. Wykonaj te kroki:

  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 uświadomić sobie nowy plik, 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. Inne przyczyny dużego opóźnienia mogą być spowodowane opóźnieniem spowodowanym 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 witrynie Azure Portal. Duża różnica między wartościami metryk SuccessE2ELatency i SuccessServerLatency jest wskazaniem opóźnienia, które jest spowodowane przez sieć lub klienta. Zobacz Metryki transakcji w dokumentacji danych monitorowania usługi Azure Files.

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

Przyczyna

Jedną z potencjalnych przyczyn jest brak obsługi wielokanałowej protokołu SMB dla standardowych udziałów plików. Obecnie usługa Azure Files obsługuje tylko jeden kanał dla standardowych udziałów plików, więc istnieje tylko jedno połączenie z maszyny wirtualnej klienta do serwera. To pojedyncze połączenie jest powiązane z jednym rdzeniem na maszynie wirtualnej klienta, więc maksymalna przepływność osiągalna z maszyny wirtualnej jest powiązana przez jeden rdzeń.

Rozwiązanie

Niska wydajność w udziale usługi Azure File zainstalowanym 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, jeśli wielokrotnie uzyskujesz dostęp do pliku. W przeciwnym razie może to być obciążenie. Przed jego wyłączeniem sprawdź, czy używasz pamięci podręcznej.

Rozwiązanie dla 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 opcję cache=strict do polecenia instalacji, aby upewnić się, że domyślne buforowanie lub „ścisły” tryb buforowania jest włączony.

W niektórych scenariuszach opcja instalacji serverino może spowodować, że polecenie ls zostanie uruchomione stat dla każdego wpisu katalogu. To zachowanie powoduje obniżenie wydajności podczas wyświetlania listy 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 poprawne opcje, uruchamiając polecenie sudo mount | grep cifs i sprawdzając jego dane wyjściowe. Poniżej przedstawiono przykład:

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

Jeśli opcja cache=strict lub serverino nie jest obecna, odinstaluj i zainstaluj ponownie usługę Azure Files, uruchamiając polecenie instalacji z dokumentacji. Następnie ponownie sprawdź, czy wpis /etc/fstab ma poprawne opcje.

Przyczyna 2. Ograniczanie przepustowości

Istnieje możliwość ograniczenia 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żesz również utworzyć alerty, które powiadamiają o tym, czy udział jest ograniczany lub ma zostać ograniczony. Zobacz Rozwiązywanie problemów z usługą Azure Files, tworząc alerty.

Rozwiązanie dla przyczyny 2

Upewnij się, że aplikacja znajduje się w celach skalowania usługi Azure Files. 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 z systemem Windows

Przyczyna

Jest to znany problem z implementacją klienta SMB w systemie Linux.

Rozwiązanie

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

Duże opóźnienia w przypadku obciążeń z dużym obciążeniem metadanych obejmujących rozległe operacje otwierania/zamykania

Przyczyna

Brak obsługi dzierżaw katalogów.

Rozwiązanie

  • Jeśli to możliwe, należy unikać nadmiernego otwierania/zamykania uchwytu 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 może pomóc większa wartość, taka jak 30 sekund.
  • W przypadku maszyn wirtualnych 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 komputerze klienckim nie ma wystarczającej ilości pamięci podręcznej dla dużych katalogów.

Rozwiązanie

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

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

Można na przykład ustawić ją na wartość 0x100000 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 być widoczna niska wydajność. Jeśli nie masz określonego minimalnego wymagania dotyczącego rozmiaru we/wy, zalecamy użycie 1 MiB jako rozmiaru we/wy w celu uzyskania optymalnej wydajności.

Slow file copying to and from Azure Files in Windows (Wolne kopiowanie plików do i z usługi Azure Files w systemie Windows)

  • Jeśli znasz ostateczny rozmiar pliku, który rozszerzasz za pomocą zapisów, a twoje oprogramowanie nie ma problemów z kompatybilnością, gdy niezapisany końcowy fragment pliku zawiera zera, ustaw rozmiar pliku z wyprzedzeniem, zamiast wykonywać każdy zapis jako zapis rozszerzający.

  • 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.

Nadmierne wywołania DirectoryOpen/DirectoryClose

Przyczyna

Jeśli liczba wywołań DirectoryOpen/DirectoryClose jest jednym z najczęstszych wywołań interfejsu API i nie oczekujesz, że klient wykona tak wiele wywołań, problem może być spowodowany przez oprogramowanie antywirusowe zainstalowane na maszynie wirtualnej klienta platformy Azure.

Rozwiązanie

Poprawka tego problemu jest dostępna w kwietniowej aktualizacji platformy dla systemu Windows.

Funkcja SMB Multichannel nie jest wyzwalana

Przyczyna

Ostatnie zmiany ustawień konfiguracji SMB Multichannel bez ponownego zainstalowania.

Rozwiązanie

  • Po wprowadzeniu zmian w ustawieniach konfiguracji wielokanałowej SMB klienta lub konta SMB systemu Windows należy odinstalować udział, poczekać 60 sekund i ponownie zainstalować udział, aby wyzwolić wielokanałowość.
  • W przypadku systemu operacyjnego klienta systemu Windows wygeneruj obciążenie operacjami we/wy z dużą głębokością kolejki, na przykład skopiowanie pliku w celu wyzwolenia funkcji SMB Multichannel. W przypadku systemu operacyjnego serwera funkcja SMB Multichannel jest wyzwalana z funkcją QD=1, co oznacza, że natychmiast po uruchomieniu dowolnego we/wy udziału.

Niska wydajność podczas rozpakowywania plików

W zależności od dokładnej metody kompresji i operacji rozpakowywania operacje dekompresacji mogą działać wolniej w udziale plików platformy Azure niż na dysku lokalnym. Jest to często spowodowane tym, że rozpakowywanie narzędzi wykonuje wiele operacji metadanych w procesie dekompresacji skompresowanego archiwum. Aby uzyskać najlepszą wydajność, zalecamy skopiowanie skompresowanego archiwum z udziału plików platformy Azure do dysku lokalnego, rozpakowanie tam, 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 usłudze Azure Files względem dysku lokalnego przy użyciu wielu wątków w celu równoległego kopiowania danych.

Duże opóźnienie w witrynach internetowych hostowanych w udziałach plików

Przyczyna

Powiadomienie o zmianie pliku o dużej liczbie udziałów plików może spowodować duże opóźnienia. Dzieje się tak zwykle w przypadku witryn internetowych hostowanych w udziałach plików z głęboką strukturą katalogów zagnieżdżonych. Typowym scenariuszem jest hostowana aplikacja internetowa usług IIS, w której dla każdego katalogu w konfiguracji domyślnej jest konfigurowane powiadomienie o zmianie pliku. Każda zmiana (ReadDirectoryChangesW) w udziale, który klient jest zarejestrowany w celu wypychania powiadomienia o zmianie z usługi plików do klienta, który pobiera zasoby systemowe, a problem pogarsza się wraz z liczbą zmian. Może to spowodować ograniczenie udziału, a tym samym zwiększyć opóźnienie po stronie klienta.

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

  1. Przejdź do swojego konta magazynu w witrynie Azure Portal.
  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 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 architektury 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ć wolumin.

    Zaktualizuj interwał sondowania procesu roboczego W3WP na wyższą wartość (na przykład 10 lub 30 minut) na podstawie wymagań. Ustaw HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds w rejestrze i uruchom ponownie proces W3WP.

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

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

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 na temat platformy Azure.