Solução de problemas de desempenho do Gerenciador de Cache e de Memória
Antes do Windows Server 2012, dois problemas potenciais principais faziam com que o cache de arquivos do sistema aumentasse até que a memória disponível fosse quase esgotada em algumas cargas de trabalho. Quando essa situação resulta em lentidão no sistema, você pode determinar se o servidor está enfrentando um desses problemas.
Contadores a serem monitorados
Memória\Tempo de Vida Médio do Cache em Espera de Longo Prazo (s) < 1.800 segundos
Memória\Disponível (em Bytes, KBytes ou MBytes)
Memória\Bytes Residentes do Cache do Sistema
Se o contador Memória\Mbytes Disponíveis for baixo e, ao mesmo tempo, Memória\Bytes Residentes do Cache do Sistema estiver consumindo uma parte significativa da memória física, use o RAMMAP para descobrir para que o cache está sendo usado.
O cache de arquivos do sistema contém estruturas de dados de metarquivo NTFS
Esse problema é indicado por um alto número de páginas de metarquivos ativas na saída do RAMMAP, conforme mostrado na figura a seguir. Esse problema pode ter sido observado em servidores ocupados com milhões de arquivos sendo acessados, resultando no cache de dados de metarquivo NTFS não sendo liberado do cache.
O problema costumava ser mitigado pela ferramenta DynCache. No Windows Server 2012 e posterior, 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 alto número de páginas de arquivos mapeadas ativas na saída do RAMMAP. Em geral, isso indica que alguns aplicativos no servidor estão abrindo vários arquivos grandes usando a API CreateFile com o sinalizador FILE_FLAG_RANDOM_ACCESS definido.
O sinalizador FILE_FLAG_RANDOM_ACCESS é uma dica para o Gerenciador de Cache manter as exibições mapeadas do arquivo em memória o máximo possível (enquanto 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 aprimoramentos de corte do conjunto de trabalho no Windows Server 2012 e posterior, mas o problema em si precisa ser resolvido principalmente pelo fornecedor do aplicativo por não usar FILE_FLAG_RANDOM_ACCESS. Uma solução alternativa para o fornecedor do aplicativo pode ser usar a prioridade de memória baixa ao acessar os arquivos. Isso pode ser feito por meio da API SetThreadInformation. As páginas acessadas com prioridade de memória baixa são removidas do conjunto de trabalho de maneira mais agressiva.
O Gerenciador de Cache, a partir do Windows Server 2016, atenua isso ainda mais ignorando 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 respeita esse sinalizador para desabilitar a busca prévia de dados do arquivo). Você ainda poderá causar a sobrecarga 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 não seja usado pelos aplicativos.
O limite de páginas sujas de arquivos remotos é excedido consistentemente
Esse problema é indicado se um sistema apresenta lentidão ocasional durante as gravações de um cliente remoto. Isso pode ocorrer quando um grande volume de dados é gravado de um cliente remoto rápido em um destino de servidor lento.
Antes do Windows Server 2016, nesse cenário, se o limite de páginas sujas no cache for atingido, as gravações posteriores se comportarão como se houvesse um write-through. Isso pode causar uma liberação de um grande volume de dados para o disco, o que pode resultar em longos atrasos caso o armazenamento esteja lento, resultando em tempos limite da conexão remota.
No Windows Server 2016 e no posterior, uma mitigação é implementada para reduzir a probabilidade de tempos limite. Um limite de páginas sujas separado para gravações remotas é implementado, e uma liberação embutida será executada quando ele for excedido. Isso pode resultar em lentidão ocasional durante a atividade de gravação intensa, mas elimina o risco de um tempo limite na maioria dos casos. Por padrão, esse limite de páginas sujas remotas é de 5 GB por arquivo. Para algumas configurações e cargas de trabalho, um número diferente terá um desempenho melhor.
Se o tamanho padrão de 5 GB não funcionar bem para sua configuração, é recomendado tentar aumentar o limite em incrementos de 256 MB até que o desempenho seja satisfatório. Esteja ciente do seguinte:
Uma reinicialização é necessária para que esta chave do registro entre em vigor.
As unidades de RemoteFileDirtyPageThreshold são o número de páginas (com o tamanho da página gerenciado pelo Gerenciador de Cache). Isso significa que ele deve ser definido como o tamanho desejado em bytes, dividido por 4.096.
Os valores recomendados são 128 MB <= N <= 50% da memória disponível.
Esse limite pode ser desabilitado por completo pela definição dele como -1. Isso não é recomendado, pois pode resultar em tempos limite para conexões remotas.
Por exemplo, se você quiser definir o limite para 10GiB, isso é 10.737.418.240 bytes / 4096 = 2.621.440, que é um valor DWORD decimal de 2621440.
Esse limite pode ser controlado usando o seguinte valor de registro.
- Chave:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management- Tipo:
DWORD - Nome do valor:
RemoteFileDirtyPageThreshold - Dados do valor: Decimal - Número de páginas (tamanho da página conforme gerenciado pelo Gerenciador de Cache).
- Tipo: