Diagnóstico de erros de cache e prevenção de perda de dados no Windows

Quando o Windows começa a apresentar lentidão, demora uma eternidade para abrir aplicativos ou fica sem memória aparentemente "do nada"Frequentemente, a raiz do problema reside na forma como o sistema gerencia seu cache (tanto de arquivos quanto de memória) e como determinados aplicativos utilizam essa memória. Compreender o que acontece nos bastidores é fundamental para evitar travamentos, quedas de desempenho e até mesmo o risco de perda de dados em determinadas cargas de trabalho.

A boa notícia é que o Windows inclui contadores de desempenho, ferramentas de diagnóstico e configurações específicas. Essas ferramentas permitem detectar comportamentos anômalos do cache, identificar vazamentos de memória e ajustar parâmetros críticos, como o limite de indisponibilidade de página para gravações remotas. Com um pouco de metodologia e os utilitários certos, é possível identificar qual componente está consumindo mais memória e tomar medidas preventivas.

O que é o cache no Windows e por que ele pode causar problemas?

O cache, ambos em Hardwares Assim como em software, é basicamente uma área de armazenamento rápido onde os dados são mantidos para agilizar o acesso posterior.Em processadores e memória, falamos de caches L1, L2 ou L3; em OS Assim como no Windows, o cache de arquivos do sistema armazena dados em disco que provavelmente serão lidos novamente, reduzindo os tempos de acesso lentos. armazenamento fisica.

No caso específico do Windows, o cache de arquivos do sistema é gerenciado pelo gerenciador de cache.O cache decide quais páginas manter na memória, quais descartar e quando liberar espaço. Sob certas cargas de trabalho (milhões de arquivos, acesso altamente aleatório, servidores com clientes remotos muito rápidos, etc.), esse cache pode crescer demais e deixar o sistema praticamente sem memória disponível.

Quando o cache ocupa uma grande parte da RAM física e não é liberado a tempo.O resultado é uma equipe lenta, com processos que demoram a responder e, em casos extremos, com erros decorrentes da falta de memória virtualIsso não afeta apenas o desempenho: se o armazenamento for lento e houver muitas gravações pendentes no cache, podem ocorrer tempos limite em conexões remotas ou grandes atrasos na gravação de dados em disco.

Em outros cenários, o problema não é o cache de arquivos do sistema, mas sim vazamentos de memória em processos específicos.Esses vazamentos se manifestam como um consumo crescente e contínuo de memória virtual (tamanho alocado), sem que o processo a libere, o que acaba esgotando os recursos do sistema e acionando eventos de alerta, como o identificador 2004 do detector de esgotamento de recursos.

No âmbito da web, existe também o conceito de falha de cache.Isso ocorre quando um aplicativo (por exemplo, um site WordPress com plugins de cache) solicita dados que não estão no cache e precisa recuperá-los do banco de dados ou da fonte. Esses erros aumentam a latência, tornam as páginas mais lentas e, se frequentes, anulam muitos dos benefícios do cache.

Contadores de teclas para monitoramento do cache de arquivos no Windows

Antes do Windows Server 2012, havia dois problemas típicos que faziam com que o cache de arquivos crescesse descontroladamente. até que a memória disponível esteja praticamente esgotada. Embora a arquitetura tenha sido aprimorada em versões recentes, ainda é útil saber quais contadores monitorar para detectar situações semelhantes.

Os indicadores de desempenho mais importantes para monitorar esses cenários são::

• Tempo de vida médio de longo prazo do cache em espera (s)Tempo médio de vida útil da memória em modo de espera. Se esse valor permanecer abaixo de 1800 segundos (30 minutos), indica que as páginas em modo de espera estão sendo recicladas muito rapidamente porque o sistema está com pouca memória.
• Memória disponível (bytes / KBytes / MBytes)Isso reflete a memória disponível no sistema. Valores persistentemente baixos, combinados com alto uso do cache do sistema, geralmente são um sinal de alerta.
• Bytes residentes na memória/cache do sistemaIsso indica quanta memória física está sendo usada pelo cache de arquivos do sistema. Quando esse valor representa uma fração muito grande da RAM total e a memória disponível é baixa, o cache pode estar superdimensionado.

