Geheugendumps vastleggen op het Azure-app Service-platform

Artikel
11/20/2024

Dit artikel bevat richtlijnen voor het opsporen van fouten in Microsoft Azure-app-service voor het vastleggen van geheugendumps. De methode voor vastleggen die u gebruikt, wordt bepaald door het scenario waarin u een geheugendump vastlegt voor het oplossen van een prestatie- of beschikbaarheidsprobleem. Het vastleggen van een geheugendump is bijvoorbeeld anders voor een proces dat overmatig geheugenverbruik ondervindt dan voor een proces dat uitzonderingen genereert of langzaam reageert. Het proces in deze context is het IIS-werkproces (Internet Information Services), dat wordt uitgevoerd als w3wp.exe).

Geheugendumpscenario's toewijzen aan Azure-app Service-foutopsporingsfuncties

De volgende tabel bevat aanbevelingen over de opdrachten die elke App Service-functie uitvoert om een geheugendump te genereren. Er zijn zoveel benaderingen voor het vastleggen van een geheugendump dat het proces verwarrend kan zijn. Als u al ervaring hebt met het vastleggen van een W3WP-geheugendump, is deze informatie niet bedoeld om uw benadering te wijzigen. In plaats daarvan hopen we richtlijnen te bieden voor onervaren gebruikers die nog geen voorkeur hebben ontwikkeld.

