Udostępnij za pośrednictwem

Os 7 Grandes Mitos do Perfmon (Parte 2)

  • Artykuł

No primeiro post da série Os 7 Grandes Mitos do Perfmon, comentei sobre os contadores:

  • Buffer Manager:Buffer Cache Hit Ratio
  • LogicalDisk: Average Disk Queue Length e LogicalDisk: %Disk Busy

Agora vamos continuar falando sobre outros contadores

3. Paging File:%Usage

Existe uma discussão sobre qual o tamanho ideal do arquivo de Paging File. Algumas pessoas dizem que o correto é ajustar o Paging File para 1,5 vezes o tamanho da memória da máquina. Entretanto, com as máquinas atuais chegando facilmente a 128GB de RAM, então o arquivo ficaria com quase 200GB de espaço em disco.

A frase de ajustar em 1,5x em relação a memória RAM é um tanto antiquada e deveria se aplicar ao Windows NT e Windows 2000. A realidade mudou bastante com a chegada dos servidores de 64-bits. Hoje podemos dizer que o Paging File deve ser igual ao tamanho ocupado pela Kernel, que seria o tamanho mínimo necessário para gerar um crash dump.

How to determine the appropriate page file size for 64-bit versions of Windows
https://support.microsoft.com/en-us/kb/2860880

Se o tamanho do Paging File não depende do SQL Server, mas da Kernel, então por que monitorar?

Sim, você pode monitorar (temporariamente) esse contador para determinar o valor ideal do paging file – que seria algo entre 2GB a 20GB dependendo da quantidade de memória da máquina. Mas certamente, esse contador de Paging File não vai ajudar em nada no tuning do SQL Server.

Por fim, se o SQL Server estiver usando Paging File, algo está muito errado. O objetivo do banco de dados é usar a memória para fazer o cache dos dados em disco. Usar o paging file (disco) para fazer cache de dados (disco) não faz o menor sentido.

4. Memory: Page Faults/sec e Memory: Pages/sec

Muitos administradores de sistema usam esses contadores para determinar quando há esgotamento de memória do servidor. A memória RAM é distribuída entre os processos do Windows e, quando ficam ociosos, podem ser paginados para o Paging File.

Em um servidor SQL, o comportamento é ligeiramente diferente: quando há falta de memória, o SQL Server inicia o processo de liberação de memória para evitar que os processos sejam paginados para disco. Portanto, a ideia é que o SQL utilize toda a memória disponível na máquina para montar o cache do banco de dados. Se o Sistema Operacional (SO) precisar de memória, então o SQL Server é sinalizado e parte desse cache é desfeito, retornando a memória livre ao SO. Assim, não é necessário verificar se existe paginação de dados com os contadores de Page Faults/sec e Page/sec.

Entretanto, existem motivos mais fortes para evitar esses contadores:

  • Page Faults/sec – Conhecido também como “soft page faults”, essas paginações ocorrem somente para reposicionar a memória sem a necessidade de ir ao disco. Esse é um processo comum presente em qualquer Sistema Operacional multitasking. A ocorrência de “soft page faults” está mais relacionada a transição de contexto entre processos do que falta de memória.

Portanto, altos valores de Page Faults/sec não correspondem a problemas.

  • Pages/sec – Conhecido como “hard page faults”, essas paginações são movimentações de dados entre a memória e disco. Esse é um processo muito mais custoso do que o “soft page fault”. A paginação da memória para o Paging File é apenas um dos possíveis causadores de “hard page faults”. Na realidade, qualquer mecanismo de “Memory Mapping” contabiliza como uma operação de movimentação de dados. O problema desse contador é que operações simples como cópia, leitura e gravação de arquivo afetam o “pages/sec”.

Quando há problema de falta de memória, é possível observar um leve aumento nesse contador. Na prática, altos valores de “Memory:Pages/sec” são normalmente gravação do arquivo de Backup ou cópia de arquivo usando o File Explorer.

Partindo do princípio de que o SQL Server não usa Paging File, não recomendo que faça a monitoração de paginação do SO. Entretanto, se você realmente quer diagnosticar algum mecanismo de paginação, então o ideal é monitorar a variação de tamanho do Working Set dos processos.

No próximo artigo, vou comentar sobre os 3 últimos contadores que você deve tomar cuidado.

Comments

  • Anonymous
    January 28, 2016
    A série está muito boa, está mudando meu mind setting sobre perfmon.. Aguardando o session finalle... Abraço.