Recentemente, li uma postagem no blog mssqltips.com sobre gargalos de memória no SQL Server. Neste artigo li o seguinte:
Os seguintes contadores de desempenho no SQL Server: O objeto Buffer Manager também pode indicar pressão de memória:
- Alto número de páginas de ponto de verificação/s
- Alto número de gravações preguiçosas/s
- Alto número de leituras de página/s
- Baixa taxa de acerto do cache de buffer
- Baixa expectativa de vida da página
O que me chamou a atenção foi que um número alto de 'páginas de checkpoints/s' pode indicar pressão de memória.
Meu entendimento era que um ponto de verificação grava páginas 'sujas' no disco. Isso pode ser acionado de diferentes maneiras.
- automático (para manter o intervalo de recuperação)
- indireto (para manter o tempo de recuperação alvo)
- manual
- interno
Um número tão alto de checkpoints indica um sistema muito ocupado (no caso de checkpoints automáticos e indiretos).
Como um ponto de verificação nunca remove uma página do cache de buffer, não entendo bem como o alto número de pontos de verificação/s pode indicar pressão de memória. Se houver pressão de memória, eu gostaria de ver um alto número de 'gravações preguiçosas/s'. O escritor preguiçoso remove 'páginas frias' da memória, para dar lugar a novas páginas.
Como um alto número de páginas de ponto de verificação/s indica pressão de memória?
Não indica diretamente a pressão da memória. O valor em si é cumulativo e não fornece muitas informações sobre a pressão da memória.
No blog mencionado por você eu não confiaria em seguir 2 contadores para pressão de memória.
Para BCHR a razão já é explicada por Jonathan Kehayias neste Blog . Isso lhe daria uma interpretação incorreta se você confiar nele por causa do recurso SQL Server de Read Head.
O trabalho do ponto de verificação no SQL Server é diminuir o tempo geral de recuperação do SQL Server. Ponto de verificação mais frequente significa menos quantidade de registro de log de transações necessária para avançar e, portanto, recuperação mais curta. Portanto, eu não igualaria páginas de alto ponto de verificação/s ao gargalo de memória. Precisaria de uma análise mais aprofundada ou simplesmente em um sistema muito ocupado pode ser ignorado. É apenas o SQL Server se esforçando para garantir que, quando o banco de dados passar pela recuperação de falhas, ele fique online em um tempo mínimo, permitindo que você atenda o RTO.
Se eu quisesse olhar para a pressão da memória, dispararia seguindo os contadores de perfmon