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


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 (24×7) 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 (4)

  1. Olá Luciano….show de bola. Está aí um problema muito comum.

    Bom, vamos ver se acerto alguma coisa:

    Disco >> Temos grande fila no disco G:, no entanto, como o backup está o mesmo disco a fila pode ser de escrita… seria interessante ver também os contadores disk read/sec e disk write/sec.  (backup em RAID 5 é cruel…penso eu) Recomendaria alocar um disco exclusivo para backup, se não for possível, pelo menos jogar no D: (RAID1)

    Rede >>> OK

    Memoria >>> O SQL Server está configurado para 2500MB mas ao verificar o contador Target Server Memory(KB) notamos que o SQL está usando apenas 1624MB. A solução aqui é verificar se a opção /3GB está no boot.ini, isso aumentará a VM do processo do SQL para 3GB e permitirá o uso dos 2500 configurados. Bom… vai depender da edição do SQL 🙂

    Page File >> OK

    Processador >> OK

    Access Methods: Full Scans/sec e Index Searches/sec muito alto hein !? Uma verificação nos índices da tabela pode ajudar.

    Object: SQLServer:Buffer Manager >>> Mais indícios de falta de memória ou ainda problemas com índices… Muitos Table Scan, Index Scan…. etc scan

    Databases >> De todos os bancos podemos ver uma maior utilização do TEMPDB. Muita utilização de tabelas temporárias ? Pode ser que isso explique os altos valores no Full Scan, Index Search….. Criação de tabelas temporárias com índices pode ser uma boa.

    No mais, podemos também mais arquivos para o tempdb (1 para cada CPU) e ativar o trace flag 1118 para reduzir o overhead no tempdb.

    A princípio acho que é isso.. esto no caminho certo 🙂

    abraços

    Nilton Pinheiro

  2. MSDN Archive says:

    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

  3. 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

  4. Boa noite,

    Tenho como conseguir as partes 3 e 4 do assunto, por favor?

    Obrigado!

Skip to main content