SQLServer: A taxa de acertos do cache de buffer é uma boa indicação de POSSÍVEL gargalo de memória?

Precisamos olhar para SQLServer: Taxa de acertos do cache de buffer. Se essa taxa for inferior a 95%, o servidor está sob pressão de memória

Pare de olhar para o buffer Taxa de acertos do cache para determinar a pressão da memória. Isso ocorre porque com o mecanismo de leitura antecipada no SQL Server, mais do que páginas suficientes já estão no pool de buffer para satisfazer a consulta, de modo que o BCHR não fornece dados precisos sobre a pressão da memória. Você pode até ver que o BCHR não cai quando há pressão de memória. Tudo isso foi explicado em Grande debate sobre o SQL Server sobre BCHR

A saída de PLE que você postou parece muito baixa, mas não podemos usar apenas um contador para medir a pressão da memória. PLE é mais uma indicação de atividade de E / S no servidor. É possível que, devido à intensa atividade de E / S, o PLE tenha despencado. Se você notar que a memória do servidor de destino e total ainda permanece a mesma. O que é um bom sinal.

Para Edition upto 2008 R2. Você pode usar os contadores abaixo

1. SQLServer: Buffer Manager – CheckpointPages / sec:

2. SQLServer: Buffer Manager – Memory Grants Pendente:

3. SQLServer: Gerenciador de buffer – Memória do servidor de destino:

4. SQLServer: Gerenciador de buffer – Memória total do servidor

5. SQLServer: Gerenciador de Buffer – Páginas Livres

6. SQLServer: Gerenciador de Buffer – Bloqueio de Lista Livre / sec

7. SQLServer: Gerenciador de Buffer – Expectativa de vida da página

Para SQL Server 2012 onwards alguns do Buffer Os contadores de pool estão obsoletos e, portanto, temos que usar contadores do gerenciador de memória

1. SQL Server: Gerenciador de memória – memória do servidor de destino (KB)

2. SQL Server: Gerenciador de memória – Memória total do servidor (KB)

3. SQL Server: Gerenciador de memória – Memória livre (KB)

4. SQL Server: Gerenciador de Memória – Memória Cache do Banco de Dados (KB)

5. SQLServer: Gerenciador de Buffer – Páginas Livres

6. SQLServer: Gerenciador de Buffer – Lista gratuita bloqueada / s

7. SQLServer: Buffer Manager – Expectativa de vida da página

Observe que se você tiver muita atividade no disco, não se esqueça de consultar os contadores relacionados ao disco também. Crie um conjunto de coletores de dados e deixe-o funcionar por 4-5 horas quando a carga no sistema estiver no pico e, em seguida, adicione o instantâneo do coletor de dados em sua pergunta. Então podemos determinar se o SQL Server precisa de mais memória ou não.

Pessoalmente, 8G é um pouco menos de RAM considerando a carga de trabalho e os requisitos do sistema operacional atualmente. No fundo, você deve sempre pensar em aumentar a RAM.

precisamos olhar para SQLServer: taxa de ocorrência do cache de buffer

Se essa taxa for inferior a 95%, o servidor está sob pressão de memória

Espero que isso ajude,

Isso não o ajudará a decidir o gargalo de memória por conta própria com certeza. Em vez disso, eu preferiria coletar os dados para os contadores abaixo pelo menos por um dia durante o horário comercial / de carga pesada.

Memory – Available MBytes SQLServer: Buffer Manager – Page Life Expectancy SQLServer: Memory Manager – Memory Grants Pending SQLServer: Memory Manager – Target Server Memory SQLServer: Memory Manager – Total Server Memory SQLServer: SQL Statistics – Batch Requests/sec SQLServer: SQL Statistics – Compilations/sec 

O melhor seria basear o servidor SQL conforme sugerido Voltar ao básico: capturando linhas de base no SQL de produção Servidores que também coletarão os contadores de perfmon necessários junto com estatísticas de espera para qualquer problema.

Além disso, 8 GB de RAM pode não ser tão adequado para o ambiente de hoje, mas novamente depende do que é a carga no sistema junto com o tamanho dos bancos de dados hospedados na instância \ instâncias.