Samla in minnesdumpar på Azure App Service-plattformen

Artikel
11/20/2024

Den här artikeln innehåller vägledning om felsökningsfunktioner i Microsoft Azure App Service för insamling av minnesdumpar. Avbildningsmetoden som du använder styrs av scenariot där du avbildar en minnesdump för att felsöka ett prestanda- eller tillgänglighetsproblem. Till exempel är insamling av en minnesdump annorlunda för en process som har för hög minnesförbrukning än för en process som utlöser undantag eller svarar långsamt. Processen i det här sammanhanget är IIS-arbetsprocessen (Internet Information Services) (W3WP), som körs som w3wp.exe).

Mappa scenarier för minnesdumpar till Azure App Service-felsökningsfunktioner

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 sätt 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	Command
Svarar inte eller är långsam	Automatisk läkning (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	Ingen
Krasch (ohanterade undantag)	Application Insights Snapshot Debugger	Ingen
Överdriven CPU-användning	Proaktiv CPU-övervakning	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`
Överdriven minnesförbrukning	Automatisk läkning (minnesgräns)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`

Kommentar

Vi har en sekundär rekommendation för att samla in en W3WP-processminnesdump i scenariot med att inte svara eller långsamt. Om det scenariot är reproducerbart och du vill avbilda dumpen direkt kan du använda diagnostikverktyget Samla in en minnesdump . Det här verktyget finns på sidan Diagnostisera och lösa problem i verktygsuppsättningen för den angivna App Service-webbappen i Azure Portal. 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 Diagnostisera och lösa problemsidan .) Vi diskuterar alla tillgängliga metoder i avsnittet "Utökad Azure App Service-felsökning av funktionsbeskrivningar" .

Beskrivningar av expanderade processscenarion

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 viss 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 antingen vara 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 människor är en fördröjning på tre sekunder långsam. För andra är en fördröjning på 15 sekunder acceptabel. I grund och botten, om du ser prestandamått som indikerar långsamhet, eller en superanvändare säger att servern svarar långsammare än normalt, så 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.

Om en utvecklare tidigare inte placerar kodfragment i ett try-catch-block och ett undantag utlöstes avslutades processen. I så fall avslutade ett ohanterat undantag i utvecklarkoden processen. 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. Till exempel kan åtkomstöverträdelser (till exempel 0xC0000005 och 0x80070005) eller ett stackspill avsluta processen.

Kraschscenario (hanterade undantag)

Även om en programutvecklare är särskilt noga med att fastställa alla möjliga scenarier under vilka 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 en bra idé att placera kodkörning i try-catch-kodblock. Om en utvecklare använder dessa block har koden en möjlighet att misslyckas korrekt genom att specifikt hantera vad som följer på 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 scenariot Krasch (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 koden som utvecklaren skrev. Det är inte ramverkskoden som utlöser undantaget, och det är inte ett av de ohanterade undantagen som dödar 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 korrekt 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 kodblocket try-catch. Sedan kan utvecklaren lägga till liknande logik för att logga undantagsinformation som ska finnas i scenariot Krasch (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 w3wp.exe processen i allmänhet är 80 procent är programmet i en kritisk situation som kan orsaka olika symtom. 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 fångade den bursten. I många fall kan du orsaka prestandaproblem genom att låta övervakare ständigt 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 allokeras 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 sitt allokerade virtuella adressutrymme.

Vad som utgör ett problem med överdriven minnesförbrukning 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 minnesdumpning 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 Azure App Service-felsökning

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 inifrån Azure Portal på sidan Diagnostisera och lösa problem när du väljer panelen Diagnostikverktyg.

I följande avsnitt går vi igenom var och en av dessa felsökningsfunktioner mer detaljerat.

Funktionen Återställ 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 inträffar eller återskapas. Den här funktionen samlar snabbt in en minnesdump på manuell begäran.

Samla in en minnesdumpfunktion

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 som 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 körs.

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:

Information om 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 inte stöds. Följande kodfragment försöker till exempel dividera ett tal med noll trots att detta ä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 programkodstack 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 Portal, enligt följande skärmbild.

I den här situationen får du samma felmeddelande som du loggade genom koden. Du förlorar dock viss flexibilitet i 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-felsökningsprogrammet. 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 Portal. 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 från det hanterade undantaget i programloggen är förekomsten av stacken som identifierar metoden och raden 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, enligt 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 cpu-övervakningsverktyget. 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ändning 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 identifierar hur mycket datorprocessor som målprocessen använder (W3WP i det här fallet). Tröskelvärdessekunder är den tid som processorn användes vid CPU-tröskelvärdet. Om det till exempel finns 75 procent cpu-användning i totalt 30 sekunder, skulle minnesdumpen avbildas. Enligt konfigurationen på sidan Proaktiv CPU-övervakning skulle processen kontrolleras för tröskelvärdesöverträdelser var 15:e sekund.

Funktionen Återställ 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. Återigen, var uppmärksam på bitness (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 bitigheten 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ökad Azure App Service-felsökning av funktionsbeskrivningar" kan du se länken till Auto-Heal i panelen Diagnostikverktyg i 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 Översikt ö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 inträffar eller kan återskapas. Den här funktionen samlar snabbt in en minnesdump på manuell begäran. Mer information finns i avsnittet "Samla in en minnesdumpning" .

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 symtom som processen visar, enligt tabellen i avsnittet "Beskrivningar av expanderat processscenario" . I följande tabell jämförs däremot Azure App Service-kommandot för minnesdumpinsamling 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 samla in 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 minnesdumpen som samlar in funktioner i Azure App Service skiljer sig från de procdump-kommandon som du skulle använda om du hämtade dumpar manuellt. Om du granskar föregående avsnitt bör du se att funktionen för minnesdumpsamlingsportalen i Azure App Service exponerar konfigurationen. I scenariot med överdriven minnesförbrukning i tabellen innehåller till exempel kommandot som plattformen kör inte 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 varför 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>) till 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 under varje givet scenario. Med tiden och efter övningen kan du förbättra din metod 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.

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 efter att 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 att närma sig 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