Samla in minnesdumpar på Azure App Service-plattformen

Artikel
06/03/2024

Den här artikeln innehåller vägledning om felsökningsfunktioner i Microsoft Azure App Service för att samla in minnesdumpar. Avbildningsmetoden som du använder styrs av scenariot där du samlar in en minnesdump för att felsöka ett prestanda- eller tillgänglighetsproblem. Att till exempel samla in en minnesdump skiljer sig åt för en process som har för hög minnesförbrukning än för en process som genererar undantag eller svarar långsamt. Processen i det här sammanhanget är IIS-arbetsprocessen (W3WP) (Internet Information Services), som körs somw3wp.exe).

Mappa minnesdumpscenarier till felsökningsfunktioner i Azure App Service

Följande tabell innehåller rekommendationer om de kommandon som varje App Service-funktion kör för att generera en minnesdump. Det finns så många metoder för att samla in en minnesdump att processen kan vara förvirrande. Om du redan är skicklig på att samla in en W3WP-minnesdump är den här informationen inte avsedd att ändra din metod. I stället hoppas vi kunna ge vägledning för oerfarna användare som ännu inte har utvecklat en inställning.

Scenario	Felsökningsfunktion för Azure App Service	Kommando
Svarar inte eller är långsam	Reparera automatiskt (varaktighet för begäran)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`
Krasch (processavslut)	Kraschövervakning	Använder DbgHost för att avbilda en minnesdump
Krasch (hanterade undantag)	Spårningar i Application Insights/Log Analytics	Inga
Krasch (ohanterade undantag)	Application Insights Snapshot Debugger	Inga
Överdriven CPU-användning	Proaktiv CPU-övervakning	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`
Överdriven minnesförbrukning	Reparera automatiskt (minnesgräns)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`

Obs!

Vi har en sekundär rekommendation för att samla in en W3WP-processminnesdump i scenariot som inte svarar eller är långsamt. Om det scenariot är reproducerbart och du vill avbilda dumpen omedelbart kan du använda diagnostikverktyget Samla in en minnesdump . Det här verktyget finns på sidan Diagnostisera och lösa problemverktyg för den angivna App Service-webbappen i Azure-portalen. En annan plats där du kan söka efter allmänna undantag och dåliga prestanda finns på sidan Programhändelseloggar . (Du kan även komma åt programloggar från sidan Diagnostisera och lösa problem .) Vi diskuterar alla tillgängliga metoder i avsnittet "Utökade funktionsbeskrivningar för Felsökning av Azure App Service" .

Beskrivningar av expanderat processscenario

Det här avsnittet innehåller detaljerade beskrivningar av de sex scenarier som visas i föregående tabell.

Scenario som inte svarar eller är långsamt

När en begäran görs till en webbserver måste en del kod vanligtvis köras. Kodkörningen sker inom w3wp.exe processen på trådar. Varje tråd har en stack som visar vad som körs för närvarande.

Ett scenario som inte svarar kan vara antingen permanent (och sannolikt överskrida tidsgränsen) eller långsamt. Därför är scenariot som inte svarar ett scenario där en begäran tar längre tid än förväntat att köras. Vad du kan överväga att vara långsam beror på vad koden gör. För vissa är en fördröjning på tre sekunder långsam. För andra är en fördröjning på 15 sekunder acceptabel. Om du ser prestandamått som indikerar långsamhet, eller om en superanvändare säger att servern svarar långsammare än normalt, har du ett scenario som inte svarar eller är långsamt.

Kraschscenario (processavslut)

Under många år har Microsoft .NET Framework förbättrat hanteringen av undantag. I den aktuella versionen av .NET är undantagshanteringsupplevelsen ännu bättre.

Tidigare, om en utvecklare inte placerade kodfragment i ett try-catch-block och ett undantag utlöstes, avslutades processen. I så fall avslutades processen med ett ohanterat undantag i utvecklarkoden. Modernare versioner av .NET hanterar några av dessa "ohanterade" undantag så att processen som kör koden inte kraschar. Alla ohanterade undantag genereras dock inte direkt från den anpassade koden. Åtkomstöverträdelser (till exempel 0xC0000005 och 0x80070005) eller ett stackspill kan till exempel avsluta processen.

Kraschscenario (hanterade undantag)

Även om en programutvecklare är särskilt noga med att fastställa alla möjliga scenarier där koden körs, kan något oväntat inträffa. Följande fel kan utlösa ett undantag:

Oväntade null-värden
Ogiltig gjutning
Ett instansierat objekt saknas

Det är bästa praxis att placera kodkörning i try-catch-kodblock. Om en utvecklare använder dessa block har koden möjlighet att misslyckas korrekt genom att specifikt hantera vad som följer den oväntade händelsen. Ett hanterat undantag är ett undantag som genereras i ett försöksblock och fångas i motsvarande catch-block. I det här fallet förväntade sig utvecklaren att ett undantag kunde inträffa och kodade ett lämpligt try-catch-block runt det kodavsnittet.

I catch-blocket är det användbart att samla in tillräckligt med information i en loggningskälla så att problemet kan återskapas och slutligen lösas. Undantag är dyra kodsökvägar när det gäller prestanda. Därför påverkar många undantag prestanda.

Kraschscenario (ohanterade undantag)

Ohanterade undantag inträffar när kod försöker vidta en åtgärd som den inte förväntar sig att stöta på. Precis som i kraschscenariot (processavslut) finns den koden inte i ett try-catch-kodblock. I det här fallet förväntade sig inte utvecklaren att ett undantag skulle kunna inträffa i det kodavsnittet.

Det här scenariot skiljer sig från de föregående två undantagsscenarierna. I scenariot Krasch (ohanterade undantag) är koden i fråga den kod som utvecklaren skrev. Det är inte ramverkskoden som utlöser undantaget, och det är inte ett av de ohanterade undantagen som stoppar w3wp.exe processen. Eftersom koden som utlöser ett undantag inte finns inom ett try-catch-block finns det ingen möjlighet att hantera undantaget på ett smidigt sätt. Felsökning av koden är inledningsvis lite mer komplext. Målet är att hitta undantagstexten, typen och stacken som identifierar metoden som genererar det här ohanterade undantaget. Med den här informationen kan du identifiera var du måste lägga till try-catch-kodblocket. Utvecklaren kan sedan lägga till liknande logik för att logga undantagsinformation som ska finnas i kraschscenariot (ohanterade undantag).

Scenario med överdriven CPU-användning

Vad är överdriven CPU-användning? Den här situationen beror på vad koden gör. Om processoranvändningen från denw3wp.exe processen i allmänhet är 80 procent befinner sig programmet i en kritisk situation som kan orsaka olika symptom. Några möjliga symtom är:

Långsamhet
Fel
Annat odefinierat beteende

Även en 20-procentig CPU-användning kan betraktas som överdriven om webbplatsen bara levererar statiska HTML-filer. Felsökning efter döden av en överdriven CPU-topp genom att generera en minnesdump hjälper dig förmodligen inte att fastställa den specifika metod som använder den. Det bästa du kan göra är att avgöra vilka begäranden som sannolikt tog längst tid och sedan försöka återskapa problemet genom att testa den identifierade metoden. Den proceduren förutsätter att du inte kör prestandaövervakare på de prestandasystem som registrerade den bursten. I många fall kan du orsaka prestandaproblem genom att hela tiden låta övervakare köras i realtid.

Scenario med överdriven minnesförbrukning

Om ett program körs i en 32-bitarsprocess kan överdriven minnesförbrukning vara ett problem. Även en liten mängd aktivitet kan förbruka 2–3 GB allokerat virtuellt adressutrymme. En 32-bitarsprocess får aldrig överstiga totalt 4 GB, oavsett hur mycket fysiskt minne som är tillgängligt.

En 64-bitarsprocess tilldelas mer minne än en 32-bitarsprocess. Det är mer troligt att 64-bitarsprocessen förbrukar mängden fysiskt minne på servern än att processen förbrukar det allokerade virtuella adressutrymmet.

Vad som utgör ett överdrivet minnesförbrukningsproblem beror därför på följande faktorer:

Processbitness (32-bitars eller 64-bitars)
Mängden minnesanvändning som anses vara "normal".

Om din process förbrukar mer minne än förväntat samlar du in en minnesdump för analys för att avgöra vad som förbrukar minnesresurser. Mer information finns i Skapa en minnesdump av din App Service när den förbrukar för mycket minne.

Nu när du har lite mer kontext om de olika processscenarier som en minnesdump kan hjälpa dig att felsöka, diskuterar vi det rekommenderade verktyget för att samla in minnesdumpar på Azure App Service-plattformen.

Utökade funktionsbeskrivningar för Felsökning av Azure App Service

I tabellen i avsnittet "Mappa minnesdumpscenarier till Azure App Service-felsökningsfunktioner" identifierade vi sex felsökningsfunktioner som är avsedda att samla in minnesdumpar. Var och en av dessa funktioner är tillgänglig från Azure-portalen på sidan Diagnostisera och lösa problem när du väljer panelen Diagnostikverktyg .

I följande avsnitt diskuterar vi var och en av dessa felsökningsfunktioner i detalj.

Funktionen Reparera automatiskt (varaktighet för begäran)

Funktionen för automatisk läkning (varaktighet för begäran) är användbar för att samla in en minnesdump om svaret tar längre tid än förväntat att slutföras. Du kan se länken till Auto-Heal i panelen Diagnostikverktyg i föregående skärmbild. Välj länken för att gå direkt till funktionen eller välj panelen Diagnostikverktyg för att granska alla tillgängliga verktyg på sidan Diagnostikverktyg . Information om hur du konfigurerar den här funktionen finns i följande artiklar:

Funktionen för automatisk läkning visas i följande skärmbild.

En annan funktion med namnet "Samla in en minnesdump" är användbar i det här scenariot när problemet för närvarande uppstår eller återskapas. Den här funktionen samlar snabbt in en minnesdump på manuell begäran.

Samla in en minnesdumpfunktion

Information om konfigurationen av funktionen Samla in en minnesdump finns i Samla in apptjänster för minnesdump. Den här metoden kräver manuella åtgärder. Följande skärmbild visar sidan Samla in en minnesdump .

Om du vill använda funktionen väljer du ett lagringskonto där minnesdumpen ska lagras. Välj sedan vilken serverinstans du vill samla in minnesdumpen från. Om du har mer än en enda instans kontrollerar du att problemet som du felsöker inträffar på den instansen. Observera att en omstart kanske inte är optimal för ett produktionsprogram som är i drift.

Funktionen Kraschövervakning

Funktionen Kraschövervakning är användbar för att samla in en minnesdump om ett ohanterat undantag gör att W3WP-processen avslutas. Följande skärmbild visar sidan Kraschövervakning i Diagnostikverktyg:

En guidad genomgång av hur du konfigurerar funktionen för kraschövervakning i Azure App Service finns i Kraschövervakning i Azure App Service.

Spårningar i Application Insights/Log Analytics-funktionen

Ett hanterat undantag är ett scenario där koden som finns i ett try-catch-block försöker vidta en åtgärd som är oväntad eller inte stöds. Följande kodfragment försöker till exempel dividera ett tal med noll trots att det här är en olaglig åtgärd:

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);
}

Det här kodfragmentet orsakar ett divide-by-zero-undantag som hanteras eftersom den matematiska åtgärden som inte stöds placeras i ett try-catch-block. Application Insights loggar inte hanterade undantag om du inte avsiktligt inkluderar NuGet-paketet Microsoft.ApplicationInsights i programkoden och sedan lägger till koden för att logga informationen. Om undantaget inträffar när du har lagt till koden kan du visa posten i Log Analytics, som du ser i följande skärmbild.

Följande Kusto-kod innehåller frågan som används för att extrahera data från Log Analytics:

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

Kolumnen message är den plats där du kan lagra den information som krävs för att hitta rotorsaken till undantaget. Koden som används för att skriva den här frågan finns i kodfragmentet division-by-zero. Programutvecklaren som skrev den här koden är den bästa personen att fråga om den här typen av undantag och de attribut som krävs för att samla in för att analysera rotorsaker.

Den bästa metoden för att lägga till den här funktionen i programkoden beror på den programkodsstack och version som du har (till exempel ASP.NET, ASP.NET Core, MVC, Razor och så vidare). Om du vill fastställa den bästa metoden för ditt scenario läser du Application Insights-loggning med .NET.

Funktion för programhändelseloggar (hanterade undantag)

Du kan också hitta ohanterade undantag i det hanterade undantaget på sidan Programhändelseloggar i Diagnostikverktyg i Azure-portalen, enligt följande skärmbild.

I det här fallet får du samma felmeddelande som du loggade genom koden. Du förlorar dock viss flexibilitet när det gäller hur du kan anpassa frågorna i Application Insights-spårningsloggar.

Application Insights Snapshot Debugger-funktion

Ohanterade undantag loggas också på sidan Programhändelseloggar , som du ser i utdatatexten i nästa avsnitt. Du kan dock även aktivera Application Insights Snapshot Debugger. Den här metoden kräver inte att du lägger till någon kod i ditt program.

Funktion för programhändelseloggar (ohanterade undantag)

Följande utdata kommer från sidan Programhändelseloggar i Diagnostikverktyg i Azure-portalen. Den visar exempeltext för ett ohanterat programfel:

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

En skillnad här jämfört med det hanterade undantaget i programloggen är förekomsten av stacken som identifierar metoden och den rad som undantaget genereras från. Du kan också på ett säkert sätt anta att funktionerna Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware innehåller kod för att fånga upp det här ohanterade undantaget så att processen avslutas. Undantaget visas i Application Insights på fliken Undantag på sidan Fel , som du ser i följande skärmbild.

I den här vyn visas alla undantag, inte bara de som du söker efter. Den grafiska representationen av alla undantag som inträffar i ditt program är användbar för att få en översikt över systemets hälsotillstånd. Application Insights-instrumentpanelen är mer användbar visuellt jämfört med programhändelseloggarna.

Proaktiv cpu-övervakningsfunktion

Under scenarier med överdriven CPU-användning kan du använda det proaktiva verktyget för CPU-övervakning. Information om det här verktyget finns i Åtgärda cpu-problem innan de inträffar. Följande bild visar sidan Proaktiv CPU-övervakning i Diagnostikverktyg.

Du bör betrakta CPU-användningen på 80 procent eller mer som en kritisk situation som kräver omedelbar undersökning. På sidan Proaktiv CPU-övervakning kan du ange det scenario som du vill avbilda en minnesdump för baserat på följande kategorier för dataövervakning:

Cpu-tröskelvärde
Tröskelsekunder
Övervakningsfrekvens

Cpu-tröskelvärdet anger hur mycket dator-CPU som målprocessen använder (W3WP i det här fallet). Tröskelsekunder är den tid som processorn användes vid CPU-tröskelvärdet. Om det till exempel finns en processoranvändning på 75 procent i totalt 30 sekunder registreras minnesdumpen. Enligt konfigurationen på sidan Proaktiv CPU-övervakning skulle processen kontrolleras för tröskelvärdesöverträdelser var 15:e sekund.

Funktionen Reparera automatiskt (minnesgräns)

Funktionen för automatisk återställning (minnesgräns) är användbar för att samla in en minnesdump om processen förbrukar mer minne än förväntat. Var återigen uppmärksam på bitnessen (32 eller 64). Om du upplever minnesbelastning i 32-bitars processkontexten och minnesförbrukningen förväntas kan du överväga att ändra bitnessen till 64. Om du ändrar bitness måste du vanligtvis även kompilera om programmet.

Att ändra bitness minskar inte mängden minne som används. Det gör att processen kan använda mer än 4 GB totalt minne. Men om minnesförbrukningen inte är som förväntat kan du använda den här funktionen för att avgöra vad som förbrukar minnet. Sedan kan du vidta en åtgärd för att kontrollera minnesförbrukningen.

I avsnittet "Utökade funktionsbeskrivningar för Felsökning av Azure App Service" kan du se länken till Reparera automatiskt i panelen Diagnostikverktyg på den första skärmbilden. Välj länken för att gå direkt till funktionen eller välj panelen och granska alla tillgängliga verktyg på sidan Diagnostikverktyg . Mer information finns i avsnittet "Automatisk återställning" i översikten över Azure App Service-diagnostik.

Funktionen för automatisk läkning visas i följande skärmbild.

När du väljer panelen Minnesgräns kan du ange ett minnesvärde som utlöser avbildningen av en minnesdump när minnesgränsen överskrids. Om du till exempel anger 6291456 som värde tas en minnesdump av W3WP-processen när 6 GB minne förbrukas.

Funktionen Samla in en minnesdump är användbar i det här scenariot om problemet för närvarande uppstår eller återskapas. Den här funktionen samlar snabbt in en minnesdump på manuell begäran. Mer information finns i avsnittet "Samla in en minnesdump" .

Expanderade kommandobeskrivningar

Konsten att samla minnesdumpar tar lite tid att studera, uppleva och perfekt. Som du har lärt dig baseras olika procedurer på de symptom som processen visar, enligt tabellen i avsnittet "Beskrivningar av expanderat processscenario" . I följande tabell jämförs däremot Azure App Services minne dump capture-kommando med det procdump-kommando som du kör manuellt från Kudu-konsolen.

Scenario	Azure App Service-kommando	Allmänt procdump-kommando
Svarar inte eller är långsam	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -n 3 -s # <PID>`
Krasch (processavslut)	Använder DbgHost för att avbilda minnesdumpar	`procdump -accepteula -ma -t <PID>`
Krasch (hanterade undantag)	Ingen (Application Insights)	`procdump -accepteula -ma -e 1 -f <filter> <PID>`
Krasch (ohanterade undantag)	Ingen (Application Insights Snapshot Debugger)	`procdump -accepteula -ma -e <PID>`
Överdriven CPU-användning	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -n 3 -s # -c 80 <PID>`
Överdriven minnesförbrukning	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -m 2000 <PID>`

De kommandon som du använder i minnesdumpens avbildningsfunktioner i Azure App Service skiljer sig från de procdump-kommandon som du skulle använda om du registrerade dumpar manuellt. Om du granskar föregående avsnitt bör du se att minnesdumpsamlingens portalfunktion i Azure App Service exponerar konfigurationen. I scenariot med överdriven minnesförbrukning i tabellen innehåller till exempel inte det kommando som plattformen kör ett minneströskelvärde. Kommandot som visas i den allmänna kommandokolumnen procdump anger dock ett minneströskelvärde.

Ett verktyg med namnet DaaS (diagnostik som en tjänst) ansvarar för att hantera och övervaka konfigurationen som anges i Azure App Service-felsökningsportalen. Det här verktyget körs som ett webbjobb på de virtuella datorer som kör webbappen. En fördel med det här verktyget är att du kan rikta in dig på en specifik virtuell dator i webbgruppen. Om du försöker samla in en minnesdump direkt med hjälp av procdump kan det vara svårt att identifiera, rikta, komma åt och köra kommandot på en specifik instans. Mer information om DaaS finns i DaaS – Diagnostik som en tjänst för Azure-webbplatser.

Överdriven CPU-användning är en annan anledning till att plattformen hanterar minnesdumpsamlingen så att de matchar de rekommenderade procdump-mönstren. Procdump-kommandot, som visas i föregående tabell, samlar in tre (-n 3) fullständiga minnesdumpar (-ma) med 30 sekunders mellanrum (-s #där # är 30) när CPU-användningen är större än eller lika med 80 procent (-c 80). Slutligen anger du process-ID :t (<PID>) för kommandot: procdump -accepteula -ma -n 3 -s # -c 80 <PID>.

Du kan se portalkonfigurationen i avsnittet "Proaktiv CPU-övervakning" . För korthet visade det avsnittet endast de tre första konfigurationsalternativen: CPU-tröskelvärde (-c), tröskelvärdessekunder (-s) och övervakningsfrekvens. Följande skärmbild visar att Konfigurera åtgärd, Maximala åtgärder (-n) och Maximal varaktighet är extra tillgängliga funktioner.

När du har studerat de olika metoderna för att samla in minnesdumpar är nästa steg att öva på att göra avbildningar. Du kan använda kodexempel på GitHub tillsammans med IIS-felsökningslabb och Azure Functions för att simulera var och en av de scenarier som visas i de två tabellerna. När du har distribuerat koden till Azure App Service-plattformen kan du använda dessa verktyg för att samla in minnesdumpen i varje scenario. Med tiden och efter övningen kan du göra din metod perfekt för att samla in minnesdumpar med hjälp av azure App Service-felsökningsfunktionerna. Följande lista innehåller några förslag att tänka på när du fortsätter att lära dig mer om insamling av minnesdumpar:

Att samla in en minnesdump förbrukar betydande systemresurser och stör prestandan ytterligare.
Det är inte optimalt att samla in minnesdumpar på den första chansen eftersom du förmodligen kommer att samla in för många. Dessa minnesdumpar med första chansen är troligen irrelevanta.
Vi rekommenderar att du inaktiverar Application Insights innan du registrerar en W3WP-minnesdump.

När minnesdumpen har samlats in är nästa steg att analysera minnesdumpen för att fastställa orsaken till problemet och sedan åtgärda problemet.

Nästa steg (analysera minnesdumpen)

Att diskutera hur du analyserar minnesdumpar ligger utanför omfånget för den här artikeln. Det finns dock många resurser för det ämnet, till exempel träningsserien Defrag Tools och en lista över WinDbg-kommandon som måste känna till det.

Du kanske har lagt märke till alternativet Konfigurera åtgärd i föregående skärmbild. Standardinställningen för det här alternativet är CollectAndKill. Den här inställningen innebär att processen avlivas när minnesdumpen har samlats in. En inställning med namnet CollectKillAndAnalyze analyserar den minnesdump som samlas in. I det scenariot kan plattformsanalysen hitta problemet så att du inte behöver öppna minnesdumpen i WinDbg och analysera den.

Det finns andra alternativ för att felsöka och diagnostisera prestandaproblem på Azure App Service-plattformen. Den här artikeln fokuserar på insamling av minnesdumpar och ger några rekommendationer för hur du närmar dig diagnosen med hjälp av dessa metoder. Om du redan har studerat, upplevt och fulländat dina insamlingsprocedurer, och de fungerar bra för dig, bör du fortsätta att använda dessa procedurer.

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.

Dela via