Przechwytywanie zrzutów pamięci na platformie usługi aplikacja systemu Azure

Artykuł
11/20/2024

Ten artykuł zawiera wskazówki dotyczące funkcji debugowania usługi Microsoft aplikacja systemu Azure Service na potrzeby przechwytywania zrzutów pamięci. Używana metoda przechwytywania jest określana przez scenariusz, w którym przechwytujesz zrzut pamięci na potrzeby rozwiązywania problemów z wydajnością lub dostępnością. Na przykład przechwytywanie zrzutu pamięci różni się od procesu, który doświadcza nadmiernego użycia 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 działa jako w3wp.exe).

Mapowanie scenariuszy zrzutu pamięci na funkcje debugowania usługi aplikacja systemu Azure Service

Poniższa tabela zawiera zalecenia dotyczące poleceń uruchamianych przez każdą funkcję usługi 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 jesteś już biegły w przechwytywaniu zrzutu pamięci W3WP, te informacje nie mają na celu zmiany podejścia. Zamiast tego mamy nadzieję zapewnić wskazówki dla niedoświadczonych użytkowników, którzy jeszcze nie opracowali preferencji.

Scenariusz	funkcja debugowania usługi aplikacja systemu Azure	Polecenie
Brak odpowiedzi lub wolne	Automatyczne uzdrowienie (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 uzdrowienie (limit pamięci)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`

Uwaga 16.

Mamy dodatkowe zalecenie 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 Diagnozowanie i rozwiązywanie problemów zestawu narzędzi dla danej aplikacji internetowej usługi App Service w witrynie Azure Portal. Inną lokalizacją do sprawdzenia pod kątem ogólnych wyjątków i niskiej wydajności jest strona Dzienniki zdarzeń aplikacji. (Dostęp do dzienników aplikacji można również uzyskać z poziomu Strona Diagnozowanie i rozwiązywanie problemów). Omawiamy wszystkie dostępne metody w sekcji "Rozszerzone opisy funkcji debugowania usługi aplikacja systemu Azure Service".

Rozszerzone opisy scenariuszy procesu

Ta sekcja zawiera szczegółowe opisy sześciu scenariuszy pokazanych w poprzedniej tabeli.

Brak odpowiedzi lub powolny scenariusz

Po wysłaniu żądania do serwera internetowego należy zwykle uruchomić jakiś kod. Wykonywanie kodu odbywa się w ramach procesu w3wp.exe w wątkach. Każdy wątek ma stos pokazujący, co jest obecnie uruchomione.

Scenariusz nieodpowiadczy może być trwały (i prawdopodobnie upłynął limit czasu) lub powolny. W związku z tym scenariusz nieodpowiadczy jest taki, w którym uruchomienie żądania trwa dłużej niż oczekiwano. To, co można rozważyć, jest powolne, zależy od tego, co robi kod. Dla niektórych osób opóźnienie trzech sekund jest powolne. Dla innych dopuszczalne jest 15-sekundowe opóźnienie. W zasadzie, jeśli widzisz metryki wydajności, które wskazują spowolnienie, lub superuczesny użytkownik stwierdza, że serwer odpowiada wolniej niż zwykle, oznacza to, że scenariusz nie odpowiada lub działa wolno.

Scenariusz awarii (kończenie procesu)

W ciągu wielu lat program Microsoft .NET Framework poprawił obsługę wyjątków. W bieżącej wersji platformy .NET obsługa wyjątków jest jeszcze lepsza.

W przeszłości, jeśli deweloper nie umieścił fragmentów kodu w bloku try-catch i został zgłoszony wyjątek, proces został zakończony. W takim przypadku nieobsługiwany wyjątek w kodzie dewelopera zakończył proces. Bardziej nowoczesne wersje platformy .NET obsługują niektóre z tych wyjątków "nieobsługiwane", dzięki czemu proces, w którym jest uruchomiony 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 może zakończyć proces.

Scenariusz awarii (obsługiwane wyjątki)

Mimo że deweloper oprogramowania ma szczególną ostrożność, aby określić wszystkie możliwe scenariusze, w których działa kod, może wystąpić coś nieoczekiwanego. Następujące błędy mogą wyzwalać wyjątek:

Nieoczekiwane wartości null
Nieprawidłowe rzutowanie
Brak utworzonego obiektu

Najlepszym rozwiązaniem jest umieszczenie wykonywania kodu w blokach kodu try-catch. Jeśli deweloper korzysta z tych bloków, kod może bezpiecznie zakończyć się niepowodzeniem, zarządzając tym, co następuje po nieoczekiwanym zdarzeniu. Obsłużony wyjątek jest wyjątkiem zgłaszanym wewnątrz bloku try i jest przechwycony w odpowiednim bloku catch. W takim przypadku deweloper przewidział, że może wystąpić wyjątek i za pomocą kodu utworzy odpowiedni blok try-catch wokół tej sekcji kodu.

W bloku catch przydaje się przechwytywanie wystarczającej ilości informacji do źródła rejestrowania, dzięki czemu problem można odtworzyć i ostatecznie rozwiązać. 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 może wystąpić. Podobnie jak w scenariuszu Awaria (zakończenie procesu), ten kod nie jest zawarty w bloku kodu try-catch. W tym przypadku deweloper nie przewidział, że w tej sekcji kodu może wystąpić wyjątek.

Ten scenariusz różni się od poprzednich dwóch scenariuszy wyjątków. W scenariuszu Awaria (nieobsługiwane wyjątki) pytany kod to kod napisany przez dewelopera. Nie jest to kod struktury zgłaszający wyjątek i nie jest to jeden z nieobsługiwanych wyjątków, które zabijają proces w3wp.exe . Ponadto, ponieważ kod zgłaszający wyjątek nie znajduje się w bloku try-catch, nie ma możliwości bezpiecznego obsługi wyjątku. Rozwiązywanie problemów z kodem jest początkowo nieco bardziej złożone. Twoim celem byłoby znalezienie tekstu wyjątku, typu i stosu, który identyfikuje 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 szczegółów wyjątku dziennika, 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 jest w sytuacji krytycznej, która może powodować różne objawy. Oto niektóre możliwe objawy:

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. Pośmiertne rozwiązywanie problemów z nadmiernym wzrostem użycia procesora CPU przez wygenerowanie zrzutu pamięci prawdopodobnie nie pomoże określić konkretnej metody, która jej używa. Najlepszym rozwiązaniem jest określenie, które żądania prawdopodobnie trwały najdłużej, a następnie spróbować odtworzyć problem, testując zidentyfikowaną metodę. Ta procedura zakłada, ż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ą, stale uruchamiając monitory w czasie rzeczywistym.

Scenariusz nadmiernego zużycia pamięci

Jeśli aplikacja jest uruchomiona w procesie 32-bitowym, nadmierne użycie pamięci może być problemem. Nawet niewielka ilość działań może zużywać 2–3 GB przydzielonej wirtualnej przestrzeni adresowej. Proces 32-bitowy nigdy nie może przekroczyć łącznie 4 GB, niezależnie od dostępnej ilości 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ż proces będzie zużywać przydzieloną wirtualną przestrzeń adresową.

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

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

Jeśli proces zużywa więcej pamięci niż oczekiwano, zbierz zrzut pamięci na potrzeby analizy, aby ustalić, co zużywa zasoby pamięci. Aby uzyskać więcej informacji, zobacz Tworzenie zrzutu pamięci usługi 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 zrzut pamięci może pomóc w rozwiązywaniu problemów, omówimy zalecane narzędzie do przechwytywania zrzutów pamięci na platformie aplikacja systemu Azure Service.

Rozszerzone opisy funkcji debugowania usługi aplikacja systemu Azure Service

W tabeli w sekcji "Mapowanie scenariuszy zrzutu pamięci do aplikacja systemu Azure funkcji debugowania usługi" zidentyfikowaliśmy sześć funkcji debugowania przeznaczonych do zbierania zrzutów pamięci. Każda z tych funkcji jest dostępna z poziomu witryny Azure Portal na stronie Diagnozowanie i rozwiązywanie problemów po wybraniu kafelka Narzędzia diagnostyczne.

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

Funkcja automatycznego naprawy (czas trwania żądania)

Funkcja automatycznego naprawy (czas trwania żądania) jest przydatna do przechwytywania zrzutu pamięci, jeśli odpowiedź trwa dłużej niż oczekiwano. Link do funkcji Automatycznego naprawy można zobaczyć na kafelku Narzędzia diagnostyczne na poprzednim zrzucie ekranu. Wybierz ten link, aby przejść bezpośrednio do 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 uzdrowienia jest pokazana na poniższym zrzucie ekranu.

Inna funkcja o nazwie "Collect a Memory dump" (Zbieranie zrzutu pamięci) jest przydatna w tym scenariuszu, gdy problem występuje obecnie lub można go odtworzyć. Ta funkcja szybko zbiera zrzut pamięci na żądanie ręczne.

Zbieranie funkcji zrzutu pamięci

Takie podejście wymaga ręcznej interwencji. Poniższy zrzut ekranu przedstawia stronę Zbieranie zrzutu pamięci.

Aby użyć tej funkcji, wybierz konto magazynu, w 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 problem, który debugujesz, występuje w tym wystąpieniu. Zwróć uwagę, że ponowne uruchomienie może nie być optymalne dla aplikacji produkcyjnej działającej.

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 zapoznać się z przewodnikiem dotyczącym konfigurowania funkcji monitorowania awarii w usłudze aplikacja systemu Azure Service, zobacz Monitorowanie awarii w usłudze aplikacja systemu Azure.

Ślady w funkcji Application Insights/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ę o zero, mimo że jest to nielegalna 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 po 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 dołączysz pakiet NuGet Microsoft.ApplicationInsights do kodu aplikacji, a następnie dodaj kod, aby zarejestrować informacje. 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 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ę we fragmencie kodu dzielenia według zera. Deweloper oprogramowania, który napisał ten kod, jest najlepszą osobą, która zapyta o tego rodzaju wyjątki i atrybuty niezbędne do przechwycenia do analizowania głównych przyczyn.

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

Funkcja dzienników zdarzeń aplikacji (obsługiwane wyjątki)

Wyjątki nieobsługiwane można również znaleźć w obsługiwanym wyjątku na stronie Dzienniki zdarzeń aplikacji narzędzi diagnostycznych w witrynie 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 utracisz 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 migawek usługi Application Insights. Takie podejście nie wymaga dodania żadnego kodu do aplikacji.

Funkcja dzienników zdarzeń aplikacji (nieobsługiwane wyjątki)

Poniższe dane wyjściowe pochodzą ze strony Dzienniki zdarzeń aplikacji narzędzi diagnostycznych w witrynie Azure Portal. Przedstawia on 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 w przypadku obsługiwanego wyjątku w dzienniku aplikacji jest istnienie stosu, który identyfikuje metodę i wiersz, z którego zgłaszany jest wyjątek. Ponadto można bezpiecznie założyć, że funkcja Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware zawiera kod, aby przechwycić ten nieobsługiwany wyjątek, 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 są widoczne wszystkie wyjątki, a 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

Podczas nadmiernych scenariuszy użycia procesora CPU można użyć narzędzia proaktywnego monitorowania procesora CPU. Aby uzyskać informacje o tym narzędziu, zobacz Rozwiązywanie problemów z procesorem CPU przed ich wykonaniem. Na poniższej ilustracji przedstawiono stronę Proaktywne monitorowanie procesora CPU w narzędziach diagnostycznych.

Należy rozważyć użycie procesora CPU o 80 procent lub więcej 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
Próg sekund
Częstotliwość monitorowania

Próg procesora CPU określa, ile procesora CPU komputera używa docelowy proces (W3WP w tym przypadku). Próg sekund to czas użycia procesora CPU na progu procesora CPU. Na przykład w przypadku 75-procentowego użycia procesora CPU 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ń progów co 15 sekund.

Funkcja automatycznego naprawy (limit pamięci)

Funkcja automatycznego naprawy (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 bitność (32 lub 64). Jeśli w kontekście procesu 32-bitowego wystąpi użycie pamięci, a użycie pamięci jest oczekiwane, rozważ zmianę bitowości na 64. Zazwyczaj w przypadku zmiany bitowości należy również ponownie skompilować aplikację.

Zmiana bitowości nie zmniejsza ilości używanej pamięci. Umożliwia to procesowi użycie ponad 4 GB całkowitej pamięci. Jeśli jednak użycie pamięci nie jest zgodnie z oczekiwaniami, możesz użyć tej funkcji, aby określić, co zużywa pamięć. Następnie możesz podjąć akcję w celu kontrolowania zużycia pamięci.

W sekcji "Rozszerzone opisy funkcji debugowania usługi aplikacja systemu Azure" na pierwszym zrzucie ekranu można zobaczyć link do funkcji Automatycznego naprawy na kafelku Narzędzia diagnostyczne. Wybierz ten link, aby przejść bezpośrednio do funkcji, lub wybrać kafelek i przejrzeć wszystkie dostępne narzędzia na stronie Narzędzia diagnostyczne. Aby uzyskać więcej informacji, przejdź do sekcji "Automatyczne naprawianie" w aplikacja systemu Azure Service diagnostics overview (Omówienie diagnostyki usługi aplikacja systemu Azure Service).

Funkcja automatycznego uzdrowienia jest pokazana na poniższym zrzucie ekranu.

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

Funkcja Zbierania zrzutu pamięci jest przydatna w tym scenariuszu, jeśli problem występuje obecnie lub można go odtworzyć. 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 kolekcji zrzutów pamięci zajmuje trochę czasu na naukę, doświadczenie i doskonałość. Jak już wiesz, różne procedury są oparte na objawach wyświetlanych przez proces, jak pokazano w tabeli w sekcji "Rozszerzone opisy scenariuszy procesu". Z kolei w poniższej tabeli porównano polecenie przechwytywania zrzutu pamięci usługi aplikacja systemu Azure service z poleceniem procdump uruchamianym ręcznie z konsoli Kudu.

Scenariusz	polecenie aplikacja systemu Azure Service	Ogólne polecenie procdump
Brak odpowiedzi lub wolne	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -n 3 -s # <PID>`
Awaria (zakończenie procesu)	Używa elementu 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 migawek 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 funkcji przechwytywania zrzutu pamięci w usłudze aplikacja systemu Azure Service różnią się od poleceń procdump używanych w przypadku ręcznego przechwycenia zrzutów. Jeśli zapoznasz się z poprzednią sekcją, zauważysz, że funkcja portalu zbierania zrzutów pamięci w usłudze aplikacja systemu Azure uwidacznia konfigurację. Na przykład w scenariuszu nadmiernego zużycia pamięci w tabeli polecenie uruchamiane przez platformę nie zawiera progu pamięci. Jednak polecenie wyświetlane w ogólnej kolumnie polecenia 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 usługi aplikacja systemu Azure i monitorowanie jej. To narzędzie jest uruchamiane jako zadanie internetowe na maszynach wirtualnych, które uruchamiają aplikację internetową. Zaletą tego narzędzia jest możliwość kierowania określonej maszyny wirtualnej w farmie internetowej. Jeśli spróbujesz przechwycić zrzut pamięci przy użyciu narzędzia procdump bezpośrednio, może to być trudne, aby zidentyfikować, użyć elementu docelowego, dostępu i uruchomić to polecenie w określonym wystąpieniu. Aby uzyskać więcej informacji na temat języka DaaS, zobacz DaaS — diagnostyka jako usługa dla witryn internetowych platformy Azure.

Nadmierne użycie procesora CPU jest kolejnym powodem, dla którego platforma zarządza kolekcją zrzutów pamięci, tak aby były zgodne z zalecanymi wzorcami procdump. Polecenie procdump, jak pokazano w poprzedniej tabeli, zbiera trzy zrzuty-n 3 pełnej pamięci () (-ma) 30 sekund od siebie (-s #w którym # jest 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>.

Konfigurację portalu można zobaczyć w sekcji "Proaktywne 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 ilustruje, że konfigurowanie akcji, maksymalnych akcji (-n) i maksymalny czas trwania są dodatkowymi dostępnymi funkcjami.

Po zbadaniu różnych podejść do przechwytywania zrzutów pamięci następnym krokiem jest przećwiczyć wykonywanie przechwytywania. Przykłady kodu w usłudze GitHub można używać w połączeniu z laboratoriami debugowania usług IIS i usługą Azure Functions, aby symulować poszczególne scenariusze wymienione w dwóch tabelach. Po wdrożeniu kodu na platformie usługi aplikacja systemu Azure można użyć tych narzędzi do przechwytywania zrzutu pamięci w każdym scenariuszu. W czasie i po praktyce możesz udoskonalić podejście do przechwytywania zrzutów pamięci przy użyciu funkcji debugowania usługi aplikacja systemu Azure Service. Poniższa lista zawiera kilka sugestii, które należy wziąć pod uwagę podczas dalszego poznawania 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 na 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, aby określić przyczynę problemu, a następnie rozwiązać ten problem.

Następne kroki (analizowanie zrzutu pamięci)

Omawianie sposobu analizowania zrzutów pamięci wykracza poza zakres tego artykułu. Jednak istnieje wiele zasobów dla tego tematu, takich jak seria szkoleniowa Narzędzia Defrag Tools i lista poleceń windbg musi być znane.

Na poprzednim zrzucie ekranu może zostać wyświetlona opcja Konfiguruj akcję . Ustawieniem domyślnym dla tej opcji jest CollectAndKill. To ustawienie oznacza, że proces zostanie zabity 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 aplikacja systemu Azure Service. Ten artykuł koncentruje się na kolekcji zrzutów pamięci i udostępnia kilka zaleceń dotyczących podejścia do diagnostyki przy użyciu tych metod. Jeśli już przeanalizowaliśmy, doświadczyłeś i udoskonaliłeś procedury zbierania, a one działają dobrze, należy nadal używać 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 na temat platformy Azure.

Udostępnij za pośrednictwem