Se você notar que a memória disponível (Memory\Available) está baixa e, ao mesmo tempo, a memória cache do sistema (Memory\System Cache Resident Bytes) ocupa uma parte considerável da RAM, observe que ela está ocupada.O próximo passo é descobrir exatamente para que esse cache está sendo usado. Para isso, o RAMMap é uma ferramenta essencial.

Use o RAMMap para identificar o que está preenchendo o cache de arquivos.

RAMMap é um utilitário do Sysinternals que mostra graficamente e em detalhes como a memória física está sendo usada.Entre outras coisas, permite visualizar quantas páginas estão atribuídas a metadados. NTFS, para arquivos mapeados, para cache do sistema, etc.

Um dos problemas históricos em servidores com alta carga era o acúmulo massivo de páginas de metadados NTFS no cache.Isso ocorreu especialmente em sistemas com milhões de arquivos e acesso intensivo: o armazenamento de metadados (informações sobre a estrutura do sistema de arquivos, não o conteúdo em si) não foi liberado corretamente do cache, causando um aumento exponencial do consumo.

Na saída do RAMMap, esse cenário é detectado por um número muito alto de páginas de metadados ativas.Visualmente, fica claro que essa categoria consome uma porcentagem desproporcional de memória. Historicamente, isso era atenuado com ferramentas como o DynCache, que ajustava os limites do cache do sistema para conter o problema.

A partir do Windows Server 2012, a arquitetura interna do gerenciamento de cache foi redesenhada. Exatamente para evitar que esse tipo de crescimento descontrolado de metadados ocorra, de modo que não deveria aparecer em sistemas modernos... embora ainda seja útil conhecer o sintoma para diagnosticar comportamentos semelhantes.

Outro cenário que o RAMMap ajuda a desvendar é quando o cache de arquivos do sistema contém um grande volume de arquivos mapeados em memória.A ferramenta mostra um grande número de páginas de arquivos mapeadas ativas, frequentemente associadas a aplicativos que abrem vários arquivos grandes.

Impacto do FILE_FLAG_RANDOM_ACCESS e melhores práticas de aplicação

Um padrão típico de estouro do cache de arquivos ocorre quando um aplicativo abre muitos arquivos grandes usando CreateFile com o sinalizador FILE_FLAG_RANDOM_ACCESS.Essa flag é basicamente uma dica para o gerenciador de cache: ela indica que as visualizações mapeadas devem ser mantidas na memória pelo maior tempo possível, pois espera-se um acesso muito aleatório aos dados.

Ao marcar FILE_FLAG_RANDOM_ACCESS, o gerenciador de cache tenta manter os dados na memória até que o gerenciador de memória declare uma condição de pouca memória disponível.Além disso, essa mesma opção desativa a pré-busca de dados do arquivo, já que, em teoria, os acessos não seguirão um padrão sequencial.

Esse comportamento, combinado com a abertura frequente de arquivos grandes e acessos verdadeiramente aleatóriosIsso pode causar um crescimento excessivo do cache do sistema. Embora o Windows Server 2012 e versões posteriores introduzam melhorias no ajuste do espaço de trabalho, o fornecedor do aplicativo é o responsável final pela correção desse problema.

A recomendação enfática para desenvolvedores é evitar o uso de FILE_FLAG_RANDOM_ACCESS, a menos que seja estritamente necessário.Alternativamente, eles podem acessar arquivos com baixa prioridade de memória, de modo que as páginas usadas possam ser removidas do espaço de trabalho de forma mais agressiva quando a memória for necessária para outros processos.

Essa baixa prioridade de memória pode ser configurada usando a API SetThreadInformation.Com isso, os threads que realizam acessos ao disco podem ser marcados como tendo baixa prioridade de memória, reduzindo o impacto de sua atividade no conjunto de trabalho geral do sistema.

No Windows Server 2016, o gerenciador de cache vai um passo além e, ao realizar o truncamento, ignora a sugestão de FILE_FLAG_RANDOM_ACCESS.Tratar esses arquivos da mesma forma que quaisquer outros em termos de redução de cache (embora ainda desative o pré-carregamento, como indica o parâmetro) atenua parcialmente o problema, mas não elimina o risco de um tamanho de cache desproporcional se o aplicativo continuar abrindo muitos arquivos com esse parâmetro e realizar acessos muito dispersos.

Limite de páginas desatualizado em arquivos remotos e risco de timeouts.

Outro problema específico que pode afetar tanto o desempenho quanto a estabilidade das conexões remotas. Isso ocorre quando um sistema recebe gravações muito rápidas de um cliente remoto para um armazenamento de destino relativamente lento.

Em versões anteriores ao Windows Server 2016, quando o limite de páginas obsoletas (sujas) em cache para um arquivo remoto era atingido.As gravações adicionais eram tratadas como se fossem simultâneas. Isso resultava em uma enorme quantidade de dados gravados no disco e, caso a capacidade de armazenamento fosse insuficiente, ocorriam latência significativa e até mesmo timeouts de conexão de rede.

Para solucionar esse problema, o Windows Server 2016 introduz um limite de páginas obsoletas separado para gravações remotas.Quando esse limite é ultrapassado, o sistema realiza uma limpeza online do disco, ou seja, grava os dados gradualmente para evitar picos enormes que saturariam o subsistema de armazenamento.

Esse mecanismo pode causar alguma lentidão ocasional durante períodos de escrita muito intensa.Em contrapartida, isso reduz significativamente a probabilidade de um cliente remoto sofrer um timeout devido ao excesso de dados aguardando para serem gravados.

O valor padrão para esse limite remoto é de 5 GB por arquivo.Dependendo da configuração do hardware e da carga de trabalho, pode ser aconselhável ajustá-lo: em alguns ambientes, um limite mais alto produz melhores resultados, em outros é preferível manter o valor padrão.

Como ajustar o RemoteFileDirtyPageThreshold no Registro

Se o limite de 5 GB não atender às suas necessidades, você pode modificar o limite de páginas remotas desatualizadas usando o Registro do Windows.Essa configuração é controlada pelo valor RemoteFileDirtyPageThreshold.

• Caminho principal: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
• Tipo: DWORD
• Nome do valor: RemoteFileDirtyPageThreshold
• Dados: número de páginas, onde cada página é equivalente ao tamanho da página gerenciada pelo gerenciador de cache (normalmente 4096 bytes).

Para calcular o valor correto, você deve converter o número desejado de bytes em um número de páginas.Por exemplo, se você quiser definir o limite para 10 GiB, primeiro calcule 10.737.418.240 bytes / 4096 = 2.621.440 páginas; esse é o valor decimal que você deve inserir no DWORD.

Recomendações gerais indicam trabalhar dentro de uma faixa segura entre 128 MB e até 50% da memória disponível.sempre traduzido em páginas. Idealmente, o limite deve ser aumentado em incrementos de 256 MB, medindo o desempenho após cada alteração, até que o ponto de equilíbrio seja encontrado.

Observe que qualquer modificação no valor de RemoteFileDirtyPageThreshold requer a reinicialização do computador. para que o novo valor entre em vigor. Sem a reinicialização, o sistema continuará a usar o limite anteriormente ativo.

Também é possível desativar completamente esse limite definindo o valor para -1.No entanto, não é recomendável: fazê-lo novamente aumenta o risco de grandes rajadas de gravações remotas preencherem o cache com páginas desatualizadas e causarem tempos de espera e problemas de conexão para os clientes.

Detecção de esgotamento de memória e eventos de 2004 no Windows

Além dos mecanismos de cache, o Windows possui um detector de esgotamento de recursos que monitora o uso da memória virtual.Quando se atinge um nível baixo de memória virtual, o evento 2004 é registrado no log do sistema, com informações detalhadas sobre os processos que estão consumindo mais memória.

Um exemplo típico de um evento de 2004 (Microsoft-Windows-Resource-Exhaustion-Detector) Inclui uma mensagem indicando que o Windows diagnosticou com sucesso uma condição de pouca memória virtual e lista os programas que consumiram mais memória naquele momento, com o nome do executável, o PID e o número de bytes alocados.

É importante entender que a coluna de memória que é exibida por padrão em muitas visualizações do Administrador de tarefas Não é o dado mais relevante para este tipo de diagnóstico. Normalmente, reflete a memória privada suportada pela RAM (o conjunto de trabalho), mas o que interessa aqui é o uso total de memória virtual que o sistema alocou para cada processo.

A métrica a ser observada nesses casos é o tamanho do commit.Isso representa a memória virtual que o Windows reserva para o processo, independentemente de ser respaldada por RAM física ou por um arquivo de paginação. Quando o comprometimento total do sistema se aproxima do limite, eventos 2004 são acionados.

Esse comportamento pode ocorrer tanto com processos da Microsoft quanto com aplicativos de terceiros.Para processos específicos da plataforma, geralmente existe símbolos públicos que permitem uma análise mais aprofundada; no caso de software de terceiros, muitas vezes é necessário contatar o fornecedor para obter informações adicionais se as pilhas de chamadas não mostrarem funções com nomes claros.

Utilizando o VMMap para classificar o tipo de memória que está vazando.

Quando há suspeita de vazamento de memória, o primeiro passo é determinar que tipo de memória está crescendo descontroladamente.Para isso, o VMMap é uma ferramenta muito útil, pois divide o uso de memória de um processo em categorias: dados privados, heaps, imagens, pilhas, etc.

Se o vazamento ocorrer na memória de alocação virtual genérica, no VMMap ele aparecerá como um aumento contínuo na categoria de dados privados.Essa memória não está diretamente associada a um heap gerenciado, mas sim a reservas e compromissos de espaço de endereço que o processo não libera.

Quando um despejo de memória do processo estiver disponível, o WinDbg pode ser usado para executar o comando !address -summaryEm resumo, a alocação problemática de memória virtual geralmente aparece na categoria , indicando grandes regiões de memória não classificadas que ocupam uma parte muito significativa do espaço ocupado.

Se o vazamento estiver relacionado ao heap do processo, ele será refletido nas categorias de Heap no VMMap.O uso da memória heap aumentará gradualmente ao longo do tempo. o tempo, sem retornos apreciáveis.

Novamente, com um dump e o comando !address -summary no WinDbg, nesses casos uma porcentagem muito alta será rotulada como Heap32 ou Heap64.Dependendo da arquitetura do processo, as categorias restantes (imagens, pilhas, outras) representarão uma fração muito menor do uso total.

Identificar corretamente se estamos lidando com alocação virtual ou vazamentos de memória é crucial.Porque determina que tipo de monitoramento devemos ativar em seguida e quais ferramentas específicas nos ajudarão a encontrar o responsável.

Colete rastreamentos com WPR para memória de alocação virtual.

Uma vez constatado que existe um vazamento de alocação virtual, o próximo passo é coletar dados reproduzíveis que revelem quem está fazendo essas reservas.Para isso, você pode usar o Gravador de Desempenho do Windows (WPR), que está incluído nativamente no Windows 10 e no Windows Server 2016.

O procedimento básico consiste em iniciar uma sessão de plotagem focada na alocação virtual e deixar o processo ocorrer naturalmente. enquanto o uso de memória aumenta, e interrompa a captura quando informações suficientes sobre as alocações forem acumuladas.

C:\>wpr -start VirtualAllocation

Com o rastreamento em execução, o crescimento do consumo de memória é monitorado pelo tamanho de confirmação do processo.Isso pode ser feito usando o Gerenciador de Tarefas, o Monitor de Recursos ou ferramentas similares. A vantagem desse perfil WPR é que, ao focar exclusivamente na alocação virtual, o arquivo .etl resultante normalmente não cresce muito, permitindo que ele permaneça ativo por vários minutos.

