Investigando uma queda do contador Page Life Expectancy.


Olá pessoal, tudo certo? Espero que sim!

 Já faz um tempo que montei um rápido post explicando o contador Page Life Expectancy (http://sqlmagu.blogspot.com.br/2013/04/v-behaviorurldefaultvmlo_30.html), bom, apenas para relembrarmos, este contador marca em segundos quanto tempo uma página permaneceu na memória (Buffer Pool) do SQL Server.

 Recentemente, analisando uma coleta do Performance Monitor feita através do SQLdiag das 06h00 às 18h00 de um servidor, me deparei com o seguinte gráfico para este contador:


 Notem a queda aproximadamente às 08 horas, chama bastante atenção não? Mas tem algo nesta imagem que chama mais atenção ainda...descobriram? Vejam que o PLE caiu e não conseguiu mais se reestabelecer. Além disso, várias outras quedas menores foram registradas, precisamos descobrir o que está fazendo estas páginas na memória “girarem” tão rápido que acabaram impedindo o contador de voltar ao seu valor normal. 

 Ao olhar os dados do PerfStats Script no momento da queda (~08h00) não encontrei nada estranho. Porém, olhando 7 minutos à frente, localizei uma procedure que do ínicio até o final de sua execução fez 35.598,398 leituras lógicas, este valor é extremamente alto para uma única request:
 


 Sabendo que uma página que uma request toca é uma leitura lógica, e que uma página no SQL Server possui 8kb, temos que este valor em MBytes corresponde à ~278,112 MBytes, ou ~271 GB.

 O Max Server Memory da instância do SQL Server estava configurado em 6GB conforme abaixo:


 Olhando as próximas quedas do PLE, novamente peguei a mesma procedure rodando e fazendo sempre uma quantidade alta de leituras lógicas. Esta ai nosso problema, com um Buffer Pool limitado em 6 GB e com apenas uma procedure que sozinha manipula uma quantidade de dados ~45x maior que isso é impossível que a expectativa de vida das páginas volte a subir e permaneça em um valor considerado normal para o ambiente.

 É isso pessoal, neste cenário o mais importante não foi olhar a queda e sim o que veio depois dela, daí pra frente partiríamos pra uma análise lógica da procedure etc. Espero que o post tenha sido útil, um abraço pessoal!

4 comentários:

  1. Muito bom!
    uma dúvida: são vários os scripts do perfstats, certo?
    Qual deles você deixa sempre ligado e com que periodicidade?

    Abs
    ps: bem legal o webcast de ontem.

    ResponderExcluir
  2. Olá Dhiego! O perf stats é unico, existe o perf stats snapshot que é outro script que realiza outras coletas, basicamente top queries e missing indexes. Costumo deixar sempre estes dois, sendo que o perf stats sempre fica rodando e o perf stats snapshot roda ao inicio da coleta ou no final, fica à seu critério. A periodicidade do perf stats costumo deixar a padrão que vem no xml baixado no codeplex (https://sqlnexus.codeplex.com/wikipage?title=Sql2005PerfStatsScript). Muito obrigado pela presença no webcast! Um abraço!

    ResponderExcluir
    Respostas
    1. Fala André,
      Me expressei de forma incorreta.
      Me referia ao arquivo XML e ao seus níveis de intrusão.
      No seu ambiente você costuma deixar a captura de trace habilitada, ou só os eventos do perfmon + Wait events + Event Log do Windows

      Abs

      Excluir
    2. Tranquilo Dhiego? Então, costumo trabalhar com o perfmon, perf stats script e perf stats snapshot. Não utilizo o profiler para evitar problemas de degradação de performance, se tem algo muito especifico que precise realmente do profiler a melhor saida em minha opinião é uma coleta utilizando ex events, que usa um mecanismo bem mais leve e coleta praticamente as mesmas coisas. Veja o post que fiz sobre isso: http://sqlmagu.blogspot.com.br/2013/09/desapegue-do-sql-server-profiler-use.html Abraço!

      Excluir