Solucionar problemas de desempenho do cache e do gerenciador de memória

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

Contadores a monitorizar

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

• Memória\Disponível (em bytes, KBytes ou MBytes)

• Memória\Bytes residentes no cache do sistema

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

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

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

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

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

Esse problema é indicado por um alto número de páginas de arquivo mapeado 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 o sinalizador definido.

FILE_FLAG_RANDOM_ACCESS flag é uma dica para o Gerenciador de Cache manter as exibições mapeadas do arquivo na memória o maior tempo possível (até que o Gerenciador de Memória não sinalize a condição de pouca memória). 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 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_ACCESSo . Uma solução alternativa para o fornecedor do aplicativo pode ser usar baixa prioridade de memória ao acessar os arquivos. Isso pode ser feito usando a API SetThreadInformation . As páginas que são 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 FILE_FLAG_RANDOM_ACCESS ao tomar decisões de corte, por isso é tratado como qualquer outro arquivo aberto sem o sinalizador (o FILE_FLAG_RANDOM_ACCESS Gerenciador de Cache ainda honra esse sinalizador para desabilitar a pré-busca de dados de arquivos). Você ainda pode causar inchaço do cache do sistema se tiver um grande número de arquivos abertos com esse sinalizador e acessados de forma verdadeiramente aleatória. É altamente recomendável que FILE_FLAG_RANDOM_ACCESS não seja usado por aplicativos.

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

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

Antes do Windows Server 2016, nesse cenário, se o limite de página suja no cache for atingido, outras gravações se comportarão como se houvesse gravação. 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 limite para a conexão remota.

No Windows Server 2016 e posterior, uma atenuação é implementada para reduzir a probabilidade de tempos limites. Um limite de página suja separado para gravações remotas é implementado, e uma descarga em linha será executada quando for excedida. Isso pode resultar em lentidão ocasional durante a atividade de gravação pesada, mas elimina o risco de um tempo limite 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 tem melhor desempenho.

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. Tenha em atenção o seguinte:

• É necessária uma reinicialização para que as alterações nessa chave do Registro entrem em vigor.

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

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

• Esse limite pode ser desativado completamente definindo-o 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 do 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).