C:\>wpr -stop virtalloc.etl

O arquivo virtualloc.etl conterá os eventos de alocação virtual que serão analisados ​​com o Analisador de Desempenho do Windows (WPA)., permitindo que você veja quais funções e módulos estão por trás das reservas de memória que não foram liberadas.

Colete rastreamentos com WPR para memória heap.

No caso de vazamentos associados ao heap do processo, o próximo passo é coletar rastreamentos específicos do heap.Para isso, o WPR pode ser configurado para registrar eventos de heap do executável de destino, geralmente por meio de uma entrada no Registro que permite o rastreamento.

Você pode modificar o Registro manualmente ou usar o WPR para configurar o binário de destino.Por exemplo, para habilitar o rastreamento de memória (heap tracing) para o VirtMemTest32.exe, execute-o a partir de um prompt de comando com privilégios de administrador:

C:\>wpr -heaptracingconfig VirtMemTest32.exe enable

Este comando cria uma chave de configuração em HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\VirtMemTest32.exe, com um valor DWORD chamado Tracing Flags normalmente definido como 1, habilitando assim o rastreamento de heap para esse executável.

Após a fase de diagnóstico, é importante desativar o rastreamento novamente.Para evitar sobrecarga desnecessária em tempo de execução, remova a chave ou defina o valor dos sinalizadores de rastreamento como 0.

Com a configuração aplicada, a captura de rastreamento de heap é realizada com:

C:\>wpr -start Heap

Assim como na alocação virtual, o processo pode ser executado por alguns minutos enquanto o tamanho de confirmação é observado.Como apenas os eventos de heap são registrados, o tamanho do rastreamento é gerenciável na maioria dos cenários.

C:\>wpr -stop Heap.etl

O resultado é um arquivo Heap.etl contendo os eventos de alocação e liberação de memória heap.que serão então estudadas com o WPA para localizar as pilhas de chamadas responsáveis ​​pelos vazamentos.

Análise de rastreamento com o Analisador de Desempenho do Windows (WPA)

A etapa final do processo de diagnóstico é abrir os rastreamentos .etl com o Analisador de Desempenho do Windows., uma ferramenta incluída no Windows Performance Toolkit, que por sua vez faz parte do ADK (Assessment and Deployment Kit).

Antes de começar a examinar os dados, é essencial configurar corretamente os caminhos dos símbolos.para que as pilhas de chamadas sejam resolvidas com nomes de funções legíveis para humanos. No WPA, isso é feito no menu Rastrear > Configurar Caminhos de Símbolos, adicionando um caminho semelhante a:

srv*C:\LocalPubSymbols*https://msdl.microsoft.com/download/symbols

Com os símbolos configurados, eles são carregados através do menu de símbolos e o arquivo .etl correspondente é aberto.No caso de vazamentos de alocação virtual, deve-se reproduzir uma visualização centrada no processo problemático, garantindo que a coluna "Commit Stack" esteja à esquerda da linha de grade dourada ou amarela.

Expandir as pilhas de commits identifica as funções que originam as atribuições virtuais. que não são liberadas. O módulo que aparece imediatamente acima da função de alocação na pilha é geralmente o módulo lógico que está solicitando memória repetidamente.

Para vazamentos de memória (heap leaks), a abordagem é semelhante, mas a visualização deve incluir colunas como Handle e Stack. À esquerda da linha divisória. Explorar essas pilhas revela as funções que fazem chamadas de reserva no heap sem a liberação correspondente.

Em ambos os casos, uma vez identificados o módulo e a função envolvidos.O próximo passo geralmente é verificar se há atualizações de software, patches conhecidos ou, se for um aplicativo personalizado, depurar e corrigir o padrão de alocação para eliminar o vazamento.

Falhas no cache de aplicações web e como reduzi-las