Scenario	Functie voor Azure-app serviceopsporing	Opdracht
Reageert niet of traag	Automatisch herstellen (duur van aanvraag)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`
Vastlopen (procesbeëindiging)	Crashbewaking	Gebruikt DbgHost om een geheugendump vast te leggen
Crash (afgehandelde uitzonderingen)	Traceringen in Application Insights/Log Analytics	Geen
Crash (onverwerkte uitzonderingen)	Application Insights Snapshot Debugger	Geen
Overmatig CPU-gebruik	Proactieve CPU-bewaking	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`
Overmatig geheugenverbruik	Automatisch herstellen (geheugenlimiet)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`

Notitie

We hebben een secundaire aanbeveling voor het vastleggen van een W3WP-procesgeheugendump in het niet-reagerende of trage scenario. Als dat scenario reproduceerbaar is en u de dump onmiddellijk wilt vastleggen, kunt u het diagnostische hulpprogramma Collect a Memory Dump gebruiken. Dit hulpprogramma bevindt zich op de pagina Hulpprogramma's voor problemen vaststellen en oplossen voor de opgegeven App Service-web-app in Azure Portal. Een andere locatie om te controleren op algemene uitzonderingen en slechte prestaties vindt u op de pagina Gebeurtenislogboeken van toepassingen. (U kunt ook toegang krijgen tot toepassingslogboeken vanuit de De pagina Problemen vaststellen en oplossen.) We bespreken alle beschikbare methoden in de sectie 'Uitgevouwen Azure-app Service-foutopsporingsfunctiebeschrijvingen'.

Beschrijvingen van uitgebreide processcenario's

Deze sectie bevat gedetailleerde beschrijvingen van de zes scenario's die in de vorige tabel worden weergegeven.

Niet reagerend of traag scenario

Wanneer een aanvraag wordt ingediend bij een webserver, moet bepaalde code meestal worden uitgevoerd. De uitvoering van de code vindt plaats in het w3wp.exe proces voor threads. Elke thread heeft een stack die laat zien wat er momenteel wordt uitgevoerd.

Een niet-reagerend scenario kan permanent (en waarschijnlijk een time-out) of traag zijn. Daarom is het niet-reagerende scenario een scenario waarin een aanvraag langer duurt dan verwacht om uit te voeren. Wat u kunt overwegen om langzaam te zijn, is afhankelijk van wat de code doet. Voor sommige mensen is een vertraging van drie seconden traag. Voor anderen is een vertraging van 15 seconden acceptabel. Als u prestatiemetrieken ziet die duiden op traagheid, of als een supergebruiker aangeeft dat de server langzamer reageert dan normaal, hebt u een niet-reagerend of traag scenario.

Crashscenario (procesbeëindiging)

Microsoft .NET Framework heeft de verwerking van uitzonderingen in de loop der jaren verbeterd. In de huidige versie van .NET is de ervaring voor het afhandelen van uitzonderingen nog beter.

Historisch gezien, als een ontwikkelaar geen codefragmenten in een try-catch-blok heeft gezet en er een uitzondering is opgetreden, is het proces beëindigd. In dat geval heeft een onverwerkte uitzondering in de code van de ontwikkelaar het proces beëindigd. In modernere versies van .NET worden enkele van deze 'onverwerkte' uitzonderingen verwerkt, zodat het proces waarop de code wordt uitgevoerd, niet vastloopt. Niet alle niet-verwerkte uitzonderingen worden echter rechtstreeks vanuit de aangepaste code gegenereerd. Zo kunnen toegangsschendingen (zoals 0xC0000005 en 0x80070005) of een stack-overloop het proces beëindigen.

Crashscenario (afgehandelde uitzonderingen)

Hoewel een softwareontwikkelaar speciaal zorgt voor het bepalen van alle mogelijke scenario's waaronder de code wordt uitgevoerd, kan er iets onverwachts gebeuren. De volgende fouten kunnen een uitzondering activeren:

Onverwachte null-waarden
Ongeldige cast-conversie
Een ontbrekend geïnstantieerd object

Het is een best practice om code-uitvoering in try-catch-codeblokken te plaatsen. Als een ontwikkelaar deze blokken gebruikt, kan de code probleemloos mislukken door specifiek te beheren wat de onverwachte gebeurtenis volgt. Een afgehandelde uitzondering is een uitzondering die wordt gegenereerd in een try-blok en wordt gevangen in het bijbehorende catch-blok. In dit geval verwachtte de ontwikkelaar dat er een uitzondering kon optreden en codeerde een geschikt try-catch-blok rond die sectie met code.

In het catch-blok is het handig om voldoende informatie vast te leggen in een logboekregistratiebron, zodat het probleem kan worden gereproduceerd en uiteindelijk kan worden opgelost. Uitzonderingen zijn dure codepaden in termen van prestaties. Het hebben van veel uitzonderingen is daarom van invloed op de prestaties.

Crashscenario (niet-verwerkte uitzonderingen)

Onverwerkte uitzonderingen treden op wanneer code een actie probeert uit te voeren die niet wordt verwacht. Net als in het crashscenario (procesbeëindiging) bevindt die code zich niet in een try-catch-codeblok. In dit geval had de ontwikkelaar niet verwacht dat er een uitzondering zou kunnen optreden in die sectie met code.

Dit scenario verschilt van de vorige twee uitzonderingsscenario's. In het scenario Crash (niet-verwerkte uitzonderingen) is de code in kwestie de code die de ontwikkelaar heeft geschreven. Het is niet de frameworkcode die de uitzondering genereert, en het is geen van de onverwerkte uitzonderingen die het w3wp.exe proces doden. Omdat de code die een uitzondering genereert, zich niet in een try-catch-blok bevindt, is er ook geen mogelijkheid om de uitzondering probleemloos te verwerken. Het oplossen van problemen met de code is in eerste instantie iets complexer. Het doel is om de uitzonderingstekst, het type en de stack te vinden die de methode identificeert waarmee deze niet-verwerkte uitzondering wordt gegenereerd. Met deze informatie kunt u bepalen waar u het try-catch-codeblok moet toevoegen. Vervolgens kan de ontwikkelaar de vergelijkbare logica toevoegen voor het vastleggen van uitzonderingsdetails die moeten bestaan in het crashscenario (niet-verwerkte uitzonderingen).

Overmatig CPU-gebruiksscenario

Wat is overmatig CPU-gebruik? Deze situatie is afhankelijk van wat de code doet. In het algemeen geldt dat als het CPU-gebruik van het w3wp.exe proces 80 procent is, is uw toepassing in een kritieke situatie die verschillende symptomen kan veroorzaken. Enkele mogelijke symptomen zijn:

Traagheid
Fouten
Ander niet-gedefinieerd gedrag

Zelfs een CPU-gebruik van 20 procent kan als overmatig worden beschouwd als de website alleen statische HTML-bestanden levert. Na het oplossen van problemen met een overmatige CPU-piek door het genereren van een geheugendump kunt u waarschijnlijk niet helpen om de specifieke methode te bepalen die deze gebruikt. U kunt het beste bepalen welke aanvragen waarschijnlijk het langst duren en vervolgens proberen het probleem te reproduceren door de geïdentificeerde methode te testen. Bij deze procedure wordt ervan uitgegaan dat u geen prestatiemonitors uitvoert op de prestatiesystemen die die burst hebben vastgelegd. In veel gevallen kunt u prestatieproblemen veroorzaken door monitors voortdurend in realtime uit te voeren.

Scenario voor overmatig geheugengebruik

Als een toepassing wordt uitgevoerd in een 32-bits proces, kan overmatig geheugenverbruik een probleem zijn. Zelfs een kleine hoeveelheid activiteit kan de 2-3 GB toegewezen virtuele adresruimte verbruiken. Een 32-bits proces kan nooit groter zijn dan 4 GB, ongeacht de hoeveelheid fysiek geheugen dat beschikbaar is.

Een 64-bits proces wordt meer geheugen toegewezen dan een 32-bits proces. Het is waarschijnlijker dat het 64-bits proces de hoeveelheid fysiek geheugen op de server verbruikt dan dat het proces de toegewezen virtuele adresruimte verbruikt.

Wat een overmatig probleem met geheugenverbruik vormt, is daarom afhankelijk van de volgende factoren:

Procesbitness (32-bits of 64-bits)
De hoeveelheid geheugengebruik die als normaal wordt beschouwd.

Als uw proces meer geheugen verbruikt dan verwacht, verzamelt u een geheugendump voor analyse om te bepalen wat geheugenresources verbruikt. Zie Een geheugendump van uw App Service maken wanneer deze te veel geheugen verbruikt voor meer informatie.

Nu u wat meer context hebt over de verschillende processcenario's die een geheugendump u kunnen helpen bij het oplossen van problemen, bespreken we het aanbevolen hulpprogramma voor het vastleggen van geheugendumps op het Azure-app Service-platform.

Uitgebreide beschrijvingen van functies voor Azure-app Service-foutopsporing

In de tabel in de sectie 'Geheugendumpscenario's toewijzen aan Azure-app Service-foutopsporingsfuncties' hebben we zes functies voor foutopsporing geïdentificeerd die zijn gericht op het verzamelen van geheugendumps. Elk van deze functies is toegankelijk vanuit Azure Portal op de pagina Problemen vaststellen en oplossen wanneer u de tegel Diagnostische hulpprogramma's selecteert.

In de volgende secties bespreken we elk van deze functies voor foutopsporing in meer detail.

Functie voor automatisch herstellen (duur van aanvraag)

De functie voor automatisch herstellen (aanvraagduur) is handig voor het vastleggen van een geheugendump als het langer duurt dan verwacht om het antwoord te voltooien. In de vorige schermafbeelding ziet u de koppeling naar Automatisch herstellen in de tegel Diagnostische hulpprogramma's . Selecteer die koppeling om rechtstreeks naar de functie te gaan of selecteer de tegel Diagnostische hulpprogramma's om alle beschikbare hulpprogramma's op de pagina Diagnostische hulpprogramma's te bekijken. Zie de volgende artikelen voor meer informatie over het configureren van deze functie:

De functie voor automatisch herstellen wordt weergegeven in de volgende schermopname.

Een andere functie met de naam 'Collect a Memory dump' is handig in dit scenario wanneer het probleem zich momenteel voordoet of reproduceerbaar is. Met deze functie wordt snel een geheugendump verzameld op handmatige vraag.

Een geheugendumpfunctie verzamelen

Zie App-services voor geheugendump verzamelen voor meer informatie over de configuratie van de functie Geheugendump verzamelen. Voor deze aanpak is handmatige interventie vereist. In de volgende schermopname ziet u de pagina Een geheugendump verzamelen.

Als u de functie wilt gebruiken, selecteert u een opslagaccount waarin u de geheugendump wilt opslaan. Selecteer vervolgens van welk serverexemplaren u de geheugendump wilt verzamelen. Als u meer dan één exemplaar hebt, moet u ervoor zorgen dat het probleem dat u foutopsporing uitvoert op dat exemplaar optreedt. U ziet dat een herstart mogelijk niet optimaal is voor een productietoepassing die wordt uitgevoerd.

Crash Monitoring-functie

De functie Crash Monitoring is handig voor het vastleggen van een geheugendump als een niet-verwerkte uitzondering ervoor zorgt dat het W3WP-proces wordt beëindigd. In de volgende schermopname ziet u de pagina Crash Monitoring in Diagnostische hulpprogramma's:

Zie Crash monitoring in Azure-app Service voor een stapsgewijze uitleg over het configureren van de functie crashbewaking in Azure-app Service.

Traceringen in de functie Application Insights/Log Analytics

Een afgehandelde uitzondering is een scenario waarin de code in een try-catch-blok probeert een actie uit te voeren die onverwacht of niet wordt ondersteund. Het volgende codefragment probeert bijvoorbeeld een getal te delen door nul, ook al is dit een illegale bewerking:

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

Dit codefragment veroorzaakt een scheidings-by-nul-uitzondering die wordt verwerkt omdat de niet-ondersteunde wiskundige bewerking in een try-catch-blok wordt geplaatst. Application Insights not logd handled exceptions tenzij u opzettelijk het Microsoft.ApplicationInsights NuGet-pakket in uw toepassingscode opneemt en vervolgens de code toevoegt om de gegevens te registreren. Als de uitzondering optreedt nadat u de code hebt toegevoegd, kunt u de vermelding bekijken in Log Analytics, zoals wordt weergegeven in de volgende schermopname.

De volgende Kusto-code bevat de query die wordt gebruikt om de gegevens uit Log Analytics te extraheren:

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

De message kolom is de locatie waarin u de details kunt opslaan die nodig zijn om de hoofdoorzaak van de uitzondering te vinden. De code die wordt gebruikt om deze query te schrijven, bevindt zich in het codefragment voor delen met nul. De softwareontwikkelaar die deze code heeft geschreven, is de beste persoon om te vragen over dit soort uitzonderingen en de kenmerken die nodig zijn om vast te leggen voor het analyseren van hoofdoorzaken.

De beste methode om deze functionaliteit toe te voegen aan uw toepassingscode is afhankelijk van de toepassingscodestack en versie die u hebt (bijvoorbeeld ASP.NET, ASP.NET Core, MVC, Razor, enzovoort). Als u de beste benadering voor uw scenario wilt bepalen, bekijkt u Application Insights-logboekregistratie met .NET.

Toepassingsgebeurtenislogboeken (afgehandelde uitzonderingen) functie

U kunt ook niet-verwerkte uitzonderingen vinden op de afgehandelde uitzondering op de pagina Toepassingsgebeurtenislogboeken van diagnostische hulpprogramma's in Azure Portal, zoals wordt weergegeven in de volgende schermopname.

In dit geval ontvangt u hetzelfde foutbericht dat u hebt geregistreerd via uw code. U verliest echter enige flexibiliteit bij het aanpassen van de query's in Application Insights-traceringslogboeken.

Application Insights Snapshot Debugger-functie

Niet-verwerkte uitzonderingen worden ook geregistreerd op de pagina Toepassingsgebeurtenislogboeken , zoals wordt weergegeven in de uitvoertekst in de volgende sectie. U kunt echter ook het foutopsporingsprogramma van Application Insights Snapshot inschakelen. Voor deze aanpak hoeft u geen code toe te voegen aan uw toepassing.

Gebeurtenislogboeken van toepassingen (niet-verwerkte uitzonderingen)

De volgende uitvoer vindt u op de pagina Toepassingslogboeken van diagnostische hulpprogramma's in Azure Portal. Hier ziet u een voorbeeldtekst van een niet-verwerkte toepassingsuitzondering:

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

Een verschil hier van de afgehandelde uitzondering in het toepassingslogboek is het bestaan van de stack die de methode en de regel identificeert waaruit de uitzondering wordt gegenereerd. U kunt er ook veilig van uitgaan dat de functionaliteit Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware code bevat om deze niet-verwerkte uitzondering te ondervangen, zodat beëindiging van het proces wordt vermeden. De uitzondering wordt weergegeven in Application Insights op het tabblad Uitzonderingen van de pagina Fouten , zoals wordt weergegeven in de volgende schermopname.

In deze weergave ziet u alle uitzonderingen, niet alleen de uitzonderingen die u zoekt. De grafische weergave van alle uitzonderingen die in uw toepassing optreden, is handig om een overzicht te krijgen van de status van uw systeem. Het Application Insights-dashboard is visueel handiger in vergelijking met de gebeurtenislogboeken van de toepassing.

Proactieve CPU-bewakingsfunctie

Tijdens overmatige CPU-gebruiksscenario's kunt u het proactieve hulpprogramma voor CPU-bewaking gebruiken. Zie Uw CPU-problemen beperken voordat deze zich voordoen voor meer informatie over dit hulpprogramma. In de volgende afbeelding ziet u de pagina Proactieve CPU-bewaking in Diagnostische hulpprogramma's.

Overweeg het CPU-gebruik van 80 procent of meer als een kritieke situatie waarvoor onmiddellijk onderzoek is vereist. Op de pagina Proactieve CPU-bewaking kunt u het scenario instellen waarvoor u een geheugendump wilt vastleggen op basis van de volgende gegevensbewakingscategorieën:

CPU-drempelwaarde
Drempelwaarde seconden
Monitorfrequentie

Cpu-drempelwaarde geeft aan hoeveel computer-CPU het doelproces gebruikt (W3WP in dit geval). Drempelwaarde seconden is de hoeveelheid tijd die de CPU is gebruikt bij de CPU-drempelwaarde. Als er bijvoorbeeld 75 procent CPU-gebruik is voor een totaal van 30 seconden, wordt de geheugendump vastgelegd. Zoals geconfigureerd op de pagina Proactieve CPU-bewaking , wordt het proces elke 15 seconden gecontroleerd op drempelwaarde-schendingen.

Functie voor automatisch herstellen (geheugenlimiet)

De functie voor automatisch herstellen (geheugenlimiet) is handig voor het vastleggen van een geheugendump als het proces meer geheugen verbruikt dan verwacht. Let nogmaals op de bitheid (32 of 64). Als u geheugenbelasting ondervindt in de 32-bits procescontext en het geheugenverbruik wordt verwacht, kunt u overwegen om de bitness te wijzigen in 64. Als u de bitheid wijzigt, moet u de toepassing ook opnieuw compileren.

Als u de bitheid wijzigt, vermindert u niet de hoeveelheid geheugen die wordt gebruikt. Hierdoor kan het proces meer dan 4 GB aan totale geheugen gebruiken. Als het geheugenverbruik echter niet zoals verwacht is, kunt u deze functie gebruiken om te bepalen wat het geheugen verbruikt. Vervolgens kunt u een actie ondernemen om het geheugenverbruik te beheren.

In de sectie 'Uitgevouwen Azure-app service foutopsporingsfunctiebeschrijvingen' ziet u de koppeling naar Automatisch herstellen in de tegel Diagnostische hulpprogramma's in de eerste schermopname. Selecteer die koppeling om rechtstreeks naar de functie te gaan of selecteer de tegel en bekijk alle beschikbare hulpprogramma's op de pagina Diagnostische hulpprogramma's . Ga voor meer informatie naar de sectie 'Automatisch herstellen' van Azure-app servicediagnoseoverzicht.

De functie voor automatisch herstellen wordt weergegeven in de volgende schermopname.

Wanneer u de tegel Geheugenlimiet selecteert, kunt u een geheugenwaarde invoeren die de opname van een geheugendump activeert wanneer die geheugenlimiet wordt overschreden. Als u bijvoorbeeld 6291456 invoert als de waarde, wordt een geheugendump van het W3WP-proces gebruikt wanneer 6 GB geheugen wordt verbruikt.

De functie Geheugendump verzamelen is handig in dit scenario als het probleem zich momenteel voordoet of reproduceerbaar is. Met deze functie wordt snel een geheugendump verzameld op handmatige vraag. Zie de sectie 'Een geheugendump verzamelen' voor meer informatie.

Uitgebreide opdrachtbeschrijvingen

De kunst van geheugendumpverzameling kost enige tijd om te studeren, ervaring en perfect. Zoals u hebt geleerd, zijn verschillende procedures gebaseerd op de symptomen die het proces weergeeft, zoals vermeld in de tabel in de sectie Uitgebreide beschrijvingen van processcenario's. In de volgende tabel wordt de opdracht voor het vastleggen van de geheugendump van de Azure-app-service vergeleken met de procdump-opdracht die u handmatig uitvoert vanuit de Kudu-console.

Scenario	opdracht Azure-app Service	Algemene procdump-opdracht
Reageert niet of traag	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -n 3 -s # <PID>`
Vastlopen (procesbeëindiging)	Gebruikt DbgHost om geheugendump vast te leggen	`procdump -accepteula -ma -t <PID>`
Crash (afgehandelde uitzonderingen)	Geen (Application Insights)	`procdump -accepteula -ma -e 1 -f <filter> <PID>`
Crash (onverwerkte uitzonderingen)	Geen (Application Insights Snapshot Debugger)	`procdump -accepteula -ma -e <PID>`
Overmatig CPU-gebruik	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -n 3 -s # -c 80 <PID>`
Overmatig geheugenverbruik	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -m 2000 <PID>`

De opdrachten die u in de geheugendump gebruikt voor het vastleggen van functies in Azure-app Service verschillen van de procdump-opdrachten die u zou gebruiken als u handmatig dumps hebt vastgelegd. Als u de vorige sectie bekijkt, ziet u dat de functie voor het verzamelen van geheugendumps in Azure-app Service de configuratie beschikbaar maakt. In het scenario voor overmatig geheugengebruik in de tabel bevat de opdracht die door het platform wordt uitgevoerd bijvoorbeeld geen geheugendrempelwaarde. De opdracht die wordt weergegeven in de algemene opdrachtkolom procdump geeft echter een geheugendrempel op.

Een hulpprogramma met de naam DaaS (Diagnostics as a Service) is verantwoordelijk voor het beheren en bewaken van de configuratie die is opgegeven in de Azure-app Service-foutopsporingsportal. Dit hulpprogramma wordt uitgevoerd als een webtaak op de virtuele machines (VM's) waarop uw web-app wordt uitgevoerd. Een voordeel van dit hulpprogramma is dat u zich kunt richten op een specifieke VIRTUELE machine in uw webfarm. Als u een geheugendump probeert vast te leggen met behulp van procdump, kan het lastig zijn om die opdracht te identificeren, te targeten, te openen en uit te voeren op een specifiek exemplaar. Zie DaaS : Diagnostische gegevens als een service voor Azure-websites voor meer informatie over DaaS.

Overmatig CPU-gebruik is een andere reden waarom het platform de geheugendumpverzameling beheert, zodat deze overeenkomen met de aanbevolen procdump-patronen. De procdump-opdracht, zoals weergegeven in de vorige tabel, verzamelt drie (-n 3) volledige geheugendumps (-ma) 30 seconden uit elkaar (-s #waarvan # 30) wanneer het CPU-gebruik groter is dan of gelijk is aan 80 procent (-c 80). Ten slotte geeft u de proces-id (<PID>) op voor de opdracht: procdump -accepteula -ma -n 3 -s # -c 80 <PID>.

U kunt de portalconfiguratie zien in de sectie Proactieve CPU-bewaking . Ter beknoptheid liet die sectie alleen de eerste drie configuratieopties zien: CPU-drempelwaarde (-c), drempelwaarde seconden (-s) en monitorfrequentie. In de volgende schermopname ziet u dat actie, maximumacties (-n) en maximale duur extra beschikbare functies zijn.

Nadat u de verschillende methoden voor het vastleggen van geheugendumps hebt onderzocht, is de volgende stap het oefenen met het maken van opnamen. U kunt codevoorbeelden op GitHub gebruiken in combinatie met IIS-foutopsporingslabs en Azure Functions om elk van de scenario's te simuleren die in de twee tabellen worden vermeld. Nadat u de code hebt geïmplementeerd op het Azure-app Service-platform, kunt u deze hulpprogramma's gebruiken om de geheugendump onder elk gegeven scenario vast te leggen. Na verloop van tijd en na de praktijk kunt u uw benadering voor het vastleggen van geheugendumps perfect maken met behulp van de Azure-app Service-foutopsporingsfuncties. De volgende lijst bevat enkele suggesties die u kunt overwegen wanneer u doorgaat met het verzamelen van geheugendumps:

Het vastleggen van een geheugendump verbruikt aanzienlijke systeembronnen en verstoort de prestaties nog verder.
Het vastleggen van geheugendumps op de eerste kans is niet optimaal omdat u waarschijnlijk te veel vastlegt. Deze eerste kans geheugendumps zijn waarschijnlijk irrelevant.
U wordt aangeraden Application Insights uit te schakelen voordat u een W3WP-geheugendump vastlegt.

Nadat de geheugendump is verzameld, is de volgende stap het analyseren van de geheugendump om de oorzaak van het probleem te bepalen en dat probleem vervolgens op te lossen.

Volgende stappen (het analyseren van de geheugendump)

Het bespreken van het analyseren van geheugendumps valt buiten het bereik van dit artikel. Er zijn echter veel bronnen voor dat onderwerp, zoals de defragmentatie Tools-trainingsreeks en een lijst met must-know WinDbg-opdrachten.

Mogelijk hebt u de optie Actie configureren in de vorige schermafbeelding gezien. De standaardinstelling voor deze optie is CollectAndKill. Deze instelling betekent dat het proces wordt gedood nadat de geheugendump is verzameld. Een instelling met de naam CollectKillAndAnalyze analyseert de geheugendump die wordt verzameld. In dat scenario kan de platformanalyse het probleem vinden, zodat u de geheugendump niet hoeft te openen in WinDbg en deze te analyseren.

Er zijn andere opties voor het oplossen en diagnosticeren van prestatieproblemen op het Azure-app Service-platform. Dit artikel richt zich op het verzamelen van geheugendumps en doet enkele aanbevelingen voor het benaderen van de diagnose met behulp van deze methoden. Als u uw verzamelingsprocedures al hebt bestudeerd, ervaren en perfect hebt uitgevoerd en ze goed voor u werken, moet u deze procedures blijven gebruiken.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.

Delen via