2015-11-12 11 views
7

Quando si cattura un file di dump e lo si analizza (ad esempio in WinDbg), ricevo spesso l'avviso che i dati potrebbero non essere accurati, oppure i comandi potrebbero non essere accessibili, perché il processo si trovava nel mezzo di GC quando veniva raccolto il file di dump.Come acquisire un dump della memoria di processo di un processo .NET quando .NET non si trova nel mezzo di una garbage collection (GC)

Quando si esegue l'analisi della memoria, spesso lo facciamo perché la memoria del processo è alta e la pressione della memoria è alta, quindi credo che le forze siano spesso da .NET a GC.

Come evitare di eseguire i dump durante un GC? C'è un modo per sapere quando è sicuro catturare il file dump?

+2

Si consiglia di utilizzare PerfView che è stato progettato pensando a questo problema. Aiuto | La Guida utenti ha una sezione chiamata "Raccolta heap GC: bloccare o non congelare?" che discute questo. Il collegamento per il download è: http://www.microsoft.com/en-us/download/details.aspx?id=28567 –

+0

Inviami una riga se hai bisogno di aiuto implementando/testando la mia risposta. –

+0

@Mark: nella tua applicazione, ha dei processi in background? Voglio dire, se l'utente non sta usando può ancora elaborare qualcosa dietro la scena? – CharithJ

risposta

4

Non sono esperto in questo settore ma ho notato che è possibile utilizzare i contatori delle prestazioni del runtime .NET per il monitoraggio di alcune cose interessanti - uno di questi è il numero di byte che è stato assegnato dal garbage collector durante la sua ultima collezione. La descrizione di Allocated Bytes/second in Performance Counters in the .NET Framework paese:

Visualizza il numero di byte al secondo allocati sul mucchio garbage collection. Questo contatore viene aggiornato alla fine di ogni raccolta di dati inutili, non ad ogni allocazione. Questo contatore non è una media nel tempo; mostra la differenza tra i valori osservati negli ultimi due campioni divisi per la durata dell'intervallo di campionamento.

Secondo le mie prove, se si imposta l'intervallo di aggiornamento del monitor prestazioni a 1 secondo e prendere un buon guardare l'indicatore relativo Allocated Bytes/second, sembra mostrare un valore di 0 dopo una raccolta è stata completata. Quindi suppongo che tu possa derivare da questo valore se una raccolta è in corso o meno.

L'ho verificato creando una piccola applicazione in VS 2015 che ha la capacità di mostrare se è in corso una garbage collection. Il valore dell'indicatore era diverso da 0 se era il caso.

Aggiornamento (Grazie Thomas)

E 'possibile utilizzare ProcDump per monitorare il contatore delle prestazioni e creare la discarica in modo automatico. Il modo corretto per farlo sarebbe: procdump ProcessName -s 1 -ma -pl "\.NET CLR Memory(ProcessName)\Allocated Bytes/second" 1000 che attiverà la discarica se il valore scende sotto il migliaio.

Questo dovrebbe funzionare in quanto il valore è solo zero se non è in corso alcuna garbage collection.

Se non si utilizza una versione inglese del sistema operativo, è necessario individuare il nome specifico della lingua corretta del contatore delle prestazioni (è possibile fare riferimento al collegamento MSDN fornito sopra e passare a un altro lingua lì). Per esempio. il nome tedesco sarebbe "\.NET CLR-Speicher(ProcessName)\Zugeordnete Bytes/Sek.".

+0

Grazie per la risposta. Potresti rendere la risposta un po 'più pratica? Significa che possiamo usare [ProcDump] (https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx) con l'opzione '-pl'? Se sì, quale? Potete fornire un codice di esempio per dimostrare la teoria? –

+1

Grazie per la risposta aggiornata. Lo proverò. –

+0

@Thomas Grazie per la taglia ;-) –

Problemi correlati