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.

7 ideias sobre “DESAFIO DO GORDO – Troubleshooting de Performance

  1. Thiago

    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.

    Resposta
    1. Thiago Caserta

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

      Um abraço!

      Resposta
  2. Letícia de Oliveira

    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.

    Resposta
  3. Leonardo Pedroso

    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.

    Resposta
  4. Anderson Souza

    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.

    Resposta
  5. Pingback: DESAFIO DO GORDO – Troubleshooting de Performance | Vitor Fava

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 )

Foto do Google

Você está comentando utilizando sua conta Google. 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 )

Conectando a %s

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.