Getting your Trinity Audio player ready...

A algumas semanas atrás eu estava ajudando um cliente a localizar problemas de lentidão no ambiente dele. Não havia um ponto exato, não era sempre na mesma aplicação, muitas vezes nem a mesma unidade, isso ajudava muito na localização do problema,,, Smiley triste

Um dos analistas de desenvolvimento me indagou se o servidor de SQL estava sofrendo com problemas de processador,,, em alguns momentos o servidor apresentava alguns picos em um dos núcleos mas nada muito longo muito menos alarmante.

proc

Com a query abaixo, mostrei que não havia problemas de processamento,,, pelo menos naquele momento…

 Select signal_wait_time_ms=sum(signal_wait_time_ms)<br>,'%signal (cpu) waits' = cast(100.0 * sum(signal_wait_time_ms) / sum (wait_time_ms) as numeric(20,2))<br>,resource_wait_time_ms=sum(wait_time_ms - signal_wait_time_ms)<br>,'%resource waits'= cast(100.0 * sum(wait_time_ms - signal_wait_time_ms) / sum (wait_time_ms) as numeric(20,2))<br>From sys.dm_os_wait_stats 

O resultado é o seguinte:

proc1

Agora vem a pergunta: Legal, mas idaí?

O que nos interessa nesse resultado é o %signal (cpu) waits e o %resource waits.

A matemática é bem simples: quanto mais %recouce waits e menos %signal (cpu) waits melhor, quer dizer que, nesse momento não está havendo problemas de pressão com processador, não quer dizer que daqui a 1 segundo não comece a ter, mas no momento da execução dessa query não havia problema.

English version

A few weeks ago i was helping a client to find a slow problem on his environment. Don´t had a exact point, not always the same apllication, even the same place and this help a lot to find the problem.

One of the developers ask me if the SQL Server had problems with processos pressure,,, in a few moments on the day the server show a top processes in one of the cores, but was not the problem.

With the query below i show that we don´t have any problem with the processor, in that moment…

 Select signal_wait_time_ms=sum(signal_wait_time_ms)<br>,'%signal (cpu) waits' = cast(100.0 * sum(signal_wait_time_ms) / sum (wait_time_ms) as numeric(20,2))<br>,resource_wait_time_ms=sum(wait_time_ms - signal_wait_time_ms)<br>,'%resource waits'= cast(100.0 * sum(wait_time_ms - signal_wait_time_ms) / sum (wait_time_ms) as numeric(20,2))<br>From sys.dm_os_wait_stats 

The result was:

proc1

And then comes the question: Cool, but WTF?

The important is %signal (cpu) waits and %resource waits.

The mathematic is simple: more %recouce waits and lass %signal (cpu) waits is better, in that moment the server don´t have processos pressure.

Sorry about the poor English, i´ll fix at night.

3 Comments

  1. Ok Leka, mas qual o percentual de %recouce waits e %signal (cpu) waits é preocupante? Tipo: passou de X % %recouce waits ou Y% de %signal (cpu) waits devemos já começar verificar o que está causando o problema.

    1. Olá,
      bom,,, isso é uma boa pergunta,,, a melhor resposta é um depende.. 😀
      Depende do que? da quantidade de processadores disponíveis, como suas querys estão escritas, planos de execução, etc…
      nos ambientes que administro, quando começo a ter “%signal (cpu) waits” superior a 10% já começo a ver se existe alguma coisa de errado (querys “estranhas”, planos de execução ruins, estatísticas desatualizadas), mas isso varia de ambiente para ambiente.

Leave a Reply

Your email address will not be published. Required fields are marked *