Além do sistema operacional, o conceito de falhas de cache é altamente relevante em aplicações web como o WordPress.Uma falha de cache ocorre quando os dados solicitados pelo sistema ou aplicativo não estão disponíveis no cache e precisam ser recuperados do banco de dados ou da fonte de dados.

Em contrapartida, um acerto de cache ocorre quando o conteúdo é recuperado diretamente do cache.Seja na memória, no disco ou no nível do servidor, quanto mais acertos no cache, mais rápidas as respostas; quanto mais erros, maior a latência e maior a carga que o servidor e o banco de dados suportarão.

As causas típicas de uma falha de cache incluem o fato de os dados nunca terem sido armazenados inicialmente., que foram removidos devido à falta de espaço, que o cache foi limpo manual ou automaticamente, ou que a política de tempo de vida (TTL) associada a esses dados expirou.

Quando ocorre uma falha de cache, o sistema geralmente faz uma segunda tentativa, desta vez contra a fonte de dados.Se o recurso solicitado existir, ele será lido do banco de dados ou do armazenamento principal, retornado ao cliente e, na maioria dos casos, armazenado em cache novamente para acelerar solicitações futuras.

O problema é que, cada vez que você precisa descer na hierarquia (do cache L1 para o L2, do L2 para a memória principal, da memória para o disco, etc.), uma penalidade de falha de cache é introduzida.Em locais movimentados, o excesso dessas falhas reduz significativamente os tempos de resposta.

Estratégias práticas para reduzir falhas de cache em ambientes web

Para reduzir a frequência de falhas de cache em um site, o objetivo é manter os dados relevantes no cache pelo maior tempo possível.sempre buscando o equilíbrio entre desempenho e novidade do conteúdo.

Uma tática básica é estabelecer um tempo de vida (TTL) apropriado para o cache.Cada vez que um dado é apagado, ele precisa ser recalculado e reescrito após a próxima requisição, o que pode levar a falhas iniciais. Aumentar o TTL quando o conteúdo não muda com frequência ajuda a reduzir as invalidações e, consequentemente, as falhas.

Em provedores de serviços gerenciados, é prática comum limpar apenas seções específicas do cache quando alterações relevantes são detectadas.Por exemplo, plugins como os usados ​​por alguns provedores de hospedagem especializados limpam apenas o cache da entrada modificada ou de determinadas áreas do site, em vez de apagar todo o cache do servidor.

Outra forma de reduzir as falhas de cache é aumentar o tamanho do próprio cache ou a quantidade de RAM disponível.Quanto maior a capacidade, mais objetos podem ser armazenados simultaneamente sem remover os menos utilizados, reduzindo o número de remoções forçadas.

Isso tem um custo, já que aumentar a memória RAM ou assinar planos de hospedagem escaláveis ​​envolve uma despesa adicional.No entanto, em projetos com alto tráfego, pode ser uma das otimizações mais econômicas em termos de desempenho e estabilidade.

Por fim, é muito útil escolher políticas de substituição de cache que correspondam ao padrão de acesso da aplicação.Entre os mais comuns estão FIFO (First In First Out), LIFO (Last In First Out), LRU (Least Recently Used) e MRU (Most Recently Used), cada um com vantagens e desvantagens dependendo do tipo de carga.

Aplicar uma combinação inteligente dessas políticas permite controlar quais objetos do cache são removidos primeiro. Quando for necessário liberar espaço, mantenha na memória os dados mais valiosos ou mais frequentemente utilizados, mesmo quando não for viável continuar aumentando o tamanho do cache.

Na prática, coordene a configuração de cache do site com o provedor de hospedagem. Essa geralmente é a melhor maneira de ajustar o TTL, as políticas e a capacidade, especialmente em ambientes gerenciados onde muitas decisões de cache são tomadas no nível do servidor.

Compreender como o Windows gerencia o cache e a memória, como diagnosticar vazamentos e limites problemáticos e como otimizar o uso do cache em aplicativos como o WordPress. Isso permite evitar gargalos, reduzir a latência e minimizar o risco de perda de dados ou timeouts, tanto em servidores locais quanto em ambientes web exigentes.