Przechwytywanie zrzutów pamięci na platformie Azure App Service

Artykuł
06/22/2023

Ten artykuł zawiera wskazówki dotyczące funkcji debugowania Azure App Service firmy Microsoft do przechwytywania zrzutów pamięci. Używana metoda przechwytywania jest podyktowana scenariuszem przechwytywania zrzutu pamięci w celu rozwiązania problemu z wydajnością lub dostępnością. Na przykład przechwytywanie zrzutu pamięci jest inne w przypadku procesu, w którym występuje nadmierne zużycie pamięci niż w przypadku procesu, który zgłasza wyjątki lub reaguje powoli. Procesem w tym kontekście jest proces roboczy usług Internet Information Services (IIS) (W3WP, który jest uruchamiany jako w3wp.exe).

Mapowanie scenariuszy zrzutu pamięci na funkcje debugowania Azure App Service

Poniższa tabela zawiera zalecenia dotyczące poleceń uruchamianych przez każdą funkcję App Service w celu wygenerowania zrzutu pamięci. Istnieje tak wiele podejść do przechwytywania zrzutu pamięci, że proces może być mylący. Jeśli masz już biegłą znajomość przechwytywania zrzutu pamięci W3WP, te informacje nie mają na celu zmiany podejścia. Zamiast tego mamy nadzieję dostarczyć wskazówek dla niedoświadczonych użytkowników, którzy jeszcze nie opracowali preferencji.

