Partager via

Analisando problemas de performance - Um estudo de caso (Parte 1 de 4)

  • Article

Hoje começa uma série de artigos onde vou abordar um tópico que eu acho ser do interesse de muitos: como analisar um problema de desempenho e os contadores de performance envolvidos.

Essa série de quatro artigos é um estudo de caso onde eu vou detalhar o trabalho que fiz recentemente em um dos nossos clientes Premier. Este gentilmente aceitou que eu escrevesse esta série de artigos utilizando os dados reais que obtivemos durante o serviço, mas por questões de privacidade o nome da empresa, funcionários envolvidos, nomes de servidores e procedimentos, serão omitidos ou trocados.

Os quarto artigos serão divididos em:

1) Descrição do cenário e contadores encontrados

2) Identificando o gargalo

3) Procedimento com tempos diferenciados de execuções

4) Resultado da aplicação das correções

Gostaria de ressaltar que esta série não é uma listagem detalhada de todos os contadores de performance, mas sim uma análise daqueles contadores que interessam nesse caso. Vou aproveitar e responder uma pergunta que todos vivem me fazendo...

P: Por que a Microsoft não libera um documento formal com todas as recomendações dos contadores de performance que devemos analisar?

R: Porque a análise dos contadores de performance não é algo binário (ou está certo ou errado) e um documento muitas vezes mostra dessa forma. Pela minha experiência em diversos trabalhos com casos de performance tuning, se a Microsoft soltar um documento desse tipo, no dia seguinte o número de chamados com “falsos problemas” vai bater lá na lua e ela não vai conseguir atender toda a demanda, gerando uma insatisfação sem motivo real.

Também temos que levar em conta o fato de que nenhum contador deve ser analisado de forma isolada, eu NUNCA vou olhar para somente um contador de disco e dizer: temos um problema de disco! É importante sempre correlacionar contadores e ter informações para basear sua tese sobre o problema, senão esse palpite inicial pode se mostrar errado muitas vezes.

Existem alguns engenheiros dentro da Microsoft que tem planos de divulgar tal documento em forma de um webcast (ainda não sei quando, mas avisarei), onde teremos chance de explicar o que analisamos e porque não é necessário se alarmar em alguns casos. Dessa forma o impacto do documento no público (e Microsoft) seria menor. Capisce?

De qualquer forma, aqui estou eu para mostrar a vocês um trabalho real e quais foram os contadores de performance que eu analisei para chegar a uma série de recomendações, que ajudaram o cliente a minimizar os problemas encontrados.

PARTE 1 - Descrição do cenário e contadores encontrados

Na primeira conferência para definição do escopo do trabalho e entendimento do problema, as seguintes informações me foram passadas:

1) O ambiente é crítico (24x7) e atualmente está passando por problemas de performance, com procedimentos levando muito tempo para serem executados. Esse ambiente funcionava perfeitamente meses atrás, mas o número de usuário vem crescendo com a aquisição de novas empresas e abertura de novos negócios, o que está degradando o desempenho das aplicações.

2) Neste momento não existe interesse em se analisar o código das aplicações: consultas e stored procedures.

3) Já fizemos uma análise inicial e identificamos um problema com os nossos discos, que não estão respondendo bem. Queríamos que a Microsoft ratificasse o que já encontramos.

Configuração do servidor:

  • Hardware: HP DL380G4
    • Processadores: 2x P4 3.4 Xeon (com HyperThreading habilitado)
    • Discos:
      • Sistema operacional (C:), arquivos diversos (D:) e Log (L:) em RAID 1 (dois discos)
      • Dados (G:) e backup (I:) em RAID 5 (quatro discos)
    • Memória: 3 GB
    • Arquivo de paginação no C:
  • Sistema operacional: Windows Server 2003 – 32 bits
  • Interface de rede: 1 gigabit

Configuração do SQL Server:

Name

Run_Value

 

min memory per query (KB)

1024

affinity mask

0

 

min server memory (MB)

1024

allow updates

0

 

nested triggers

1

awe enabled

0

 

