Solucionar problemas de desempenho do Cache e do Gerenciador de Memória

Antes Windows Server 2012, dois problemas potenciais principais causaram o aumento do cache de arquivos do sistema até que a memória disponível fosse quase esgotada em determinadas cargas de trabalho. Quando essa situação faz com que o sistema seja lento, você pode determinar se o servidor está enfrentando um desses problemas.

Contadores a monitorar

  • Memória\Tempo de vida médio do cache em espera de longo prazo (s) < 1800 segundos

  • Memory\Available Mbytes is low

  • Memory\System Cache Resident Bytes

Se Memory\Available Mbytes for baixo e, ao mesmo tempo, Memory\System Cache Resident Bytes estiver consumindo parte significativa da memória física, você poderá usar RAMMAP para descobrir para que o cache está sendo usado.

O cache de arquivos do sistema contém estruturas de dados de metadados NTFS

Esse problema é indicado por um grande número de páginas de Metadados ativas na saída rammap, conforme mostrado na figura a seguir. Esse problema pode ter sido observado em servidores ocupados com milhões de arquivos que estão sendo acessados, resultando em armazenar em cache os dados de metarquivo NTFS que não estão sendo liberados do cache.

rammap view

O problema costumava ser atenuado pela ferramenta DynCache. No Windows Server 2012+, a arquitetura foi reprojetada e esse problema não deve mais existir.

O cache de arquivos do sistema contém arquivos mapeados em memória

Esse problema é indicado por um grande número de páginas de arquivo mapeadas ativas na saída rammap. Isso geralmente indica que algum aplicativo no servidor está abrindo vários arquivos grandes usando a API CreateFile com FILE_FLAG_RANDOM_ACCESS sinalizador definido.

Esse problema é descrito em detalhes no artigo de KB 2549369. FILE_FLAG_RANDOM_ACCESS sinalizador é uma dica para o Gerenciador de Cache manter exibições mapeadas do arquivo na memória o máximo possível (até que o Gerenciador de Memória não sinalize a condição de memória baixa). Ao mesmo tempo, esse sinalizador instrui o Gerenciador de Cache a desabilitar a pré-busca de dados de arquivo.

Essa situação foi atenuada até certo ponto por meio de melhorias de corte de conjunto de trabalho no Windows Server 2012+, mas o problema em si precisa ser resolvido principalmente pelo fornecedor do aplicativo, não usando FILE_FLAG_RANDOM_ACCESS. Uma solução alternativa para o fornecedor do aplicativo pode ser usar a baixa prioridade de memória ao acessar os arquivos. Isso pode ser feito usando a API SetThreadInformation. As páginas acessadas com baixa prioridade de memória são removidas do conjunto de trabalho de forma mais agressiva.

O Gerenciador de Cache, a partir do Windows Server 2016 atenua ainda mais isso ignorando o FILE_FLAG_RANDOM_ACCESS ao tomar decisões de corte, portanto, ele é tratado como qualquer outro arquivo aberto sem o sinalizador FILE_FLAG_RANDOM_ACCESS (o Gerenciador de Cache ainda segue esse sinalizador para desabilitar a pré-busca de dados de arquivo). Você ainda poderá causar o aumento do cache do sistema se tiver um grande número de arquivos abertos com esse sinalizador e acessados de maneira realmente aleatória. É altamente recomendável que FILE_FLAG_RANDOM_ACCESS sejam usados por aplicativos.

O limite de página suja do arquivo remoto é excedido consistentemente

Esse problema é indicado se um sistema passa por lentidão ocasional durante gravações de um cliente remoto. Esse problema pode ocorrer quando uma grande quantidade de dados é escrita de um cliente remoto rápido para um destino de servidor lento.

Antes Windows Server 2016, nesse cenário, se o limite de página sujo no cache for atingido, outras gravações se comportarão como se houvesse write-through. Isso pode causar uma liberação de uma grande quantidade de dados para o disco, o que pode levar a longos atrasos se o armazenamento estiver lento, resultando em tempos máximos para a conexão remota.

No Window Server 2016 e no futuro, uma mitigação é colocada em uso para reduzir a probabilidade de tempos-tempoouts. Um limite de página suja separado para gravações remotas é implementado e uma liberação em linha será executada quando ela for excedida. Isso pode resultar em lentidão ocasional durante uma atividade de gravação intensa, mas elimina o risco de um tempo-tempo máximo na maioria dos casos. Esse limite de página suja remota é de 5 GB por arquivo por padrão. Para algumas configurações e cargas de trabalho, um número diferente terá um desempenho melhor.

Esse limite pode ser controlado com a seguinte regkey: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\RemoteFileDirtyPageThreshold. Se o tamanho padrão de 5 GB não funcionar bem para sua configuração, é recomendável tentar aumentar o limite em incrementos de 256 MB até que o desempenho seja satisfatório. Observe o seguinte:

  • Uma reinicialização é necessária para que as alterações nessa regkey entre em vigor.

  • As unidades de RemoteFileDirtyPageThreshold são o número de páginas (com o tamanho da página como gerenciado pelo Gerenciador de Cache). Isso significa que ele deve ser definido com o tamanho desejado em bytes, dividido por 4096.

  • Os valores recomendados são 128 MB < = N < = 50% da memória disponível.

  • Esse limite pode ser desabilitado completamente definindo-o como -1. Isso não é recomendado, pois pode resultar em tempos máximos para conexões remotas.