Share via


Perfmon: Monitorando o Buffer Manager

O gerenciador de memória de Buffer de dados, também conhecido por Data Cache ou Database Cache, fornece as melhores informações sobre a utilização de memória do banco de dados.

Inicialmente analisamos os contadores:

  • Page life expectancy
  • Lazy writes/sec
  • Free list stalls/sec

Segue aqui alguns exemplos de gráfico do Page Life Expectancy (PLE). Particularmente, gosto de utilizar validar se o PLE está acima de 5000 ao invés de usar o tradicional valor limite de 300. Nos casos abaixo, todos os servidores apresentam carga ao longo do dia, embora apenas o terceiro esteja com aparente falta de memória.

image

image

image

Podemos complementar a análise olhando o contador Free List Stalls/sec, que deve ser sempre zero absoluto – parece que existe um novo Latch que deixa claro sua interferência, que se chama Lazy Writer Helper.

Em seguida, podemos olhar a distribuição de memória usando os contadores:

  • Database pages
  • Free pages
  • Stolen pages
  • Target pages
  • Total pages

Os servidores apresentam: 1) distribuição constante e normal; 2) folga e sobra de memória; 3) alto consumo de memória não-buffer (stolen). Em nenhum dos gráficos temos uma situação que podemos chamar de crítica, que seria quando o Stolen Memory chega a 75% do total de memória (pressão interna) ou quando o Total Pages e Target Pages começam a diminuir ao longo do tempo (pressão externa).

image_thumb[3]

image_thumb[5]

image_thumb[4]

Por fim, confirmamos que as variações do PLE são causados por Table/Index Scan no servidor usando os contadores Page Reads/sec e Readahead pages/sec. Adicionalmente, você pode acompanhar o contador Page lookups/sec para ter uma ideia da carga.

  • Page lookups/sec
  • Page reads/sec
  • Readahead pages/sec

Seguem os gráficos correspondentes: notamos que a quantidade de Reads (aleatório + sequencial) é praticamente igual a Readahead (sequencial). Assim, o primeiro servidor apresenta picos de utilização, que causam grandes variações no PLE . No segundo e terceiro servidor, está ocorrendo uma operação de Scan realizando a leitura de 10-30 mil págnas por segundo (equivalente a 80-240MB/seg!!!).

image

image

image

Aqui conseguimos concluir:

  • Servidor 1 possui memória suficiente para aguendar a carga. A variação do PLE ocorre por conta de picos de consumo (ver gráfico do readahead), mas não há indícios de falta de memória.
  • Servidor 2 possui memória de sobra (ver o gráfico de Free Memory) e recebe uma carga bastante pesada (ver gráfico de readahead)
  • Servidor 3 recebe uma carga semelhante ao Servidor 2 (ver gráfico de readahead), entretanto o PLE indica que o nível de memória está constantemente baixo. A distribuição de memória revela que grande parte está reservado como Stolen Memory (provavelmente são Memory Grants). A carga desse servidor é alta e falta memória.

Não há dúvida que o Performance Monitor é a melhor ferramenta para conduzir uma análise sobre a utilização de memória do SQL Server.