Scenariusz	funkcja debugowania Azure App Service	Polecenia
Brak odpowiedzi lub wolne działanie	Automatyczne naprawianie (czas trwania żądania)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`
Awaria (zakończenie procesu)	Monitorowanie awarii	Używa elementu DbgHost do przechwytywania zrzutu pamięci
Awaria (obsługiwane wyjątki)	Ślady w usłudze Application Insights/Log Analytics	Brak
Awaria (nieobsługiwane wyjątki)	Debuger migawek usługi Application Insights	Brak
Nadmierne użycie procesora CPU	Proaktywne monitorowanie procesora CPU	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`
Nadmierne zużycie pamięci	Automatyczne naprawianie (limit pamięci)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`

Uwaga

Mamy zalecenie pomocnicze dotyczące przechwytywania zrzutu pamięci procesu W3WP w scenariuszu braku odpowiedzi lub powolnego działania. Jeśli ten scenariusz jest powtarzalny i chcesz natychmiast przechwycić zrzut, możesz użyć narzędzia diagnostycznego Zbieranie zrzutu pamięci . To narzędzie znajduje się na stronie Zestaw narzędzi Diagnozowanie i rozwiązywanie problemów dla danej aplikacji internetowej App Service w Azure Portal. Inna lokalizacja do sprawdzenia pod kątem ogólnych wyjątków i niskiej wydajności znajduje się na stronie Dzienniki zdarzeń aplikacji . (Dostęp do dzienników aplikacji można również uzyskać na stronie Diagnozowanie i rozwiązywanie problemów). Wszystkie dostępne metody omówimy w sekcji "Rozwinięte Azure App Service opisy funkcji debugowania".

Opisy scenariuszy rozszerzonych procesów

Ta sekcja zawiera szczegółowe opisy sześciu scenariuszy, które są wyświetlane w poprzedniej tabeli.

Scenariusz braku odpowiedzi lub powolnego działania

Gdy żądanie jest wysyłane do serwera internetowego, zazwyczaj należy uruchomić kod. Wykonywanie kodu odbywa się w ramach procesuw3wp.exe w wątkach. Każdy wątek ma stos, który pokazuje, co jest obecnie uruchomione.

Scenariusz, który nie odpowiada, może być trwały (i prawdopodobnie upłynął limit czasu) lub powolny. W związku z tym scenariusz braku odpowiedzi jest taki, w którym uruchomienie żądania trwa dłużej niż oczekiwano. To, co możesz uznać za powolne, zależy od tego, co robi kod. Dla niektórych osób opóźnienie o trzy sekundy jest powolne. Dla innych dopuszczalne jest 15-sekundowe opóźnienie. Zasadniczo, jeśli widzisz metryki wydajności, które wskazują na spowolnienie, lub superużytkownik stwierdza, że serwer reaguje wolniej niż zwykle, to masz scenariusz nie odpowiada lub powolny.

Scenariusz awarii (zakończenia procesu)

Przez wiele lat firma Microsoft .NET Framework ulepszyła obsługę wyjątków. W bieżącej wersji platformy .NET środowisko obsługi wyjątków jest jeszcze lepsze.

W przeszłości, jeśli deweloper nie umieszczał fragmentów kodu w bloku try-catch i zgłoszono wyjątek, proces zakończył się. W takim przypadku nieobsługiwany wyjątek w kodzie dewelopera zakończył proces. Bardziej nowoczesne wersje platformy .NET obsługują niektóre z tych "nieobsługiwanych" wyjątków, dzięki czemu proces uruchamiający kod nie ulega awarii. Jednak nie wszystkie nieobsługiwane wyjątki są zgłaszane bezpośrednio z kodu niestandardowego. Na przykład naruszenia dostępu (takie jak 0xC0000005 i 0x80070005) lub przepełnienie stosu mogą zakończyć proces.

Scenariusz awarii (obsługiwanych wyjątków)

Mimo że deweloper oprogramowania szczególnie dba o określenie wszystkich możliwych scenariuszy uruchamiania kodu, może wystąpić coś nieoczekiwanego. Następujące błędy mogą wyzwolić wyjątek:

Nieoczekiwane wartości null
Nieprawidłowe rzutowanie
Brak obiektu wystąpienia

Najlepszym rozwiązaniem jest umieszczenie wykonywania kodu w blokach kodu try-catch. Jeśli deweloper korzysta z tych bloków, kod ma możliwość pomyślnego niepowodzenia, zarządzając tym, co następuje po nieoczekiwanym zdarzeniu. Obsługiwany wyjątek jest wyjątkiem, który jest zgłaszany wewnątrz bloku try i jest przechwytywany w odpowiednim bloku catch. W takim przypadku deweloper przewidział, że może wystąpić wyjątek i zakodował odpowiedni blok try-catch wokół tej sekcji kodu.

W bloku catch warto przechwycić wystarczającą ilość informacji w źródle rejestrowania, aby można było odtworzyć i ostatecznie rozwiązać problem. Wyjątki są kosztownymi ścieżkami kodu pod względem wydajności. W związku z tym posiadanie wielu wyjątków wpływa na wydajność.

Scenariusz awarii (nieobsługiwane wyjątki)

Nieobsługiwane wyjątki występują, gdy kod próbuje podjąć akcję, która nie powinna wystąpić. Podobnie jak w scenariuszu Awaria (zakończenie procesu), ten kod nie znajduje się w bloku kodu try-catch. W takim przypadku deweloper nie przewidział, że w tej sekcji kodu może wystąpić wyjątek.

Ten scenariusz różni się od dwóch poprzednich scenariuszy wyjątków. W scenariuszu Awaria (nieobsługiwane wyjątki) dany kod jest kodem napisanym przez dewelopera. To nie kod struktury zgłasza wyjątek i nie jest to jeden z nieobsługiwanych wyjątków, który zabija proces w3wp.exe . Ponadto, ponieważ kod, który zgłasza wyjątek, nie znajduje się w bloku try-catch, nie ma możliwości bezproblemowego obsługi wyjątku. Rozwiązywanie problemów z kodem jest początkowo nieco bardziej złożone. Twoim celem jest znalezienie tekstu wyjątku, typu i stosu identyfikującego metodę, która zgłasza ten nieobsługiwany wyjątek. Te informacje umożliwiają określenie, gdzie należy dodać blok kodu try-catch. Następnie deweloper może dodać podobną logikę do rejestrowania szczegółów wyjątków, które powinny istnieć w scenariuszu Awaria (nieobsługiwane wyjątki).

Scenariusz nadmiernego użycia procesora CPU

Co to jest nadmierne użycie procesora CPU? Ta sytuacja zależy od tego, co robi kod. Ogólnie rzecz biorąc, jeśli użycie procesora CPU z procesu w3wp.exe wynosi 80 procent, aplikacja znajduje się w krytycznej sytuacji, która może powodować różne objawy. Niektóre możliwe objawy są:

Powolność
Błędy
Inne niezdefiniowane zachowanie

Nawet 20-procentowe użycie procesora CPU można uznać za nadmierne, jeśli witryna internetowa dostarcza tylko statyczne pliki HTML. Rozwiązywanie problemów z nadmiernym skokiem użycia procesora CPU przez wygenerowanie zrzutu pamięci prawdopodobnie nie pomoże Ci określić określonej metody, która go używa. Najlepsze, co można zrobić, to określić, które żądania prawdopodobnie trwają najdłużej, a następnie spróbować odtworzyć problem, testując zidentyfikowaną metodę. W tej procedurze przyjęto założenie, że nie uruchamiasz monitorów wydajności w systemach wydajności, które przechwyciły ten wzrost. W wielu przypadkach możesz powodować problemy z wydajnością, ponieważ monitory są stale uruchamiane w czasie rzeczywistym.

Scenariusz nadmiernego użycia pamięci

Jeśli aplikacja jest uruchomiona w procesie 32-bitowym, nadmierne zużycie pamięci może być problemem. Nawet niewielka ilość aktywności może zużywać od 2 do 3 GB przydzielonej wirtualnej przestrzeni adresowej. Proces 32-bitowy nigdy nie może przekroczyć łącznie 4 GB, niezależnie od ilości dostępnej pamięci fizycznej.

Proces 64-bitowy jest przydzielany więcej pamięci niż proces 32-bitowy. Jest bardziej prawdopodobne, że proces 64-bitowy będzie zużywał ilość pamięci fizycznej na serwerze, niż że proces będzie zużywał przydzieloną wirtualną przestrzeń adresową.

W związku z tym to, co stanowi problem z nadmiernym zużyciem pamięci, zależy od następujących czynników:

Bitowość procesu (32-bitowa lub 64-bitowa)
Ilość użycia pamięci, która jest uważana za "normalną".

Jeśli proces zużywa więcej pamięci niż oczekiwano, zbierz zrzut pamięci do analizy, aby określić, co zużywa zasoby pamięci. Aby uzyskać więcej informacji, zobacz Tworzenie zrzutu pamięci App Service, gdy zużywa zbyt dużo pamięci.

Teraz, gdy masz nieco więcej kontekstu na temat różnych scenariuszy procesu, które mogą pomóc w rozwiązywaniu problemów z zrzutem pamięci, omówimy zalecane narzędzie do przechwytywania zrzutów pamięci na platformie Azure App Service.

Rozwinięte opisy funkcji debugowania Azure App Service

W tabeli w sekcji "Mapowanie scenariuszy zrzutu pamięci na funkcje Azure App Service debugowania" zidentyfikowaliśmy sześć funkcji debugowania, które są przeznaczone do zbierania zrzutów pamięci. Każda z tych funkcji jest dostępna z poziomu Azure Portal na stronie Diagnozowanie i rozwiązywanie problemów po wybraniu kafelka Narzędzia diagnostyczne.

W poniższych sekcjach bardziej szczegółowo omówimy każdą z tych funkcji debugowania.

Funkcja automatycznego leczenia (czas trwania żądania)

Funkcja automatycznego leczenia (czas trwania żądania) jest przydatna do przechwytywania zrzutu pamięci, jeśli zakończenie odpowiedzi trwa dłużej niż oczekiwano. Na poprzednim zrzucie ekranu na kafelku Narzędzia diagnostyczne zostanie wyświetlony link do narzędzia automatycznego leczenia. Wybierz ten link, aby przejść bezpośrednio do tej funkcji, lub wybierz kafelek Narzędzia diagnostyczne , aby przejrzeć wszystkie dostępne narzędzia na stronie Narzędzia diagnostyczne . Aby uzyskać informacje o sposobie konfigurowania tej funkcji, zobacz następujące artykuły:

Funkcja automatycznego uzdrawiania jest wyświetlana na poniższym zrzucie ekranu.

Inna funkcja o nazwie "Zbieranie zrzutu pamięci" jest przydatna w tym scenariuszu, gdy problem jest obecnie występujący lub powtarzalny. Ta funkcja szybko zbiera zrzut pamięci na żądanie ręczne.

Zbieranie funkcji zrzutu pamięci

Aby zrozumieć konfigurację funkcji zbierania zrzutu pamięci, zobacz Zbieranie usług aplikacji zrzutu pamięci. Takie podejście wymaga interwencji ręcznej. Poniższy zrzut ekranu przedstawia stronę Zbieranie zrzutu pamięci .

Aby użyć tej funkcji, wybierz konto magazynu, na którym ma być przechowywany zrzut pamięci. Następnie wybierz wystąpienie serwera, z którego chcesz zebrać zrzut pamięci. Jeśli masz więcej niż jedno wystąpienie, upewnij się, że w tym wystąpieniu występuje problem z debugowaniem. Ponadto ta konfiguracja powoduje ponowne uruchomienie aplikacji. Zwróć uwagę, że ponowne uruchomienie może nie być optymalne w aplikacji produkcyjnej, która działa.

Funkcja monitorowania awarii

Funkcja monitorowania awarii jest przydatna do przechwytywania zrzutu pamięci, jeśli nieobsługiwany wyjątek powoduje zakończenie procesu W3WP. Poniższy zrzut ekranu przedstawia stronę Monitorowanie awarii w narzędziach diagnostycznych:

Aby wyświetlić przewodnik dotyczący konfigurowania funkcji monitorowania awarii w Azure App Service, zobacz Monitorowanie awarii w Azure App Service.

Ślady w usłudze Application Insights/funkcja usługi Log Analytics

Obsługiwany wyjątek to scenariusz, w którym kod zawarty w bloku try-catch próbuje wykonać nieoczekiwaną lub nieobsługiwaną akcję. Na przykład poniższy fragment kodu próbuje podzielić liczbę przez zero, mimo że jest to niedozwolona operacja:

decimal percentage = 0, number = 1000, total = 0;
try
{
  percentage = number / total;
}
catch (DivideByZeroException divEx)
{
  _logger.LogError("A handled exception just happened: -> {divEx.Message}", divEx.Message);
}

Ten fragment kodu powoduje wyjątek dzielenia na zero, który jest obsługiwany, ponieważ nieobsługiwana operacja matematyczna jest umieszczana w bloku try-catch. Usługa Application Insights nie rejestruje obsługiwanych wyjątków, chyba że celowo uwzględnisz pakiet NuGet Microsoft.ApplicationInsights w kodzie aplikacji, a następnie dodasz kod do rejestrowania informacji. Jeśli wyjątek wystąpi po dodaniu kodu, możesz wyświetlić wpis w usłudze Log Analytics, jak pokazano na poniższym zrzucie ekranu.

Poniższy kod Kusto zawiera zapytanie, które jest używane do wyodrębniania danych z usługi Log Analytics:

traces
| where message has "handled"
 | project timestamp, severityLevel, message, operation_Name, cloud_RoleInstance

Kolumna message to lokalizacja, w której można przechowywać szczegóły wymagane do znalezienia głównej przyczyny wyjątku. Kod używany do pisania tego zapytania znajduje się w fragmencie kodu dzielenia na zero. Deweloper oprogramowania, który napisał ten kod, jest najlepszą osobą, która pyta o tego rodzaju wyjątki i atrybuty, które są niezbędne do przechwytywania w celu analizowania głównych przyczyn.

Najlepsze podejście do dodawania tej funkcji do kodu aplikacji zależy od stosu kodu aplikacji i posiadanej wersji (na przykład ASP.NET, ASP.NET Core, MVC, Razor itd.). Aby określić najlepsze podejście do danego scenariusza, zapoznaj się z tematem Rejestrowanie usługi Application Insights przy użyciu platformy .NET.

Funkcja dzienników zdarzeń aplikacji (obsługiwanych wyjątków)

Nieobsługiwane wyjątki można również znaleźć w obsługiwanym wyjątku na stronie Dzienniki zdarzeń aplikacjinarzędzi diagnostycznych w Azure Portal, jak pokazano na poniższym zrzucie ekranu.

W takiej sytuacji zostanie wyświetlony ten sam komunikat o błędzie, który został zarejestrowany za pośrednictwem kodu. Jednak tracisz pewną elastyczność w sposobie dostosowywania zapytań w dziennikach śledzenia usługi Application Insights.

Funkcja debugera migawek usługi Application Insights

Nieobsługiwane wyjątki są również rejestrowane na stronie Dzienniki zdarzeń aplikacji , jak pokazano w tekście wyjściowym w następnej sekcji. Można jednak również włączyć debuger migawki usługi Application Insights. Takie podejście nie wymaga dodania kodu do aplikacji.

Funkcja dzienników zdarzeń aplikacji (nieobsługiwanych wyjątków)

Poniższe dane wyjściowe pochodzą ze strony Dzienniki zdarzeń aplikacjinarzędzi diagnostycznych w Azure Portal. Przedstawia przykładowy tekst nieobsługiwanego wyjątku aplikacji:

Category: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
EventId: 1
SpanId: 311d8cb5d10b1a6e
TraceId: 041929768411c12f1c3f1ccbc91f6751
ParentId: 0000000000000000
RequestId: 8000006d-0001-bf00-b63f-84710c7967bb
RequestPath: /Unhandled

An unhandled exception has occurred while executing the request.

Exception:
System.DivideByZeroException: Attempted to divide by zero.
   at System.Decimal.DecCalc.VarDecDiv(DecCalc& d1, DecCalc& d2)
   at System.Decimal.op_Division(Decimal d1, Decimal d2)
   at contosotest.Pages.Pages Unhandled.ExecuteAsync()
     in C:\Users\contoso\source\repos\contosorepo\contosorepo\Pages\Unhandled.cshtml:line 12

Jedną z różnic między obsługiwanym wyjątkiem w dzienniku aplikacji jest istnienie stosu identyfikującego metodę i wiersz, z którego jest zgłaszany wyjątek. Ponadto można bezpiecznie założyć, że funkcja Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware zawiera kod umożliwiający przechwycenie tego nieobsługiwanego wyjątku, aby uniknąć zakończenia procesu. Wyjątek jest wyświetlany w usłudze Application Insights na karcie Wyjątki na stronie Błędy , jak pokazano na poniższym zrzucie ekranu.

W tym widoku zostaną wyświetlone wszystkie wyjątki, nie tylko te, których szukasz. Graficzna reprezentacja wszystkich wyjątków występujących w aplikacji jest przydatna do uzyskania przeglądu kondycji systemu. Pulpit nawigacyjny usługi Application Insights jest bardziej przydatny wizualnie w porównaniu z dziennikami zdarzeń aplikacji.

Funkcja proaktywnego monitorowania procesora CPU

W scenariuszach nadmiernego użycia procesora CPU można użyć proaktywnego narzędzia do monitorowania procesora CPU. Aby uzyskać informacje o tym narzędziu, zobacz Rozwiązywanie problemów z procesorem CPU przed ich wystąpieniem. Na poniższej ilustracji przedstawiono stronę Aktywne monitorowanie procesora CPU w narzędziach diagnostycznych.

Użycie procesora CPU w wysokości co najmniej 80 procent należy traktować jako krytyczną sytuację, która wymaga natychmiastowego zbadania. Na stronie Proaktywne monitorowanie procesora CPU można ustawić scenariusz, dla którego chcesz przechwycić zrzut pamięci na podstawie następujących kategorii monitorowania danych:

Próg procesora CPU
Sekundy progowe
Częstotliwość monitorowania

Próg procesora CPU określa, ile procesora komputera używa docelowy proces (W3WP w tym przypadku). Threshold Seconds to czas użycia procesora CPU na poziomie progu procesora CPU. Jeśli na przykład użycie procesora CPU wynosi 75% przez łącznie 30 sekund, zrzut pamięci zostanie przechwycony. Zgodnie z konfiguracją na stronie Proaktywne monitorowanie procesora CPU proces będzie sprawdzany pod kątem naruszeń progu co 15 sekund.

Funkcja automatycznego uzdrawiania (limit pamięci)

Funkcja automatycznego uzdrawiania (limit pamięci) jest przydatna do przechwytywania zrzutu pamięci, jeśli proces zużywa więcej pamięci niż oczekiwano. Ponownie zwróć uwagę na bitowość (32 lub 64). Jeśli wystąpi presja pamięci w kontekście procesu 32-bitowego i oczekiwane jest użycie pamięci, możesz rozważyć zmianę bitów na 64. Zazwyczaj w przypadku zmiany bitów należy również ponownie skompilować aplikację.

Zmiana bitów nie zmniejsza ilości używanej pamięci. Umożliwia procesowi użycie więcej niż 4 GB całkowitej pamięci. Jeśli jednak użycie pamięci nie jest zgodne z oczekiwaniami, możesz użyć tej funkcji, aby określić, co zużywa pamięć. Następnie można wykonać akcję w celu kontrolowania zużycia pamięci.

W sekcji "Rozwinięte Azure App Service opisy funkcji debugowania" na pierwszym zrzucie ekranu można zobaczyć link do funkcji automatycznego leczenia na kafelku Narzędzia diagnostyczne. Wybierz ten link, aby przejść bezpośrednio do funkcji, lub wybierz kafelek i przejrzyj wszystkie dostępne narzędzia na stronie Narzędzia diagnostyczne . Aby uzyskać więcej informacji, przejdź do sekcji "Autonaprawianie" w temacie Azure App Service diagnostics overview (Omówienie diagnostyki Azure App Service).

Funkcja automatycznego uzdrawiania jest wyświetlana na poniższym zrzucie ekranu.

Po wybraniu kafelka Limit pamięci możesz wprowadzić wartość pamięci, która wyzwala przechwytywanie zrzutu pamięci w przypadku naruszenia tego limitu pamięci. Jeśli na przykład wprowadzisz 6291456 jako wartość, zrzut pamięci procesu W3WP zostanie wykonany po użyciu 6 GB pamięci.

Funkcja zbierania zrzutu pamięci jest przydatna w tym scenariuszu, jeśli problem jest obecnie występujący lub powtarzalny. Ta funkcja szybko zbiera zrzut pamięci na żądanie ręczne. Aby uzyskać więcej informacji, zobacz sekcję "Zbieranie zrzutu pamięci ".

Rozwinięte opisy poleceń

Sztuka zbierania zrzutów pamięci zajmuje trochę czasu, aby studiować, doświadczyć i doskonały. Jak już wiesz, różne procedury są oparte na objawach wyświetlanych w procesie, jak wymieniono w tabeli w sekcji "Opisy scenariuszy rozszerzonego procesu" . Z kolei poniższa tabela porównuje polecenie przechwytywania zrzutu pamięci Azure App Service z poleceniem procdump uruchamiane ręcznie z konsoli Kudu.

Scenariusz	polecenie Azure App Service	Ogólne polecenie procdump
Brak odpowiedzi lub wolne działanie	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -n 3 -s # <PID>`
Awaria (zakończenie procesu)	Używa narzędzia DbgHost do przechwytywania zrzutu pamięci	`procdump -accepteula -ma -t <PID>`
Awaria (obsługiwane wyjątki)	Brak (Application Insights)	`procdump -accepteula -ma -e 1 -f <filter> <PID>`
Awaria (nieobsługiwane wyjątki)	Brak (debuger migawki usługi Application Insights)	`procdump -accepteula -ma -e <PID>`
Nadmierne użycie procesora CPU	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -n 3 -s # -c 80 <PID>`
Nadmierne zużycie pamięci	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -m 2000 <PID>`

Polecenia używane w funkcjach przechwytywania zrzutu pamięci w Azure App Service różnią się od poleceń procdump, które byłyby używane w przypadku ręcznego przechwytywania zrzutów. Jeśli przejrzysz poprzednią sekcję, zwróć uwagę, że funkcja portalu zbierania zrzutów pamięci w Azure App Service uwidacznia konfigurację. Na przykład w scenariuszu nadmiernego użycia pamięci w tabeli polecenie uruchamiane przez platformę nie zawiera progu pamięci. Jednak polecenie wyświetlane w ogólnej kolumnie poleceń procdump określa próg pamięci.

Narzędzie o nazwie DaaS (Diagnostyka jako usługa) jest odpowiedzialne za zarządzanie konfiguracją określoną w portalu debugowania Azure App Service i monitorowanie jej. To narzędzie jest uruchamiane jako zadanie internetowe na maszynach wirtualnych, na których jest uruchamiana aplikacja internetowa. Zaletą tego narzędzia jesttoiee określonej maszyny wirtualnej w farmie internetowej. Jeśli spróbujesz przechwycić zrzut pamięci przy użyciu protokołu procdump bezpośrednio, zidentyfikowanie, cel, dostęp i uruchomienie tego polecenia w określonym wystąpieniu może być trudne. Aby uzyskać więcej informacji na temat usługi DaaS, zobacz DaaS — Diagnostyka jako usługa dla witryn internetowych platformy Azure.

Nadmierne użycie procesora CPU to kolejny powód, dla którego platforma zarządza kolekcją zrzutów pamięci, aby była zgodna z zalecanymi wzorcami procdump. Polecenie procdump, jak pokazano w poprzedniej tabeli, zbiera trzy (-n 3) pełne zrzuty pamięci (-ma) oddalone od siebie o 30 sekund (-s #w tym # 30), gdy użycie procesora CPU jest większe lub równe 80 procent (-c 80). Na koniec należy podać identyfikator procesu (<PID>) do polecenia : procdump -accepteula -ma -n 3 -s # -c 80 <PID>.

Konfiguracja portalu jest widoczna w sekcji "Aktywne monitorowanie procesora CPU ". W przypadku zwięzłości w tej sekcji przedstawiono tylko trzy pierwsze opcje konfiguracji: próg procesora CPU (-c), próg sekund (-s) i częstotliwość monitorowania. Poniższy zrzut ekranu pokazuje, że opcje Konfigurowanie akcji, Maksymalna liczba akcji (-n) i Maksymalny czas trwania są dodatkowymi dostępnymi funkcjami.

Po przeanalizowaniu różnych metod przechwytywania zrzutów pamięci następnym krokiem jest przećwiczanie wykonywania przechwytywania. Przykładów kodu w usłudze GitHub można użyć w połączeniu z laboratoriami debugowania usług IIS i Azure Functions, aby symulować każdy ze scenariuszy wymienionych w dwóch tabelach. Po wdrożeniu kodu na platformie Azure App Service można użyć tych narzędzi do przechwytywania zrzutu pamięci w ramach każdego danego scenariusza. W czasie i po praktyce możesz doskonalić swoje podejście do przechwytywania zrzutów pamięci przy użyciu funkcji debugowania Azure App Service. Poniższa lista zawiera kilka sugestii do rozważenia w miarę dalszego poznania kolekcji zrzutów pamięci:

Przechwytywanie zrzutu pamięci zużywa znaczne zasoby systemowe i jeszcze bardziej zakłóca wydajność.
Przechwytywanie zrzutów pamięci przy pierwszej szansie nie jest optymalne, ponieważ prawdopodobnie przechwycisz zbyt wiele. Te zrzuty pamięci pierwszej szansy są najprawdopodobniej nieistotne.
Zalecamy wyłączenie usługi Application Insights przed przechwyceniem zrzutu pamięci W3WP.

Po zebraniu zrzutu pamięci następnym krokiem jest przeanalizowanie zrzutu pamięci w celu ustalenia przyczyny problemu, a następnie naprawienie tego problemu.

Następne kroki (analizowanie zrzutu pamięci)

Omówienie sposobu analizowania zrzutów pamięci wykracza poza zakres tego artykułu. Istnieje jednak wiele zasobów dla tego tematu, takich jak seria trenowania Narzędzi Defrag Tools i lista wymaganych poleceń WinDbg.

Być może na poprzednim zrzucie ekranu została zauważona opcja Konfiguruj akcję . Ustawieniem domyślnym tej opcji jest CollectAndKill. To ustawienie oznacza, że proces jest zabijany po zebraniu zrzutu pamięci. Ustawienie o nazwie CollectKillAndAnalyze analizuje zebrany zrzut pamięci. W tym scenariuszu analiza platformy może znaleźć problem, aby nie trzeba było otwierać zrzutu pamięci w usłudze WinDbg i analizować go.

Istnieją inne opcje rozwiązywania i diagnozowania problemów z wydajnością na platformie Azure App Service. W tym artykule skupiono się na zbieraniu zrzutów pamięci i przedstawiono kilka zaleceń dotyczących podejścia do diagnozy przy użyciu tych metod. Jeśli już studiowałeś, doświadczyłeś i udoskonaliłeś swoje procedury zbierania, a one działają dobrze dla Ciebie, należy nadal korzystać z tych procedur.

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.