network packet size (B)

4096

c2 audit mode

0

 

open objects

0

cost threshold for parallelism

5

 

priority boost

0

Cross DB Ownership Chaining

0

 

query governor cost limit

0

cursor threshold

-1

 

query wait (s)

-1

default full-text language

1033

 

recovery interval (min)

0

default language

0

 

remote access

1

fill factor (%)

70

 

remote login timeout (s)

20

index create memory (KB)

0

 

remote proc trans

0

lightweight pooling

0

 

remote query timeout (s)

600

locks

0

 

scan for startup procs

1

max degree of parallelism

0

 

set working set size

0

max server memory (MB)

2500

 

show advanced options

1

max text repl size (B)

65536

 

two digit year cutoff

2049

max worker threads

255

 

user connections

0

media retention

0

 

user options

0

Com o intuito de termos dados suficientes para iniciarmos nossa análise, pedi que fossem utilizados o Performance Monitor (ou System Monitor) e o SQL Server Profiler. Essa coleta ficou rodando durante quase um dia (vinte e duas horas), já que também existem diversos procedimentos sendo executados durante a madrugada.

Para facilitar a vida de vocês eu coloquei em uma planilha Excel o valor médio dos contadores que eu considerava mais importantes para este caso. No arquivo anexo a este artigo, vocês encontrarão esta planilha, bem como o artigo em formato PDF.

Vale lembrar que a planilha contém os valores médios para os contadores entre 11:34AM e 9:49AM do dia seguinte. Usualmente eu crio diversas planilhas com intervalos de interesse durante o dia, mas para nosso caso os dados deste intervalo já contêm informações interessantes para análise.

Agora o trabalho está em suas mãos! Analise o cenário, veja os contadores, crie hipóteses dos problemas que o ambiente pode estar apresentando e, é claro, como todo bom engenheiro de suporte, proponha soluções para este caso.

Na próxima semana eu vou postar a segunda parte desta série.

Para aqueles que querem montar seu próprio documento de orientação (para a sua empresa?!), aconselho dar uma olhada em diversos livros publicados. Sempre encontro com uma ou outra recomendação de contadores que podem ser utilizados, não é uma tarefa fácil, mas vale a pena.

[]s

Luciano Caixeta Moreira

luciano.moreira@microsoft.com

=============================================================

This posting is provided "AS IS" with no warranties, and confers no rights

=============================================================

20070703 - Analisando problemas de performance - Um estudo de caso (Parte 1 de 4).zip

Comments

  • Anonymous
    July 18, 2007
    The comment has been removed

  • Anonymous
    July 18, 2007
    Oi Nilton, as colocações foram excelentes! :-) Não vou comentar cada item agora, mas no próximo artigo eu aproveito e aponto algumas das questões levantadas por você. Fica aqui alguns questionamentos: Colocando o /3GB você vai realmente conseguir alocar 2,5 GB, o que o SQL Server não estava fazendo. Acertou em cheio, MAS... A adição de mais memória vai ajudar na atual situação? Como você pode verirficar isso? Qual o impacto dessa alteração no servidor e quais os cuidados que devemos ter? Abraços. Luti

  • Anonymous
    July 22, 2007
    A adição de mais memória vai ajudar na atual situação?  SIM. Como você pode verirficar isso? Aumento no Buffer Pool !! Mais memória para cache de dados e de procedure. Penso também que como a área de memória do SQL Server irá aumentar em 1GB, a tendência é que o contador Page life expectancy aumente, indicando um aumento no tempo de vida das páginas no cache, tendendo a reduzir o Readahead pages/sec. Qual o impacto dessa alteração no servidor e quais os cuidados que devemos ter? O SQL Server passará a alocar os 2.5GB deixando apenas 500MB para o SO. Deve-se acompanhar com atenção para ver se isso não será muito pouco e acabe trazendo problemas no nivel SO. abraços Nilton Pinheiro

  • Anonymous
    December 19, 2007
    Boa noite, Tenho como conseguir as partes 3 e 4 do assunto, por favor? Obrigado!