Acquisire dump di memoria nella piattaforma del servizio app Azure

Articolo
11/20/2024

Questo articolo fornisce indicazioni sulle funzionalità di debug di Microsoft app Azure Service per l'acquisizione di dump di memoria. Il metodo di acquisizione usato è determinato dallo scenario in cui si acquisisce un dump della memoria per la risoluzione di un problema di prestazioni o disponibilità. Ad esempio, l'acquisizione di un dump della memoria è diversa per un processo che riscontra un consumo eccessivo di memoria rispetto a un processo che genera eccezioni o risponde lentamente. Il processo in questo contesto è il processo di lavoro di Internet Information Services (IIS), che viene eseguito come w3wp.exe.

Mapping degli scenari di dump della memoria alle funzionalità di debug del servizio app Azure

Nella tabella seguente vengono fornite indicazioni sui comandi eseguiti da ogni servizio app funzionalità per generare un dump della memoria. Esistono così tanti approcci per acquisire un dump della memoria che il processo potrebbe generare confusione. Se sei già esperto nell'acquisizione di un dump di memoria W3WP, queste informazioni non sono destinate a modificare il tuo approccio. Speriamo invece di fornire indicazioni per gli utenti inesperti che non hanno ancora sviluppato una preferenza.

Scenario	funzionalità di debug del servizio app Azure	Comando
Non rispondere o rallentare	Correzione automatica (durata richiesta)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`
Arresto anomalo (terminazione del processo)	Monitoraggio degli arresti anomali	Usa DbgHost per acquisire un dump della memoria
Arresto anomalo (eccezioni gestite)	Tracce in Application Insights/Log Analytics	None
Arresto anomalo (eccezioni non gestite)	Debugger di snapshot di Application Insights	None
Utilizzo eccessivo della CPU	Monitoraggio proattivo della CPU	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`
Consumo eccessivo di memoria	Correzione automatica (limite di memoria)	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`

Note

È consigliabile acquisire un dump della memoria del processo W3WP nello scenario non rispondente o lento. Se questo scenario è riproducibile e si vuole acquisire immediatamente il dump, è possibile usare lo strumento di diagnostica Raccogli un dump della memoria. Questo strumento si trova nella pagina Diagnosticare e risolvere i problemi del set di strumenti per l'app Web servizio app specificata nella portale di Azure. Un'altra posizione per verificare la presenza di eccezioni generali e prestazioni scarse è nella pagina Registri eventi dell'applicazione. È possibile accedere ai log applicazioni anche da Pagina Diagnosticare e risolvere i problemi. Tutti i metodi disponibili vengono illustrati nella sezione "Descrizioni delle funzionalità di debug del servizio espanse app Azure".

Descrizioni degli scenari di processo espanse

Questa sezione contiene descrizioni dettagliate dei sei scenari illustrati nella tabella precedente.

Scenario non rispondente o lento

Quando viene effettuata una richiesta a un server Web, è in genere necessario eseguire codice. L'esecuzione del codice viene eseguita all'interno del processo di w3wp.exe sui thread. Ogni thread ha uno stack che mostra cosa è attualmente in esecuzione.

Uno scenario che non risponde può essere permanente (e probabilmente timeout) o lento. Di conseguenza, lo scenario che non risponde è quello in cui una richiesta richiede più tempo del previsto per l'esecuzione. Ciò che si potrebbe considerare lento dipende dalle operazioni eseguite dal codice. Per alcune persone, un ritardo di tre secondi è lento. Per altri, un ritardo di 15 secondi è accettabile. Fondamentalmente, se vengono visualizzate metriche delle prestazioni che indicano lentezza o un utente con privilegi avanzati indica che il server risponde più lentamente del normale, si ha uno scenario non rispondente o lento.

Scenario di arresto anomalo (terminazione del processo)

In molti anni, Microsoft .NET Framework ha migliorato la gestione delle eccezioni. Nella versione corrente di .NET, l'esperienza di gestione delle eccezioni è ancora migliore.

Storicamente, se uno sviluppatore non inserisce frammenti di codice all'interno di un blocco try-catch e viene generata un'eccezione, il processo è terminato. In tal caso, un'eccezione non gestita nel codice dello sviluppatore ha terminato il processo. Le versioni più moderne di .NET gestiscono alcune di queste eccezioni "non gestite", in modo che il processo che esegue il codice non si arresti in modo anomalo. Tuttavia, non tutte le eccezioni non gestite vengono generate direttamente dal codice personalizzato. Ad esempio, le violazioni di accesso (ad esempio 0xC0000005 e 0x80070005) o un overflow dello stack possono terminare il processo.

Scenario di arresto anomalo (eccezioni gestite)

Anche se uno sviluppatore di software si occupa in modo particolare di determinare tutti gli scenari possibili in cui viene eseguito il codice, può verificarsi un evento imprevisto. Gli errori seguenti possono attivare un'eccezione:

Valori Null imprevisti
Cast non valido
Oggetto di cui è stata creata un'istanza mancante

È consigliabile inserire l'esecuzione del codice in blocchi di codice try-catch. Se uno sviluppatore usa questi blocchi, il codice ha la possibilità di non riuscire correttamente gestendo in modo specifico ciò che segue l'evento imprevisto. Un'eccezione gestita è un'eccezione generata all'interno di un blocco try e rilevata nel blocco catch corrispondente. In questo caso, lo sviluppatore ha previsto che potrebbe verificarsi un'eccezione e ha codificato un blocco try-catch appropriato intorno a tale sezione di codice.

Nel blocco catch è utile acquisire informazioni sufficienti in un'origine di registrazione in modo che il problema possa essere riprodotto e, in definitiva, risolto. Le eccezioni sono percorsi di codice costosi in termini di prestazioni. Di conseguenza, la presenza di molte eccezioni influisce sulle prestazioni.

Scenario di arresto anomalo (eccezioni non gestite)

Le eccezioni non gestite si verificano quando il codice tenta di eseguire un'azione che non si prevede di incontrare. Come nello scenario Arresto anomalo (terminazione del processo), il codice non è contenuto in un blocco di codice try-catch. In questo caso, lo sviluppatore non ha previsto che un'eccezione possa verificarsi in tale sezione di codice.

Questo scenario differisce dai due scenari di eccezione precedenti. Nello scenario Arresto anomalo (eccezioni non gestite) il codice in questione è il codice scritto dallo sviluppatore. Non è il codice del framework che genera l'eccezione e non è una delle eccezioni non gestite che termina il processo di w3wp.exe . Inoltre, poiché il codice che genera un'eccezione non si trova all'interno di un blocco try-catch, non è possibile gestire correttamente l'eccezione. La risoluzione dei problemi del codice è inizialmente un po' più complessa. L'obiettivo è trovare il testo dell'eccezione, il tipo e lo stack che identifica il metodo che genera questa eccezione non gestita. Queste informazioni consentono di identificare dove è necessario aggiungere il blocco di codice try-catch. Lo sviluppatore può quindi aggiungere la logica simile per registrare i dettagli delle eccezioni che devono esistere nello scenario Arresto anomalo (eccezioni non gestite).

Scenario di utilizzo eccessivo della CPU

Qual è l'utilizzo eccessivo della CPU? Questa situazione dipende dalle operazioni eseguite dal codice. In generale, se l'utilizzo della CPU dal processo di w3wp.exe è pari all'80%, l'applicazione si trova in una situazione critica che può causare vari sintomi. Alcuni possibili sintomi sono:

Lentezza
Errori
Altro comportamento non definito

Anche un utilizzo della CPU del 20% può essere considerato eccessivo se il sito Web sta semplicemente recapitando file HTML statici. La risoluzione dei problemi post-mortem di un picco eccessivo della CPU generando un dump della memoria probabilmente non consente di determinare il metodo specifico che lo usa. Il meglio che è possibile fare è determinare quali richieste richiedevano probabilmente il tempo più lungo e quindi provare a riprodurre il problema testando il metodo identificato. Questa procedura presuppone che non si eseguano monitoraggi delle prestazioni nei sistemi di prestazioni che hanno acquisito tale burst. In molti casi, è possibile causare problemi di prestazioni con monitoraggi continuamente eseguiti in tempo reale.

Scenario di utilizzo eccessivo della memoria

Se un'applicazione è in esecuzione in un processo a 32 bit, un consumo eccessivo di memoria può essere un problema. Anche una piccola quantità di attività può utilizzare i 2-3 GB di spazio indirizzi virtuale allocato. Un processo a 32 bit non può mai superare un totale di 4 GB, indipendentemente dalla quantità di memoria fisica disponibile.

Un processo a 64 bit viene allocato più memoria di un processo a 32 bit. È più probabile che il processo a 64 bit utilizzerà la quantità di memoria fisica nel server rispetto a quella che il processo utilizzerà lo spazio indirizzi virtuale allocato.

Di conseguenza, ciò che costituisce un problema eccessivo di consumo di memoria dipende dai fattori seguenti:

Bitness del processo (32 bit o 64 bit)
Quantità di utilizzo della memoria considerata "normale".

Se il processo utilizza più memoria del previsto, raccogliere un dump della memoria per l'analisi per determinare quali risorse di memoria utilizzano. Per altre informazioni, vedere Creare un dump della memoria del servizio app quando utilizza una quantità eccessiva di memoria.

Ora che si dispone di un po' di più contesto sui diversi scenari di processo che un dump della memoria consente di risolvere i problemi, verrà illustrato lo strumento consigliato per l'acquisizione di dump di memoria nella piattaforma del servizio app Azure.

Descrizioni delle funzionalità di debug del servizio espanse app Azure

Nella tabella nella sezione "Mapping degli scenari di dump della memoria alle funzionalità di debug del servizio app Azure", sono state identificate sei funzionalità di debug destinate alla raccolta dei dump della memoria. Ognuna di queste funzionalità è accessibile dall'interno del portale di Azure nella pagina Diagnostica e risoluzione dei problemi quando si seleziona il riquadro Strumenti di diagnostica.

Nelle sezioni seguenti vengono illustrate in modo più dettagliato ognuna di queste funzionalità di debug.

Funzionalità di correzione automatica (durata della richiesta)

La funzionalità di correzione automatica (durata della richiesta) è utile per acquisire un dump della memoria se la risposta richiede più tempo del previsto. È possibile visualizzare il collegamento a Correzione automatica nel riquadro Strumenti di diagnostica nello screenshot precedente. Selezionare il collegamento per passare direttamente alla funzionalità oppure selezionare il riquadro Strumenti di diagnostica per esaminare tutti gli strumenti disponibili nella pagina Strumenti di diagnostica. Per informazioni su come configurare questa funzionalità, vedere gli articoli seguenti:

La funzionalità di correzione automatica è illustrata nello screenshot seguente.

Un'altra funzionalità denominata "Raccogli un dump della memoria" è utile in questo scenario quando il problema si verifica o riproducibile. Questa funzionalità raccoglie rapidamente un dump della memoria su richiesta manuale.

Raccogliere una funzionalità di dump della memoria

Questo approccio richiede un intervento manuale. Lo screenshot seguente mostra la pagina Raccogli un dump della memoria.

Per usare la funzionalità, selezionare un account di archiviazione in cui archiviare il dump della memoria. Selezionare quindi l'istanza del server da cui raccogliere il dump della memoria. Se si dispone di più di una singola istanza, assicurarsi che il problema di cui si sta eseguendo il debug si stia verificando in tale istanza. Si noti che un riavvio potrebbe non essere ottimale in un'applicazione di produzione in esecuzione.

Funzionalità di monitoraggio degli arresti anomali

La funzionalità Monitoraggio arresti anomali è utile per acquisire un dump della memoria se un'eccezione non gestita causa il termine del processo W3WP. Lo screenshot seguente mostra la pagina Monitoraggio arresto anomalo in Strumenti di diagnostica:

Per visualizzare una procedura guidata su come configurare la funzionalità di monitoraggio degli arresti anomali nel servizio app Azure, vedere Monitoraggio degli arresti anomali nel servizio app Azure.

Tracce nella funzionalità Application Insights/Log Analytics

Un'eccezione gestita è uno scenario in cui il codice contenuto in un blocco try-catch tenta di eseguire un'azione imprevista o non supportata. Ad esempio, il frammento di codice seguente tenta di dividere un numero per zero anche se si tratta di un'operazione non valida:

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

Questo frammento di codice causa un'eccezione di divisione per zero gestita perché l'operazione matematica non supportata viene inserita all'interno di un blocco try-catch. Application Insights non registra le eccezioni gestite a meno che non si includa intenzionalmente il pacchetto NuGet Microsoft.ApplicationInsights nel codice dell'applicazione e quindi si aggiunge il codice per registrare le informazioni. Se l'eccezione si verifica dopo aver aggiunto il codice, è possibile visualizzare la voce in Log Analytics, come illustrato nello screenshot seguente.

Il codice Kusto seguente contiene la query usata per estrarre i dati da Log Analytics:

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

La message colonna è la posizione in cui è possibile archiviare i dettagli necessari per trovare la causa radice dell'eccezione. Il codice usato per scrivere questa query si trova nel frammento di codice division-by-zero. Lo sviluppatore di software che ha scritto questo codice è la persona migliore per chiedere informazioni su questi tipi di eccezioni e sugli attributi necessari per acquisire per l'analisi delle cause radice.

L'approccio migliore per aggiungere questa funzionalità al codice dell'applicazione dipende dallo stack di codice e dalla versione dell'applicazione disponibili, ad esempio ASP.NET, ASP.NET Core, MVC, Razor e così via. Per determinare l'approccio migliore per lo scenario, vedere Registrazione di Application Insights con .NET.

Funzionalità registri eventi dell'applicazione (eccezioni gestite)

È anche possibile trovare eccezioni non gestite nell'eccezione gestita nella pagina Registri eventi dell'applicazione di Strumenti di diagnostica nel portale di Azure, come illustrato nello screenshot seguente.

In questo caso, viene visualizzato lo stesso messaggio di errore registrato tramite il codice. Tuttavia, si perde una certa flessibilità nel modo in cui è possibile personalizzare le query nei log di traccia di Application Insights.

Funzionalità Snapshot Debugger di Application Insights

Le eccezioni non gestite vengono registrate anche nella pagina Registri eventi dell'applicazione, come illustrato nel testo di output nella sezione successiva. Tuttavia, è anche possibile abilitare il debugger di snapshot di Application Insights. Questo approccio non richiede l'aggiunta di codice all'applicazione.

Funzionalità registri eventi dell'applicazione (eccezioni non gestite)

L'output seguente proviene dalla pagina Registri eventi dell'applicazione di Strumenti di diagnostica nella portale di Azure. Mostra un testo di esempio di un'eccezione dell'applicazione non gestita:

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

Una differenza rispetto all'eccezione gestita nel log applicazioni è l'esistenza dello stack che identifica il metodo e la riga da cui viene generata l'eccezione. Inoltre, è possibile presupporre in modo sicuro che la funzionalità Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware contenga codice per intercettare questa eccezione non gestita in modo che la terminazione del processo venga evitata. L'eccezione viene visualizzata in Application Insights nella scheda Eccezioni della pagina Errori , come illustrato nello screenshot seguente.

In questa visualizzazione vengono visualizzate tutte le eccezioni, non solo quella che si sta cercando. La rappresentazione grafica di tutte le eccezioni che si verificano nell'applicazione è utile per ottenere una panoramica dell'integrità del sistema. Il dashboard di Application Insights è più utile visivamente rispetto ai registri eventi dell'applicazione.

Funzionalità di monitoraggio proattivo della CPU

Durante scenari di utilizzo eccessivo della CPU, è possibile usare lo strumento di monitoraggio proattivo della CPU. Per informazioni su questo strumento, vedere Attenuare i problemi di CPU prima che si verifichino. L'immagine seguente mostra la pagina Monitoraggio proattivo cpu in Strumenti di diagnostica.

È consigliabile considerare l'utilizzo della CPU dell'80% o più come una situazione critica che richiede un'analisi immediata. Nella pagina Monitoraggio proattivo CPU è possibile impostare lo scenario per cui si vuole acquisire un dump della memoria in base alle categorie di monitoraggio dei dati seguenti:

Soglia CPU
Secondi soglia
Frequenza monitoraggio

Soglia CPU identifica la quantità di CPU utilizzata dal processo di destinazione (in questo caso W3WP). Threshold Seconds è la quantità di tempo in cui la CPU è stata usata alla soglia della CPU. Ad esempio, se è presente un utilizzo della CPU del 75% per un totale di 30 secondi, verrà acquisito il dump della memoria. Come configurato nella pagina Monitoraggio proattivo della CPU, il processo verrà controllato per verificare la presenza di violazioni della soglia ogni 15 secondi.

Funzionalità di correzione automatica (limite di memoria)

La funzionalità di correzione automatica (limite di memoria) è utile per acquisire un dump della memoria se il processo utilizza più memoria del previsto. Anche in questo caso, prestare attenzione al bitness (32 o 64). Se si verifica un utilizzo elevato della memoria nel contesto del processo a 32 bit e si prevede il consumo di memoria, è possibile impostare la velocità di bit su 64. In genere, se si modifica il bitness, è necessario ricompilare anche l'applicazione.

La modifica del bitness non riduce la quantità di memoria usata. Consente al processo di usare più di 4 GB di memoria totale. Tuttavia, se l'utilizzo della memoria non è quello previsto, è possibile usare questa funzionalità per determinare l'utilizzo della memoria. È quindi possibile eseguire un'azione per controllare il consumo di memoria.

Nella sezione "Expanded app Azure Service debugging feature description" (Descrizioni delle funzionalità di debug del servizio) è possibile visualizzare il collegamento a Correzione automatica nel riquadro Strumenti di diagnostica nella prima schermata. Selezionare il collegamento per passare direttamente alla funzionalità oppure selezionare il riquadro ed esaminare tutti gli strumenti disponibili nella pagina Strumenti di diagnostica. Per altre informazioni, vedere la sezione "Correzione automatica" di app Azure Panoramica della diagnostica del servizio.

La funzionalità di correzione automatica è illustrata nello screenshot seguente.

Quando si seleziona il riquadro Limite memoria, è possibile immettere un valore di memoria che attiva l'acquisizione di un dump di memoria quando tale limite di memoria viene violato. Ad esempio, se si immette 6291456 come valore, viene eseguito un dump della memoria del processo W3WP quando vengono utilizzati 6 GB di memoria.

La funzionalità Raccogli un dump della memoria è utile in questo scenario se il problema si verifica o riproducibile. Questa funzionalità raccoglie rapidamente un dump della memoria su richiesta manuale. Per altre informazioni, vedere la sezione "Raccogliere un dump della memoria".

Descrizioni dei comandi espanse

L'arte della raccolta di dump di memoria richiede tempo per studiare, sperimentare e perfetto. Come si è appreso, procedure diverse si basano sui sintomi visualizzati dal processo, come indicato nella tabella nella sezione "Descrizioni degli scenari di processo espanso". Al contrario, la tabella seguente confronta il comando di acquisizione del dump della memoria del servizio app Azure con il comando procdump eseguito manualmente dalla console Kudu.

Scenario	comando app Azure Service	Comando procdump generale
Non rispondere o rallentare	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -n 3 -s # <PID>`
Arresto anomalo (terminazione del processo)	Usa DbgHost per acquisire il dump della memoria	`procdump -accepteula -ma -t <PID>`
Arresto anomalo (eccezioni gestite)	Nessuno (Application Insights)	`procdump -accepteula -ma -e 1 -f <filter> <PID>`
Arresto anomalo (eccezioni non gestite)	Nessuno (Debugger snapshot di Application Insights)	`procdump -accepteula -ma -e <PID>`
Utilizzo eccessivo della CPU	`procdump -accepteula -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -n 3 -s # -c 80 <PID>`
Consumo eccessivo di memoria	`procdump -accepteula -r -dc "Message" -ma <PID> <PATH>`	`procdump -accepteula -ma -m 2000 <PID>`

I comandi usati nelle funzionalità di acquisizione del dump della memoria in app Azure Servizio differiscono dai comandi procdump che si userebbero se sono stati acquisiti manualmente i dump. Se si esamina la sezione precedente, è necessario notare che la funzionalità del portale della raccolta di dump della memoria in app Azure Servizio espone la configurazione. Ad esempio, nello scenario di utilizzo eccessivo della memoria nella tabella, il comando eseguito dalla piattaforma non contiene una soglia di memoria. Tuttavia, il comando visualizzato nella colonna generale del comando procdump specifica una soglia di memoria.

Uno strumento denominato DaaS (Diagnostica come servizio) è responsabile della gestione e del monitoraggio della configurazione specificata nel portale di debug del servizio app Azure. Questo strumento viene eseguito come processo Web nelle macchine virtuali (VM) che eseguono l'app Web. Un vantaggio di questo strumento è che è possibile specificare una macchina virtuale specifica nella web farm. Se si tenta di acquisire un dump della memoria usando direttamente procdump, può essere difficile identificare, impostare come destinazione, accedere ed eseguire tale comando in un'istanza specifica. Per altre informazioni su DaaS, vedere DaaS - Diagnostica come servizio per i siti Web di Azure.

Un utilizzo eccessivo della CPU è un altro motivo per cui la piattaforma gestisce la raccolta di dump della memoria in modo che corrispondano ai modelli di procdump consigliati. Il comando procdump, come illustrato nella tabella precedente, raccoglie tre dump-n 3 di memoria completa () a distanza di 30 secondi (-ma-s #, in cui # è 30) quando l'utilizzo della CPU è maggiore o uguale all'80% (-c 80). Infine, si specifica l'ID del processo (<PID>) al comando : procdump -accepteula -ma -n 3 -s # -c 80 <PID>.

È possibile visualizzare la configurazione del portale nella sezione "Monitoraggio proattivo della CPU". Per brevità, questa sezione mostra solo le prime tre opzioni di configurazione: Soglia CPU (-c), Soglia secondi (-s) e Frequenza di monitoraggio. Lo screenshot seguente illustra che Configura azione, Azioni massime (-n) e Durata massima sono funzionalità aggiuntive disponibili.

Dopo aver studiato i diversi approcci per l'acquisizione dei dump di memoria, il passaggio successivo consiste nell'eseguire acquisizioni. È possibile usare esempi di codice in GitHub insieme ai lab di debug IIS e Funzioni di Azure per simulare ognuno degli scenari elencati nelle due tabelle. Dopo aver distribuito il codice nella piattaforma del servizio app Azure, è possibile usare questi strumenti per acquisire il dump della memoria in ogni scenario specifico. Nel corso del tempo e dopo la pratica, è possibile perfezionare l'approccio per l'acquisizione di dump di memoria usando le funzionalità di debug del servizio app Azure. L'elenco seguente contiene alcuni suggerimenti da considerare quando si continua a ottenere informazioni sulla raccolta di dump della memoria:

L'acquisizione di un dump della memoria utilizza risorse di sistema significative e interrompe ulteriormente le prestazioni.
L'acquisizione dei dump di memoria sulla prima probabilità non è ottimale perché probabilmente si acquisisce un numero eccessivo di immagini. Questi dump di memoria first-chance sono probabilmente irrilevanti.
È consigliabile disabilitare Application Insights prima di acquisire un dump della memoria W3WP.

Dopo aver raccolto il dump della memoria, il passaggio successivo consiste nell'analizzare il dump della memoria per determinare la causa del problema e quindi correggere il problema.

Passaggi successivi (analisi del dump della memoria)

La discussione su come analizzare i dump della memoria non rientra nell'ambito di questo articolo. Esistono tuttavia molte risorse per tale argomento, ad esempio la serie di training Defrag Tools e un elenco di comandi WinDbg che devono conoscere.

È possibile che sia stata notata l'opzione Configura azione nello screenshot precedente. L'impostazione predefinita per questa opzione è CollectAndKill. Questa impostazione indica che il processo viene terminato dopo la raccolta del dump della memoria. Un'impostazione denominata CollectKillAndAnalyze analizza il dump della memoria raccolto. In questo scenario, l'analisi della piattaforma potrebbe trovare il problema in modo che non sia necessario aprire il dump della memoria in WinDbg e analizzarlo.

Sono disponibili altre opzioni per la risoluzione dei problemi di prestazioni e la diagnosi dei problemi di prestazioni nella piattaforma del servizio app Azure. Questo articolo è incentrato sulla raccolta di dump della memoria e fornisce alcune raccomandazioni per affrontare la diagnosi usando questi metodi. Se hai già studiato, esperto e perfezionato le tue procedure di raccolta, e funzionano bene per te, dovresti continuare a usare queste procedure.

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.

Condividi tramite