Recolha de lixo e desempenho
Este artigo descreve problemas relacionados à coleta de lixo e uso de memória. Ele aborda problemas relacionados ao heap gerenciado e explica como minimizar o efeito da coleta de lixo em seus aplicativos. Cada problema tem links para procedimentos que você pode usar para investigar problemas.
Ferramentas de análise de desempenho
As seções a seguir descrevem as ferramentas disponíveis para investigar o uso de memória e problemas de coleta de lixo. Os procedimentos fornecidos posteriormente neste artigo referem-se a essas ferramentas.
Contadores de desempenho de memória
Você pode usar contadores de desempenho para coletar dados de desempenho. Para obter instruções, consulte Criação de perfil de tempo de execução. A categoria de memória CLR do .NET dos contadores de desempenho, conforme descrito em Contadores de desempenho no .NET, fornece informações sobre o coletor de lixo.
Depuração com SOS
Você pode usar o Depurador do Windows (WinDbg) para inspecionar objetos no heap gerenciado.
Para instalar o WinDbg, instale as Ferramentas de Depuração para Windows a partir da página Baixar Ferramentas de Depuração para Windows .
Coleta de lixo ETW Eventos
O rastreamento de eventos para Windows (ETW) é um sistema de rastreamento que complementa o suporte à criação de perfil e depuração fornecido pelo .NET. A partir do .NET Framework 4, os eventos ETW de coleta de lixo capturam informações úteis para analisar o heap gerenciado de um ponto de vista estatístico. Por exemplo, o GCStart_V1
evento, que é gerado quando uma coleta de lixo está prestes a ocorrer, fornece as seguintes informações:
- Que geração de objetos está sendo coletada.
- O que desencadeou a recolha de lixo.
- Tipo de coleta de lixo (simultânea ou não simultânea).
O log de eventos do ETW é eficiente e não mascarará nenhum problema de desempenho associado à coleta de lixo. Um processo pode fornecer seus próprios eventos em conjunto com eventos ETW. Quando registrados, os eventos do aplicativo e os eventos de coleta de lixo podem ser correlacionados para determinar como e quando ocorrem problemas de heap. Por exemplo, um aplicativo de servidor pode fornecer eventos no início e no final de uma solicitação de cliente.
A API de criação de perfil
As interfaces de criação de perfil CLR (Common Language Runtime) fornecem informações detalhadas sobre os objetos que foram afetados durante a coleta de lixo. Um criador de perfil pode ser notificado quando uma coleta de lixo começa e termina. Ele pode fornecer relatórios sobre os objetos no heap gerenciado, incluindo uma identificação de objetos em cada geração. Para obter mais informações, consulte Visão geral da criação de perfil.
Os criadores de perfil podem fornecer informações abrangentes. No entanto, profilers complexos podem potencialmente modificar o comportamento de um aplicativo.
Monitoramento de recursos do domínio do aplicativo
A partir do .NET Framework 4, o monitoramento de recursos de domínio de aplicativo (ARM) permite que os hosts monitorem o uso da CPU e da memória por domínio de aplicativo. Para obter mais informações, consulte Application Domain Resource Monitoring.
Resolver problemas de desempenho
O primeiro passo é determinar se o problema é realmente a coleta de lixo. Se você determinar que sim, selecione na lista a seguir para solucionar o problema.
- Uma exceção de falta de memória é lançada
- O processo usa muita memória
- O coletor de lixo não recupera objetos com rapidez suficiente
- A pilha gerenciada está muito fragmentada
- As pausas para a recolha de lixo são demasiado longas
- A geração 0 é demasiado grande
- O uso da CPU durante uma coleta de lixo é muito alto
Problema: uma exceção de falta de memória é lançada
Há dois casos legítimos para que um conseguiu OutOfMemoryException ser lançado:
Ficando sem memória virtual.
O coletor de lixo aloca memória do sistema em segmentos de um tamanho pré-determinado. Se uma alocação exigir um segmento adicional, mas não houver nenhum bloco livre contíguo no espaço de memória virtual do processo, a alocação para o heap gerenciado falhará.
Não ter memória física suficiente para alocar.
Verificações de desempenho |
---|
Determine se a exceção de falta de memória é gerenciada. Determine a quantidade de memória virtual que pode ser reservada. Determine se há memória física suficiente. |
Se você determinar que a exceção não é legítima, entre em contato com o Suporte e Atendimento ao Cliente Microsoft com as seguintes informações:
- A pilha com a exceção gerenciada de falta de memória.
- Despejo de memória total.
- Dados que provam que não é uma exceção legítima de falta de memória, incluindo dados que mostram que a memória virtual ou física não é um problema.
Problema: O processo usa muita memória
Uma suposição comum é que a exibição de uso de memória na guia Desempenho do Gerenciador de Tarefas do Windows pode indicar quando muita memória está sendo usada. No entanto, essa exibição pertence ao conjunto de trabalho; ele não fornece informações sobre o uso de memória virtual.
Se você determinar que o problema é causado pelo heap gerenciado, deverá medir o heap gerenciado ao longo do tempo para determinar quaisquer padrões.
Se você determinar que o problema não é causado pelo heap gerenciado, deverá usar a depuração nativa.
Problema: O coletor de lixo não recupera objetos com rapidez suficiente
Quando parece que os objetos não estão sendo recuperados como esperado para a coleta de lixo, você deve determinar se há referências fortes a esses objetos.
Você também pode encontrar esse problema se não tiver havido coleta de lixo para a geração que contém um objeto morto, o que indica que o finalizador para o objeto morto não foi executado. Por exemplo, isso é possível quando você está executando um aplicativo de apartamento de thread único (STA) e o thread que atende a fila do finalizador não pode chamá-lo.
Verificações de desempenho |
---|
Verifique as referências a objetos. Determine se um finalizador foi executado. Determine se há objetos aguardando para serem finalizados. |
Problema: o heap gerenciado está muito fragmentado
O nível de fragmentação é calculado como a proporção de espaço livre sobre o total de memória alocada para a geração. Para a geração 2, um nível aceitável de fragmentação não é superior a 20%. Como a geração 2 pode ficar muito grande, a proporção de fragmentação é mais importante do que o valor absoluto.
Ter muito espaço livre na geração 0 não é um problema, porque esta é a geração onde novos objetos são alocados.
A fragmentação sempre ocorre na pilha de objeto grande porque ela não é compactada. Os objetos livres adjacentes são naturalmente recolhidos em um único espaço para satisfazer grandes solicitações de alocação de objetos.
A fragmentação pode tornar-se um problema nas gerações 1 e 2. Se essas gerações tiverem uma grande quantidade de espaço livre após uma coleta de lixo, o uso de objetos de um aplicativo pode precisar de modificação, e você deve considerar reavaliar a vida útil de objetos de longo prazo.
A fixação excessiva de objetos pode aumentar a fragmentação. Se a fragmentação for alta, muitos objetos podem ter sido fixados.
Se a fragmentação da memória virtual estiver impedindo o coletor de lixo de adicionar segmentos, as causas podem ser uma das seguintes:
Carga e descarga frequente de muitos pequenos conjuntos.
Manter muitas referências a objetos COM ao interoperar com código não gerenciado.
Criação de grandes objetos transitórios, o que faz com que o heap de objeto grande aloque e libere segmentos de heap com freqüência.
Ao hospedar o CLR, um aplicativo pode solicitar que o coletor de lixo mantenha seus segmentos. Isso reduz a frequência de alocações de segmentos. Isso é feito usando o sinalizador STARTUP_HOARD_GC_VM na enumeração STARTUP_FLAGS.
Verificações de desempenho |
---|
Determine a quantidade de espaço livre na pilha gerenciada. Determine o número de objetos fixados. |
Se você acha que não há uma causa legítima para a fragmentação, entre em contato com o Suporte e Atendimento ao Cliente Microsoft.
Problema: as pausas na coleta de lixo são muito longas
A coleta de lixo opera em tempo real, portanto, um aplicativo deve ser capaz de tolerar algumas pausas. Um critério para soft real time é que 95% das operações devem terminar a tempo.
Na coleta de lixo simultânea, os threads gerenciados podem ser executados durante uma coleta, o que significa que as pausas são muito mínimas.
As coletas efêmeras de lixo (gerações 0 e 1) duram apenas alguns milissegundos, portanto, diminuir as pausas geralmente não é viável. No entanto, você pode diminuir as pausas nas coleções de geração 2 alterando o padrão de solicitações de alocação por um aplicativo.
Outro método, mais preciso, é usar eventos ETW de coleta de lixo. Você pode encontrar os horários das coleções adicionando as diferenças de carimbo de data/hora para uma sequência de eventos. Toda a sequência de coleta inclui a suspensão do motor de execução, a própria coleta de lixo e a retomada do motor de execução.
Você pode usar as Notificações de Coleta de Lixo para determinar se um servidor está prestes a ter uma coleção de geração 2 e se as solicitações de redirecionamento para outro servidor podem facilitar quaisquer problemas com pausas.
Verificações de desempenho |
---|
Determine o período de tempo em uma coleta de lixo. Determine o que causou uma coleta de lixo. |
Problema: a geração 0 é muito grande
É provável que a geração 0 tenha um número maior de objetos em um sistema de 64 bits, especialmente quando você usa a coleta de lixo do servidor em vez da coleta de lixo da estação de trabalho. Isso ocorre porque o limite para acionar uma coleta de lixo da geração 0 é maior nesses ambientes, e as coletas da geração 0 podem ficar muito maiores. O desempenho é melhorado quando um aplicativo aloca mais memória antes que uma coleta de lixo seja acionada.
Problema: o uso da CPU durante uma coleta de lixo é muito alto
O uso da CPU será alto durante uma coleta de lixo. Se uma quantidade significativa de tempo de processo é gasta em uma coleta de lixo, o número de coletas é muito frequente ou a coleta está durando muito tempo. Uma maior taxa de alocação de objetos na pilha gerenciada faz com que a coleta de lixo ocorra com mais frequência. A diminuição da taxa de alocação reduz a frequência das coletas de lixo.
Você pode monitorar as taxas de alocação usando o contador de Allocated Bytes/second
desempenho. Para obter mais informações, consulte Contadores de desempenho no .NET.
A duração de uma coleção é principalmente um fator do número de objetos que sobrevivem após a alocação. O coletor de lixo deve passar por uma grande quantidade de memória se muitos objetos permanecerem a serem coletados. O trabalho para compactar os sobreviventes é demorado. Para determinar quantos objetos foram manipulados durante uma coleção, defina um ponto de interrupção no depurador no final de uma coleta de lixo para uma geração especificada.
Verificações de desempenho |
---|
Determine se o alto uso da CPU é causado pela coleta de lixo. Defina um ponto de interrupção no final da coleta de lixo. |
Diretrizes de solução de problemas
Esta seção descreve as diretrizes que você deve considerar ao iniciar suas investigações.
Coleta de lixo de estação de trabalho ou servidor
Determine se você está usando o tipo correto de coleta de lixo. Se seu aplicativo usa vários threads e instâncias de objeto, use a coleta de lixo do servidor em vez da coleta de lixo da estação de trabalho. A coleta de lixo do servidor opera em vários threads, enquanto a coleta de lixo da estação de trabalho requer várias instâncias de um aplicativo para executar seus próprios threads de coleta de lixo e competir pelo tempo da CPU.
Um aplicativo que tem uma carga baixa e que executa tarefas com pouca frequência em segundo plano, como um serviço, pode usar a coleta de lixo da estação de trabalho com a coleta de lixo simultânea desabilitada.
Quando medir o tamanho da pilha gerenciada
A menos que você esteja usando um criador de perfil, você terá que estabelecer um padrão de medição consistente para diagnosticar efetivamente problemas de desempenho. Considere os seguintes pontos para estabelecer um cronograma:
- Se você medir após uma coleta de lixo de geração 2, toda a pilha gerenciada estará livre de lixo (objetos mortos).
- Se você medir imediatamente após uma coleta de lixo da geração 0, os objetos das gerações 1 e 2 ainda não serão coletados.
- Se você medir imediatamente antes de uma coleta de lixo, você medirá o máximo de alocação possível antes que a coleta de lixo comece.
- A medição durante uma coleta de lixo é problemática, porque as estruturas de dados do coletor de lixo não estão em um estado válido para a travessia e podem não ser capazes de fornecer os resultados completos. Esta ação é propositada.
- Quando você estiver usando a coleta de lixo da estação de trabalho com a coleta de lixo simultânea, os objetos recuperados não são compactados, portanto, o tamanho da pilha pode ser o mesmo ou maior (a fragmentação pode fazer com que pareça ser maior).
- A coleta simultânea de lixo na geração 2 é atrasada quando a carga de memória física é muito alta.
O procedimento a seguir descreve como definir um ponto de interrupção para que você possa medir o heap gerenciado.
Para definir um ponto de interrupção no final da coleta de lixo
No WinDbg com a extensão do depurador SOS carregada, digite o seguinte comando:
bp mscorwks!WKS::GCHeap::RestartEE "j (dwo(mscorwks!WKS::GCHeap::GcCondemnedGeneration)==2) 'kb';'g'"
Defina
GcCondemnedGeneration
para a geração desejada. Este comando requer símbolos privados.Este comando força uma quebra se
RestartEE
for executado após os objetos da geração 2 terem sido recuperados para coleta de lixo.Na coleta de lixo do servidor, apenas um thread chama
RestartEE
, portanto, o ponto de interrupção ocorrerá apenas uma vez durante uma coleta de lixo de geração 2.
Procedimentos de verificação do desempenho
Esta seção descreve os seguintes procedimentos para isolar a causa do problema de desempenho:
- Determine se o problema é causado pela coleta de lixo.
- Determine se a exceção de falta de memória é gerenciada.
- Determine a quantidade de memória virtual que pode ser reservada.
- Determine se há memória física suficiente.
- Determine a quantidade de memória que o heap gerenciado está confirmando.
- Determine a quantidade de memória que o heap gerenciado reserva.
- Determine objetos grandes na geração 2.
- Determinar referências a objetos.
- Determine se um finalizador foi executado.
- Determine se há objetos aguardando para serem finalizados.
- Determine a quantidade de espaço livre na pilha gerenciada.
- Determine o número de objetos fixados.
- Determine o período de tempo em uma coleta de lixo.
- Determine o que desencadeou uma coleta de lixo.
- Determine se o alto uso da CPU é causado pela coleta de lixo.
Para determinar se o problema é causado pela coleta de lixo
Examine os dois contadores de desempenho de memória a seguir:
% Tempo em GC. Exibe a porcentagem de tempo decorrido que foi gasto executando uma coleta de lixo após o último ciclo de coleta de lixo. Use esse contador para determinar se o coletor de lixo está gastando muito tempo para disponibilizar espaço de pilha gerenciado. Se o tempo gasto na coleta de lixo for relativamente baixo, isso pode indicar um problema de recursos fora da pilha gerenciada. Esse contador pode não ser preciso quando a coleta de lixo simultânea ou em segundo plano está envolvida.
# Total de bytes comprometidos. Exibe a quantidade de memória virtual atualmente confirmada pelo coletor de lixo. Use esse contador para determinar se a memória consumida pelo coletor de lixo é uma parte excessiva da memória que seu aplicativo usa.
A maioria dos contadores de desempenho de memória são atualizados no final de cada coleta de lixo. Portanto, eles podem não refletir as condições atuais sobre as quais você deseja informações.
Para determinar se a exceção de falta de memória é gerenciada
No depurador WinDbg ou Visual Studio com a extensão do depurador SOS carregada, digite o comando print exception (
pe
):!pe
Se a exceção for gerenciada, OutOfMemoryException será exibida como o tipo de exceção, conforme mostrado no exemplo a seguir.
Exception object: 39594518 Exception type: System.OutOfMemoryException Message: <none> InnerException: <none> StackTrace (generated):
Se a saída não especificar uma exceção, você terá que determinar de qual thread a exceção de falta de memória é. Digite o seguinte comando no depurador para mostrar todos os threads com suas pilhas de chamadas:
~\*kb
O thread com a pilha que tem chamadas de exceção é indicado pelo
RaiseTheException
argumento. Este é o objeto de exceção gerenciado.28adfb44 7923918f 5b61f2b4 00000000 5b61f2b4 mscorwks!RaiseTheException+0xa0
Você pode usar o comando a seguir para despejar exceções aninhadas.
!pe -nested
Se você não encontrar exceções, a exceção de falta de memória originou-se de código não gerenciado.
Para determinar quanta memória virtual pode ser reservada
No WinDbg com a extensão do depurador SOS carregada, digite o seguinte comando para obter a maior região livre:
!address -summary
A maior região livre é exibida como mostrado na saída a seguir.
Largest free region: Base 54000000 - Size 0003A980
Neste exemplo, o tamanho da maior região livre é de aproximadamente 24000 KB (3A980 em hexadecimal). Essa região é muito menor do que o coletor de lixo precisa para um segmento.
-ou-
Use o
vmstat
comando:!vmstat
A maior região livre é o maior valor na coluna MÁXIMO, conforme mostrado na saída a seguir.
TYPE MINIMUM MAXIMUM AVERAGE BLK COUNT TOTAL ~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~~~ ~~~~ Free: Small 8K 64K 46K 36 1,671K Medium 80K 864K 349K 3 1,047K Large 1,384K 1,278,848K 151,834K 12 1,822,015K Summary 8K 1,278,848K 35,779K 51 1,824,735K
Para determinar se há memória física suficiente
Inicie o Gestor de Tarefas do Windows.
Na guia, observe o
Performance
valor comprometido. (No Windows 7, vejaCommit (KB)
noSystem group
.)Se o
Total
estiver perto doLimit
, você está com pouca memória física.
Para determinar a quantidade de memória que o heap gerenciado está confirmando
Use o
# Total committed bytes
contador de desempenho de memória para obter o número de bytes que o heap gerenciado está confirmando. O coletor de lixo compromete pedaços em um segmento conforme necessário, não todos ao mesmo tempo.Nota
Não use o contador de desempenho, porque ele não representa o
# Bytes in all Heaps
uso real da memória pelo heap gerenciado. O tamanho de uma geração está incluído neste valor e é, na verdade, o seu tamanho limite, ou seja, o tamanho que induz uma coleta de lixo se a geração estiver cheia de objetos. Portanto, esse valor geralmente é zero.
Para determinar a quantidade de memória que o heap gerenciado reserva
Use o contador de desempenho de
# Total reserved bytes
memória.O coletor de lixo reserva memória em segmentos e você pode determinar onde um segmento começa usando o
eeheap
comando.Importante
Embora seja possível determinar a quantidade de memória que o coletor de lixo aloca para cada segmento, o tamanho do segmento é específico da implementação e está sujeito a alterações a qualquer momento, inclusive em atualizações periódicas. Seu aplicativo nunca deve fazer suposições sobre ou depender de um tamanho de segmento específico, nem deve tentar configurar a quantidade de memória disponível para alocações de segmento.
No depurador WinDbg ou Visual Studio com a extensão do depurador SOS carregada, digite o seguinte comando:
!eeheap -gc
O resultado é o seguinte.
Number of GC Heaps: 2 ------------------------------ Heap 0 (002db550) generation 0 starts at 0x02abe29c generation 1 starts at 0x02abdd08 generation 2 starts at 0x02ab0038 ephemeral segment allocation context: none segment begin allocated size 02ab0000 02ab0038 02aceff4 0x0001efbc(126908) Large object heap starts at 0x0aab0038 segment begin allocated size 0aab0000 0aab0038 0aab2278 0x00002240(8768) Heap Size 0x211fc(135676) ------------------------------ Heap 1 (002dc958) generation 0 starts at 0x06ab1bd8 generation 1 starts at 0x06ab1bcc generation 2 starts at 0x06ab0038 ephemeral segment allocation context: none segment begin allocated size 06ab0000 06ab0038 06ab3be4 0x00003bac(15276) Large object heap starts at 0x0cab0038 segment begin allocated size 0cab0000 0cab0038 0cab0048 0x00000010(16) Heap Size 0x3bbc(15292) ------------------------------ GC Heap Size 0x24db8(150968)
Os endereços indicados por "segmento" são os endereços iniciais dos segmentos.
Para determinar objetos grandes na geração 2
No depurador WinDbg ou Visual Studio com a extensão do depurador SOS carregada, digite o seguinte comando:
!dumpheap –stat
Se a pilha gerenciada for grande,
dumpheap
pode demorar um pouco para terminar.Você pode começar a analisar a partir das últimas linhas da saída, porque elas listam os objetos que usam mais espaço. Por exemplo:
2c6108d4 173712 14591808 DevExpress.XtraGrid.Views.Grid.ViewInfo.GridCellInfo 00155f80 533 15216804 Free 7a747c78 791070 15821400 System.Collections.Specialized.ListDictionary+DictionaryNode 7a747bac 700930 19626040 System.Collections.Specialized.ListDictionary 2c64e36c 78644 20762016 DevExpress.XtraEditors.ViewInfo.TextEditViewInfo 79124228 121143 29064120 System.Object[] 035f0ee4 81626 35588936 Toolkit.TlkOrder 00fcae40 6193 44911636 WaveBasedStrategy.Tick_Snap[] 791242ec 40182 90664128 System.Collections.Hashtable+bucket[] 790fa3e0 3154024 137881448 System.String Total 8454945 objects
O último objeto listado é uma cadeia de caracteres e ocupa mais espaço. Você pode examinar seu aplicativo para ver como seus objetos de cadeia de caracteres podem ser otimizados. Para ver cadeias de caracteres entre 150 e 200 bytes, digite o seguinte:
!dumpheap -type System.String -min 150 -max 200
Um exemplo dos resultados é o seguinte.
Address MT Size Gen 1875d2c0 790fa3e0 152 2 System.String HighlightNullStyle_Blotter_PendingOrder-11_Blotter_PendingOrder-11 …
Usar um inteiro em vez de uma cadeia de caracteres para um ID pode ser mais eficiente. Se a mesma string estiver sendo repetida milhares de vezes, considere a string interning. Para obter mais informações sobre a internação de cadeia de caracteres, consulte o tópico de referência para o String.Intern método.
Para determinar referências a objetos
No WinDbg com a extensão do depurador SOS carregada, digite o seguinte comando para listar referências a objetos:
!gcroot
-ou-
Para determinar as referências para um objeto específico, inclua o endereço:
!gcroot 1c37b2ac
As raízes encontradas nas pilhas podem ser falsos positivos. Para obter mais informações, use o comando
!help gcroot
.ebx:Root:19011c5c(System.Windows.Forms.Application+ThreadContext)-> 19010b78(DemoApp.FormDemoApp)-> 19011158(System.Windows.Forms.PropertyStore)-> … [omitted] 1c3745ec(System.Data.DataTable)-> 1c3747a8(System.Data.DataColumnCollection)-> 1c3747f8(System.Collections.Hashtable)-> 1c376590(System.Collections.Hashtable+bucket[])-> 1c376c98(System.Data.DataColumn)-> 1c37b270(System.Data.Common.DoubleStorage)-> 1c37b2ac(System.Double[]) Scan Thread 0 OSTHread 99c Scan Thread 6 OSTHread 484
O
gcroot
comando pode levar muito tempo para ser concluído. Qualquer objeto que não seja recuperado pela coleta de lixo é um objeto ativo. Isso significa que alguma raiz está direta ou indiretamente segurando o objeto, portantogcroot
, deve retornar informações de caminho para o objeto. Você deve examinar os gráficos retornados e ver por que esses objetos ainda são referenciados.
Para determinar se um finalizador foi executado
Execute um programa de teste que contém o seguinte código:
GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect();
Se o teste resolver o problema, isso significa que o coletor de lixo não estava recuperando objetos, porque os finalizadores para esses objetos foram suspensos. O GC.WaitForPendingFinalizers método permite que os finalizadores concluam suas tarefas e corrige o problema.
Para determinar se há objetos aguardando para serem finalizados
No depurador WinDbg ou Visual Studio com a extensão do depurador SOS carregada, digite o seguinte comando:
!finalizequeue
Observe o número de objetos que estão prontos para finalização. Se o número for alto, você deve examinar por que esses finalizadores não podem progredir ou não podem progredir rápido o suficiente.
Para obter uma saída de threads, digite o seguinte comando:
!threads -special
Este comando fornece saídas como as seguintes.
OSID Special thread type 2 cd0 DbgHelper 3 c18 Finalizer 4 df0 GC SuspendEE
O thread do finalizador indica qual finalizador, se houver, está sendo executado no momento. Quando um thread de finalizador não está executando nenhum finalizador, ele está esperando por um evento para dizer-lhe para fazer seu trabalho. Na maioria das vezes, você verá o thread do finalizador neste estado, porque ele é executado em THREAD_HIGHEST_PRIORITY e deve terminar de executar os finalizadores, se houver, muito rapidamente.
Para determinar a quantidade de espaço livre na pilha gerenciada
No depurador WinDbg ou Visual Studio com a extensão do depurador SOS carregada, digite o seguinte comando:
!dumpheap -type Free -stat
Este comando exibe o tamanho total de todos os objetos livres no heap gerenciado, conforme mostrado no exemplo a seguir.
total 230 objects Statistics: MT Count TotalSize Class Name 00152b18 230 40958584 Free Total 230 objects
Para determinar o espaço livre na geração 0, digite o seguinte comando para obter informações de consumo de memória por geração:
!eeheap -gc
Este comando exibe uma saída semelhante à seguinte. A última linha mostra o segmento efêmero.
Heap 0 (0015ad08) generation 0 starts at 0x49521f8c generation 1 starts at 0x494d7f64 generation 2 starts at 0x007f0038 ephemeral segment allocation context: none segment begin allocated size 00178250 7a80d84c 7a82f1cc 0x00021980(137600) 00161918 78c50e40 78c7056c 0x0001f72c(128812) 007f0000 007f0038 047eed28 0x03ffecf0(67103984) 3a120000 3a120038 3a3e84f8 0x002c84c0(2917568) 46120000 46120038 49e05d04 0x03ce5ccc(63855820)
Calcule o espaço utilizado pela geração 0:
? 49e05d04-0x49521f8c
O resultado é o seguinte. A geração 0 tem aproximadamente 9 MB.
Evaluate expression: 9321848 = 008e3d78
O comando a seguir despeja o espaço livre dentro do intervalo de geração 0:
!dumpheap -type Free -stat 0x49521f8c 49e05d04
O resultado é o seguinte.
------------------------------ Heap 0 total 409 objects ------------------------------ Heap 1 total 0 objects ------------------------------ Heap 2 total 0 objects ------------------------------ Heap 3 total 0 objects ------------------------------ total 409 objects Statistics: MT Count TotalSize Class Name 0015a498 409 7296540 Free Total 409 objects
Esta saída mostra que a parte de geração 0 da pilha está usando 9 MB de espaço para objetos e tem 7 MB livres. Esta análise mostra em que medida a geração 0 contribui para a fragmentação. Essa quantidade de uso de pilha deve ser descontada do valor total como a causa da fragmentação por objetos de longo prazo.
Para determinar o número de objetos fixados
No depurador WinDbg ou Visual Studio com a extensão do depurador SOS carregada, digite o seguinte comando:
!gchandles
As estatísticas exibidas incluem o número de alças fixadas, como mostra o exemplo a seguir.
GC Handle Statistics: Strong Handles: 29 Pinned Handles: 10
Para determinar o período de tempo em uma coleta de lixo
Examine o contador de desempenho de
% Time in GC
memória.O valor é calculado usando um tempo de intervalo de amostragem. Como os contadores são atualizados no final de cada coleta de lixo, a amostra atual terá o mesmo valor da amostra anterior se nenhuma coleta ocorrer durante o intervalo.
O tempo de recolha obtém-se multiplicando o tempo do intervalo da amostra pelo valor percentual.
Os dados a seguir mostram quatro intervalos de amostragem de dois segundos, para um estudo de 8 segundos. As
Gen0
colunas ,Gen1
e mostramGen2
o número total de coletas de lixo concluídas até o final do intervalo para essa geração.Interval Gen0 Gen1 Gen2 % Time in GC 1 9 3 1 10 2 10 3 1 1 3 11 3 1 3 4 11 3 1 3
Essas informações não mostram quando a coleta de lixo ocorreu, mas você pode determinar o número de coletas de lixo que ocorreram em um intervalo de tempo. Assumindo o pior cenário, a coleta de lixo de décima quinta geração 0 terminou no início do segundo intervalo, e a décima primeira geração 0 coleta de lixo terminou no final do terceiro intervalo. O tempo entre o final da décima e o final da décima primeira coleta de lixo é de cerca de 2 segundos, e o contador de desempenho mostra 3%, então a duração da décima primeira geração 0 coleta de lixo foi (2 segundos * 3% = 60ms).
No exemplo seguinte, há cinco intervalos.
Interval Gen0 Gen1 Gen2 % Time in GC 1 9 3 1 3 2 10 3 1 1 3 11 4 1 1 4 11 4 1 1 5 11 4 2 20
A coleta de lixo da segunda geração 2 começou durante o quarto intervalo e terminou no quinto intervalo. Assumindo o pior cenário, a última coleta de lixo foi para uma coleta de geração 0 que terminou no início do terceiro intervalo, e a coleta de lixo de geração 2 terminou no final do quinto intervalo. Portanto, o tempo entre o fim da coleta de lixo da geração 0 e o fim da coleta de lixo da geração 2 é de 4 segundos. Como o contador é de
% Time in GC
20%, o tempo máximo que a coleta de lixo da geração 2 poderia ter levado é (4 segundos * 20% = 800ms).Como alternativa, você pode determinar o comprimento de uma coleta de lixo usando eventos ETW de coleta de lixo e analisar as informações para determinar a duração da coleta de lixo.
Por exemplo, os dados a seguir mostram uma sequência de eventos que ocorreu durante uma coleta de lixo não simultânea.
Timestamp Event name 513052 GCSuspendEEBegin_V1 513078 GCSuspendEEEnd 513090 GCStart_V1 517890 GCEnd_V1 517894 GCHeapStats 517897 GCRestartEEBegin 517918 GCRestartEEEnd
Suspender o thread gerenciado levou 26us (
GCSuspendEEEnd
–GCSuspendEEBegin_V1
).A coleta de lixo real levou 4,8ms (
GCEnd_V1
–GCStart_V1
).Retomar os threads gerenciados levou 21us (
GCRestartEEEnd
–GCRestartEEBegin
).A saída a seguir fornece um exemplo de coleta de lixo em segundo plano e inclui os campos de processo, thread e evento. (Nem todos os dados são mostrados.)
timestamp(us) event name process thread event field 42504385 GCSuspendEEBegin_V1 Test.exe 4372 1 42504648 GCSuspendEEEnd Test.exe 4372 42504816 GCStart_V1 Test.exe 4372 102019 42504907 GCStart_V1 Test.exe 4372 102020 42514170 GCEnd_V1 Test.exe 4372 42514204 GCHeapStats Test.exe 4372 102020 42832052 GCRestartEEBegin Test.exe 4372 42832136 GCRestartEEEnd Test.exe 4372 63685394 GCSuspendEEBegin_V1 Test.exe 4744 6 63686347 GCSuspendEEEnd Test.exe 4744 63784294 GCRestartEEBegin Test.exe 4744 63784407 GCRestartEEEnd Test.exe 4744 89931423 GCEnd_V1 Test.exe 4372 102019 89931464 GCHeapStats Test.exe 4372
O
GCStart_V1
evento em 42504816 indica que esta é uma coleta de lixo em segundo plano, porque o último campo é1
. Isso se torna a coleta de lixo nº 102019.O
GCStart
evento ocorre porque há uma necessidade de uma coleta de lixo efêmera antes de iniciar uma coleta de lixo em segundo plano. Trata-se da coleta de lixo nº 102020.Em 42514170, a coleta de lixo nº 102020 termina. Os threads gerenciados são reiniciados neste ponto. Isso é concluído no thread 4372, que acionou essa coleta de lixo em segundo plano.
Na rosca 4744, ocorre uma suspensão. Este é o único momento em que a coleta de lixo em segundo plano precisa suspender threads gerenciados. Esta duração é de aproximadamente 99ms ((63784407-63685394)/1000).
O
GCEnd
evento para a coleta de lixo de fundo está no 89931423. Isso significa que a coleta de lixo de fundo durou cerca de 47 segundos ((89931423-42504816)/1000).Enquanto os threads gerenciados estão em execução, você pode ver qualquer número de coletas de lixo efêmeras ocorrendo.
Para determinar o que desencadeou uma coleta de lixo
No depurador WinDbg ou Visual Studio com a extensão do depurador SOS carregada, digite o seguinte comando para mostrar todos os threads com suas pilhas de chamadas:
~*kb
Este comando exibe uma saída semelhante à seguinte.
0012f3b0 79ff0bf8 mscorwks!WKS::GCHeap::GarbageCollect 0012f454 30002894 mscorwks!GCInterface::CollectGeneration+0xa4 0012f490 79fa22bd fragment_ni!request.Main(System.String[])+0x48
Se a coleta de lixo foi causada por uma notificação de memória baixa do sistema operacional, a pilha de chamadas é semelhante, exceto que o thread é o thread do finalizador. O thread do finalizador recebe uma notificação assíncrona de pouca memória e induz a coleta de lixo.
Se a coleta de lixo foi causada pela alocação de memória, a pilha aparece da seguinte maneira:
0012f230 7a07c551 mscorwks!WKS::GCHeap::GarbageCollectGeneration 0012f2b8 7a07cba8 mscorwks!WKS::gc_heap::try_allocate_more_space+0x1a1 0012f2d4 7a07cefb mscorwks!WKS::gc_heap::allocate_more_space+0x18 0012f2f4 7a02a51b mscorwks!WKS::GCHeap::Alloc+0x4b 0012f310 7a02ae4c mscorwks!Alloc+0x60 0012f364 7a030e46 mscorwks!FastAllocatePrimitiveArray+0xbd 0012f424 300027f4 mscorwks!JIT_NewArr1+0x148 000af70f 3000299f fragment_ni!request..ctor(Int32, Single)+0x20c 0000002a 79fa22bd fragment_ni!request.Main(System.String[])+0x153
Um ajudante just-in-time (
JIT_New*
) eventualmente chamaGCHeap::GarbageCollectGeneration
. Se você determinar que as coletas de lixo da geração 2 são causadas por alocações, deverá determinar quais objetos são coletados por uma coleta de lixo da geração 2 e como evitá-los. Ou seja, você deseja determinar a diferença entre o início e o fim de uma coleta de lixo de geração 2 e os objetos que causaram a coleta de geração 2.Por exemplo, digite o seguinte comando no depurador para mostrar o início de uma coleção de geração 2:
!dumpheap –stat
Exemplo de saída (abreviada para mostrar os objetos que usam mais espaço):
79124228 31857 9862328 System.Object[] 035f0384 25668 11601936 Toolkit.TlkPosition 00155f80 21248 12256296 Free 79103b6c 297003 13068132 System.Threading.ReaderWriterLock 7a747ad4 708732 14174640 System.Collections.Specialized.HybridDictionary 7a747c78 786498 15729960 System.Collections.Specialized.ListDictionary+DictionaryNode 7a747bac 700298 19608344 System.Collections.Specialized.ListDictionary 035f0ee4 89192 38887712 Toolkit.TlkOrder 00fcae40 6193 44911636 WaveBasedStrategy.Tick_Snap[] 7912c444 91616 71887080 System.Double[] 791242ec 32451 82462728 System.Collections.Hashtable+bucket[] 790fa3e0 2459154 112128436 System.String Total 6471774 objects
Repita o comando no final da 2ª geração:
!dumpheap –stat
Exemplo de saída (abreviada para mostrar os objetos que usam mais espaço):
79124228 26648 9314256 System.Object[] 035f0384 25668 11601936 Toolkit.TlkPosition 79103b6c 296770 13057880 System.Threading.ReaderWriterLock 7a747ad4 708730 14174600 System.Collections.Specialized.HybridDictionary 7a747c78 786497 15729940 System.Collections.Specialized.ListDictionary+DictionaryNode 7a747bac 700298 19608344 System.Collections.Specialized.ListDictionary 00155f80 13806 34007212 Free 035f0ee4 89187 38885532 Toolkit.TlkOrder 00fcae40 6193 44911636 WaveBasedStrategy.Tick_Snap[] 791242ec 32370 82359768 System.Collections.Hashtable+bucket[] 790fa3e0 2440020 111341808 System.String Total 6417525 objects
Os
double[]
objetos desapareceram do final da saída, o que significa que foram recolhidos. Esses objetos representam aproximadamente 70 MB. Os restantes objetos não mudaram muito. Portanto, essesdouble[]
objetos foram a razão pela qual essa coleta de lixo da geração 2 ocorreu. Seu próximo passo é determinar por que osdouble[]
objetos estão lá e por que eles morreram. Você pode perguntar ao desenvolvedor de código de onde esses objetos vieram ou pode usar ogcroot
comando.
Para determinar se o alto uso da CPU é causado pela coleta de lixo
Correlacione o valor do contador de desempenho de
% Time in GC
memória com o tempo de processo.Se o valor aumentar ao mesmo tempo que o tempo do processo, a
% Time in GC
coleta de lixo está causando um alto uso da CPU. Caso contrário, crie o perfil do aplicativo para encontrar onde o alto uso está ocorrendo.
Consulte também
Comentários
https://aka.ms/ContentUserFeedback.
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja:Submeter e ver comentários