DESAFIO DO GORDO – Troubleshooting de Performance

E ai galerinha, tudo bem com vocês?

Hoje quero propor um desafio bem interessante para vocês em mais uma edição do DESAFIO DO GORDOOOOOOOOOOO!!!!

Vamos imaginar que você trabalha na empresa SQLMANIACS S/A e que utiliza o SQL Server 2012 Enterprise X64 como plataforma de banco de dados.

O principal servidor possui 2 processadores com 12 cores cada e um total de 96 GB de memória RAM, além de 5 discos mapeados para o servidor.

Atualmente os usuários tem reclamado constantemente de lentidão nas aplicações que acessam o servidor de banco de dados SQL Server.

Em uma rápida análise, você percebeu que durante os períodos de maior lentidão, os discos que possuem os arquivos de dados do banco de dados de sistema TEMPDB são extremamente acessados para leitura e escrita.

Além disso, o contador de performance Page Life Expectancy está com um valor médio de 120 durante todo o período em que os usuários relatam que a lentidão fica muito pior.

Quero saber de vocês o seguinte:

  • Qual o problema que está ocorrendo neste servidor?
  • Como podemos levantar mais indícios sobre a causa-raiz desse problema?
  • Quais as possíveis ações para resolver o problema?

Basta colocar suas respostas nos comentários galera.

Não deixem de fazer sua inscrição no blog e receber todas as informações que forem postadas por aqui.

Grande abraço.

Anúncios
  1. Thiago
    08/10/2013 às 13:47

    Bem,de cara falaria que temos uma pressão de memória, pelo Page Life Expectancy que você mencionou. Olharia a dm_exec_requests para avaliar quais Waits poderiam estar impactando. Provavelmente a quantidade de Lazy Writes, devido a pressão de memória, pode estar impactando com relação à performance das aplicações.
    Olharia um pouco mais os contadores de disco no Perfmon, para ver tempo de escrita e leitura, e também as configurações da Max Server Memory da instância.

    • Thiago Caserta
      08/10/2013 às 13:54

      Esqueci de mencionar que no Perfmon também daria para ver a quantidade de Lazy Writes, nos contadores de Buffer Manager.

      Um abraço!

  2. Letícia de Oliveira
    09/10/2013 às 0:05

    O tempo 120 de Page Life Expectancy pode derterminar que há um problema de memória, 300 segundos é a meta mínima que a Microsoft indica que tenha.
    Podem ter planos de consulta ineficientes e/ou consultas que retornam milhões de linhas.
    Olharia os contadores de disco para verificar escrita/leitura, a configuração de Max Server Memory da instância, verificaria no cache quais são as consultas presentes(sys.dm_exec_cached_plans e sys.dm_exec_sql_text).
    Vale a pena também dar uma olhada nos wait_types(sys.dm_exec_requests).
    Se algum disco estiver com leitura muito acima do normal você já pode tentar isolar o problema a alguma atividade que esteja envolvendo os arquivos de dados guardados neste disco, logo sua busca nas consultas que recuperou do cache já estará com um filtro mais apurado.
    Atualizar estatísticas, desfragmentação de índices, análise/tuning das queries top consumidoras de recursos.

  3. 09/10/2013 às 8:34

    O sistema tem que tá bem sobrecarregado mesmo pra colocar 96GB de memória em um PLE de 120 hehehehhehehehe

    Mas como o problema é pontual, são em determinadas horas do dia, não julgo que seria um problema de desempenho generalizado não, pois se fosse, isso ocorreria em várias horas do dia.

    Acredito que isso seja alguma carga muito violenta para um sistema OLAP, acompanhado de um table SCAN em uma BIG TABLE. O resultado dela provavelmente usa tabela temporária para armazenar alguns dados para tratamento e depois salva em outro lugar.

    Também não descarto a hipotese do RCSI estar habilitado e versionando milhares de linhas no tempDB.

  4. 09/10/2013 às 15:02

    de bate e pronto… eu olharia o tamanho inicial do TEMPDB e sua taxa de crescimento, pois ele deve estar com seu tamanho sendo alterado constantemente…

  5. Anderson Souza
    10/10/2013 às 13:28

    Poderia ser um problema de disco, usando o contador AVG Disk Queue lenght, se estiver acima de 2 certamente esta ocorrendo swap, pela falta de memoria. Como ações primeiramente verificaria onde estão os arquivos de log e tempdb, para separa-los se for o caso. Como temos dois processadores (12 Cores) criaria um tempdb para cada processador.

  1. 21/10/2013 às 23:51

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: