Blog archives

3 Articles

Desempenho do Processador x Desempenho do SQL Server – Parte 3

Post 3/3. Este post é parte da série: Desempenho do Processador x Desempenho do SQL Server

São 7 horas da manhã, e recebo uma ligação da Equipe de BI, dizendo que todas as cargas estão 50% mais lentas. O caos se instaura na equipe, pois os relatórios do dia não estariam prontos…

Isso aconteceu depois de uma migração. A máquina antiga era virtual. A máquina nova? Física. Com configurações idênticas! Como pode? O mínimo, era ter desempenho igual, não inferior. O que aconteceu?

Vou contar melhor essa história…


Bem vindo de volta!

No último post desta série, você viu como uma redução de 50% no clock da CPU impactou diretamente no tempo das consultas de um SQL Server.

Se você ficou surpreso com isso, saiba que não tem nada de novo. Isso se dá por uma simples teoria matemática: velocidade e tempo são grandezas inversamente proporcionais. Se eu dobrar a velocidade, eu faço na metade do tempo. Do mesmo jeito que, se eu usar metade da velocidade, eu gasto o dobro do tempo.

E, foi exatamente isso que aconteceu no exemplo o post anterior: a velocidade da CPU diminui, e o tempo das instruções, e, consequentemente, da nossa query, aumentou.

Mas por que você se preocuparia com isso? Afinal, quem seria louco o suficiente para baixar a velocidade da CPU pelo gerenciamento de energia? E é aí que voltamos a nossa historinha…

Um caso real e inesquecível

Que absurdo é esse, onde, uma máquina física, idêntica a virtual (pra ser mais preciso, idêntica ao host da máquina virtual), é tão mais lenta?

Nós gastamos um bom tempo checando tudo, configurações da instância, bloqueios, disco, etc. Até que, tive a ideia de fazer um simples teste de CPU: Vou comparar quanto tempo levo pra executar uma quantidade de instruções na instância antiga e na nova. Como fazer isso no SQL Server? Um simples loop:

Este código SQL é  muito simples:

  1. A variável @i, começa em 10 milhões. O meu objetivo é decrementar ela até que chegue em zero. O processador vai ser utilizado basicamente para operações aritméticas… Que são simples e rápidas…
  2. Eu utilizo a variável @start para gravar a data e hora atuais, antes de começar o loop WHILE…
  3. Ao final do meu loop while, eu calculo quanto tempo se passou, subtraindo a data de agora, pelo valor gravado em @Start

Este é um código que vai gastar apenas CPU. Não tem disco, rede, memória, ou outra coisa significativa envolvida.  Mais de 99% do tempo desse script vai ser gasto executando instruções na CPU. Quando eu executei este script na máquina antiga, ele me retornou um tempo de 5 segundos. Quando executei na nova, variava de 7 a 8 segundos.

Comparando tempos de CPU usando T-SQL. O script demora aproximadamente 4 segundos para subtrair 10 milhões em uma CPU de 3.1 Ghz! Já em uma CPU de 1.39 Ghz, ele leva 10.5 segundo! 😯 😯 😯 😯

 

Pronto, tinha achado um norte. O próximo passo nesse caso, foi verificar se o problema estava dentro do SQL Server, ou era algo generalizado, no Sistema Operacional. Então, fiz a mesma versão desse script, em powershell:

E novamente, comparei o resultado com a máquina nova e antiga! Mesma situação. Agora excluí o SQL Server do problema. O script na máquina antiga (virtual) retornava um valor muito inferior ao da máquina nova(física). A partir daí, usei o CPU-Z (era um Windows Server 2008) e constatei que o clock do processador do servidor novo estava operando a 2.2 GHz, enquanto que o CPU-Z da máquina virtual, reportava 2.5 GHz. Uma diferença de apenas 300 MHz, foi suficiente para dar dor da cabeça no ambiente de BI!

Você pode estar se perguntando o porquê de apenas 300 MHz, causar 50% de lentidão no processo de carga e a razão é muito simples:

  • O processo de carga não envolve apenas uma única consulta. São várias consultas. Consultas de 2, 3, 15 minutos, subindo para 4, 6, 18 minutos, respectivamente. As consultas pequenas também.
  • A instância onde ocorria tudo isso, além de concorrer com um Analysis Service e Integration Services, que também estavam sendo impactados pelo problema, tinham outras queries em execução, de outros relatórios, e não somente do processo de carga.
  • Todo o sistema operacional lento, logo, gravações em disco mais lento, comunicação de rede mais lento. Toda a concorrência do processador estava maior, uma vez, que a CPU está mais lenta, tudo demora mais na CPU, e aí aumenta a espera por CPU

A rua é o processador, e os veículos são nossas queries e processos… Experimenta colocar todo mundo um pouco mais lento pra ver o caos que vira…

 

O problema foi resolvido depois que, comprovado para a equipe de infraestrutura que o problema era da máquina, eles abriram chamado no fabricante, que detectou uma atualização de BIOS. E aí resolveu tudo (depois de várias tentativas por parte deles, como mudar configuração da BIOS, colocar a máquina com 100% de energia, já que ela aceitava 4 cabos de força, e apenas dois estavam plugados, etc.). Isso levou meses, e tivemos que desfazer a migração até lá. Quando nos foi reportado que a máquina estava pronta, apenas repetir todos os testes, e dessa vez, os tempos estavam iguais. Prosseguimos com a migração, e tudo certo. O processo de carga estava até um pouco mais rápido!

Image result for gif claps velinhas

Epidemia

Alguns meses depois deste problema, um colega me procurou e me relatou sobre um problema de lentidão após um ambiente extremamente crítico migrar de SQL 2008 R2 para SQL 2014. Chegaram a cogitar problema com o novo CE… De novo, o problema era um clock mais lento nas novas máquinas.

Ainda, muito antes de fazer parte do #TeamFabricioLima, o Fabrício me contou sobre o mesmo sintoma: novo servidor e tudo mais lento, e novamente, achamos problema com velocidade do clock.

Depois disso, encontrei muitos problemas como este, até em ambiente com outros bancos de dados… Com outras tecnologias… Me dei a liberdade de batizar isso de epidemia de ClockLentopsia.

Image result for gif vergonha alheia

A questão aqui é: Quantas vezes você parou pra validar o desempenho do seu processador? Você coloca isso no seu checklist de migração? Um conceito extremamente simples, que pode estar afetando seu ambiente.

Você percebeu no post anterior que uma query de 266 ms foi para mais de 500ms… Na casa dos milissegundos, ninguém percebe isso. Você já pode ter migrado um ambiente sem nem sequer notar que a CPU ficou mais lenta… Mas as queries podem ter saído de 50ms, para 100ms…

Mas aqui vai um conselho: Sempre verifica! Sempre valide! Até agora nesta série, você já aprendeu a usar duas ferramentas e tem dois scripts para validar. Coloque isso nos seus processos e durma feliz após as migrações críticas! Não tô dizendo que este sempre vai ser o problema, mas se for, você vai pegá-lo, antes que o inverso aconteça.

 

E se ainda você precisar de uma força para avaliar casos estranhos como estes, pode chamar a gente do #TeamFabricioLima que vamos até  os bit e bytes da sua CPU para achar o problema!

E você acha que acabou por aqui? Nada disso! Ainda tem muito o que falar sobre CPU!

No próximo post quero explicar a você uma diferença muito importante sobre o tempo de CPU e o percentual de CPU. Você vai passar a analisar as queries de outra forma! Até lá!

 

 

Desempenho do Processador x Desempenho do SQL Server – Parte 2

Post 2/3. Este post é parte da série: Desempenho do Processador x Desempenho do SQL Server

Olá caro leitor,

Esta é mais uma série de posts, e o assunto da vez é o desempenho do processador. No post anterior, vimos alguns conceitos básicos sobre velocidade da CPU. Agora vamos aplicar um pouco desses conceitos no SQL Server e observar alguns efeitos na prática.

Revisão:

  • Clock = dispositivo da CPU que liga e desliga em uma certa frequência (clock tick)
    • 1 Hertz = 1 vez por segundo
    • 1 KHz = Mil vezes por segundo
    • 1 MHz = Um  milhão de vezes por segundo
    • 1 GHz = 1 bilhão de vezes por segundo
  • Cada instrução leva X clocks ticks. Quanto mais rápido um processodor, mais rápida as instruções executam.

 

No caso de código SQL, uma infinidade de instruções são executadas, não somente para acessar os dados e fazer alguma operação em cima deles, mas também para:

  • verificar locks/latches
  • checar permissões
  • acionar disco, rede

São centenas de milhares de instruções sendo executadas por uma simples consulta SQL. Isto significa que qualquer alteração na velocidade da CPU, a query poderá ser impactada (para melhor, ou para pior).

Vamos fazer um simples exercício, baseado numa query simples como esta:

  • Imagine que a query acima gaste  10 instruções. E pra simplificar mais ainda, imagine que cada instrução desta gaste apenas 1 tick do nosso clock.
  • Imagine que essa query execute num incrível processador de 100 Hertz (isso mesmo, cem ticks por segundo)
  • Primeiro, calcule o tempo de um tick:
    • 1 tick = 1000ms/100
    • 10ms = Cada tick nesse nosso incrível processador gasta apenas 10 ms!
  • Ora, se nossa query gasta 10 ticks, e cada tick tem 10ms, então ela vai gastar 100 ms de CPU (10ms * 10 ticks = 100 ms).
  • NOTA MUITO IMPORTANTE:  Aqui é só uma simulação de um gasto SOMENTE de CPU. Não estou colocando outras variáveis, como disco, memória, rede, etc.

Um exemplo de uma query que gasta um número X de instruções. O tempo total de CPU, vai sempre depender da velocidade do processador

Quando otimizamos essa query, criando um índice, ou adicionando mais filtros, estamos reduzindo o número de instruções (ou escolhendo instruções que gastam menos tempo).  E por isso o tempo de CPU diminui. Por exemplo, imagine que após criar um índice, causando a leitura de menos dados, a query execute com  apenas 4 instruções, então o tempo, no processador de mesma velocidade, será de 40ms ( 10ms * 4 ticks).

Simulando a otimização da query. Por exemplo, saindo de um clustered index scan, para um index scan, poderia causar a execução de menos instruções, devido a um menor número de páginas, menos colunas, etc. Tudo isso impacta na quantidade de instruções no final.

Simples, não?

Velocidade do Processador na prática

Vamos fazer o seguinte: Vamos brincar com nosso processador e observar como a velocidade do mesmo impacta em nossas consultas.

Os processadores mais modernos permitem alterar sua velocidade dinamicamente para poupar energia. Um clock que opera a 2.5 GHz gasta mais energia do que o mesmo clock operando a somente 100 MHz. Geralmente, os sistemas operacionais nos fornecem várias opções de controlar o gerenciamento de energia do processador.

Vamos criar um simples banco de dados com uma tabela grande e alguma quantidade considerável de registros:

  • Este código simplesmente cria um banco novo, uma tabela neste banco e insere alguns registros aleatórios.
  • Eu faço CROSS JOINs entre várias instâncias da view “sys.objects” apenas para gerar um grande número de registros.
  • O abs(CHECKSUM(newid())) gera um número aleatório para cada linha.

Antes de executar alguma query, vamos garantir que nosso computador irá operar no seu potencial máximo:

  1. Procure as opções de energia do seu computador. Você pode digitar powercfg.cpl no menu iniciar.
  2. Irá abrir tela tela semelhante a esta:

  3. Clique em “Alterar configurações do plano”, no respectivo plano que está marcando com a bolinha preta (No meu caso, o plano se chama “Dell”).
  4. Na próxima tela, cliquem em “Alterar configurações de energia avançadas”:

  5. Na janela que abrir, procure por “gerenciamento de energia do processador”:
  6. Altere o valor de mínimo para 100. Certifique-se que o máximo esteja em 100%, caso contrário, ajuste também. Se você está usando notebook, mas ele está usando a bateria como fonte de energia, então faça as alterações na opção “Na Bateria”. Se quiser garantir, pode alterar a configuração tanto para bateria, quanto para tomada. Memorize os valores que estavam antes para voltar a configuração original depois, ok?
  7. Pronto, clique em Aplicar, depois ok.
  8. Agora observe no Gerenciador de Tarefas (caso utilize um gerenciador de tarefas de uma versão anterior ao 2012 do Windows, você pode baixar a ferramenta CPU-Z):

  9. A velocidade deverá ficar sempre maior ou igual ao “velocidade base”.

O quê esta opção fez? Nós apenas solicitamos que o nosso processador sempre trabalhe no máximo de velocidade possível. Com isso,  mais energia será gasta, porém, nosso processador nunca irá baixar a velocidade. No meu caso, meu processador consegue trabalhar em 3.1 GHz (3 bilhões de ticks por segundo).

Esse percentual de CPU que você configurou NÃO é o mesmo percentual de CPU reportado pela maioria das ferramentas de monitoramento, como o próprio gerenciador de tarefas, process explorer, perfmon, etc. Seu processador ainda poderá bater 100% de uso! Explicaremos melhor depois.

Pronto, acabamos de deixar o processador em seu desempenho máximo, vamos rodar uma consulta e observar o tempo de CPU. Utilize o seguinte comando para obter o tempo de CPU:

Agora, execute a seguinte query:

Na aba “Messages” observe o tempo da execução. Se você acabou de reiniciar a instância, execute novamente, para garantir que iremos fazer leitura somente de dados em memória. Você está interessado no valor da informação “Cpu Time”:

O primeiro grupo de informação é referente ao tempo de compilação/recompilação da query. Ele rodou abaixo de 1ms, e por isso exibe zero.

Já o segundo grupo, este sim nos interessa. Ele nos diz quanto de CPU a query gastou, através da informação “Cpu time”. Note que o valor é de 266ms.

Agora vamos reduzir o máximo do nosso processador pela metade, e observar o que acontece com nossa query. Acesse novamente o powercfg.cpl, e repita o procedimento:

  • Escolha alterar configuração do plano atual
  • Depois vá em alterar configurações de energia avançadas
  • Vá em gerenciamento de energia do processador
  • Coloque o mínimo e o máximo em 50% (lembre-se, se não estiver conectado na tomada, altere o da bateria).

Confirme no Gerenciador de tarefas, ou no CPU-Z, que a velocidade do clock diminuiu.

Diminuindo o clock do processador para 50% da sua velocidade. Não espere nunca uma redução de exatos 50%. Poderão sofrer algumas pequenas variações, porque isso depende do processador, do sistema operacional, etc.

 

Note que a velocidade do clock de meu processador caiu para 1.29 Ghz

Perceba que agora minha CPU estará rodando com cerca de metade da força. Como será que isso vai impactar no tempo da minha query?

Minha query saiu de 266ms para 594ms. Um aumento de 123% no consumo de CPU, e tempo da query.

Muito interessante como a velocidade da CPU pode afetar o tempo de execução das consultas. No próximo post vou explicar melhor o que aconteceu e falaremos de outras coisas mais!

Até lá!

Desempenho do Processador x Desempenho do SQL Server – Parte 1

Post 1/3. Este post é parte da série: Desempenho do Processador x Desempenho do SQL Server

A CPU é um dos recursos mais fundamentais, senão o mais fundamental, de um computador. É ali que todos os recursos de um computador são coordenados.  Este é o primeiro post de mais uma série onde vamos aprender conceitos básicos sobre velocidade de CPU e como podemos usar isso para análises simples em consultas de um SQL Server.

Hoje vamos obter um conhecimento fundamental sobre CPU antes de partir para o SQL Server!

Clocks e Hertz

Você já deve estar cansado de ver os termos “2.5 GHz”, “3.0 GHz”, etc. Mas você sabe, de fato, o que eles significam? Embora eu necessite de uma série exclusiva somente para este assunto, é necessário um simples entendimento:

  • Quanto maior este valor, mais rápido as instruções são executadas

Basicamente,  toda CPU tem um “clock“, que é um dispositivo que “liga” e “desliga”  X vezes por segundo.  Cada vez que esse dispositivo “liga”, nós dizemos que houve um “clock tick”, ou, apenas “tick”.  Esse é o valor que você vê nas especificações:

  • Um processador de 1 Hertz (1 Hz) significa que seu clock liga e delisga 1 vez por segundo (1 tick por segundo)
  • 1000 Hertz, são 1000 ticks por segundo. Aqui se pode aplicar as unidades do SI (Sistema Internacional de Medidas) : 1000 Hertz = 1 KHz (Kilo Hertz)
  • 1 milhão de Hertz, ou 1 MHz, significa 1 milhão de ticks por segundo.
  • 2.5 GHz (Giga Hertz) , significa 2.5 x  1 bilhão (Giga), que equivale a 2 bilhões e 500 milhões de vezes por segundo

Uma vez que a velocidade do processador dita quantos ticks temos em um segundo, então, podemos calcular quanto tempo dura um tick. Pode parecer confuso o que eu vou dizer agora, mas é apenas uma questão de lógica, pare e reflita.

Cada tick do clock, leva um tempo fixo. Nenhum tick leva mais ou menos tempo que o outro tick. Então, quanto mais lento o processador,  maior será o tempo de 1 tick.  Pense em números pequenos, que vai ajudar:

  • Em um processador de 2 Hertz (dois ticks por segundo), cada tick leva 500 ms (0.5 segundos)
  • Em um processador de 4 Hertz (quatro ticks por segundo), cada tick leva 250 ms ( 0.250 segundos)
  • Percebeu a fórmula mágica pra calcular o tempo de 1 tick?
    • Tempo de um Tick, em Milssegundos = 1000ms/<Número Hertz>
    • 2.5 MHz = 1000/2500000 = 0,0004 ms (1 tick = 400 nanossegundos)
    • 1.0 MHz = 1000/1000000 = 0,001 (1 tick = 1000 nanossegundos)
    • 2.5 GHz  resulta num tick muuuuuuuuuuuuuuuuuuito pequeno! faça as contas você mesmo!

 

As instruções que um processador pode executar, gastam N ticks (isso porque, grosseiramente falando, cada vez que o clock liga, ele aciona certos circuitos e sincroniza o processador com a placa mãe, etc.) . Isso vai depender de cada processador, e de cada instrução.  A velocidade da CPU dita o tempo de cada instrução:

Em uma cpu fictícia de 2 Hz, uma instrução que gastasse 1 tick, demoraria 500 ms para executar. Uma instrução que custasse dois ticks, levaria 1 segundo. E assim por diante…

Por que saber de tudo isso é importante?

Quando você traz esses conceitos para o sistema operacional, e para os seus programas, como o SQL server, fica fácil entender certas coisas. No caso de uma simples consulta SQL, você tem centenas de milhares de instruções executando.  Por exemplo, uma query como esta:

 

Pode causar a execução de milhares de instruções. Vai depender da quantidade de registros, tamanho, concorrência, etc. A questão é que, no final das contas, tudo se resume ao que a CPU irá fazer, e entender a velocidade do seu processador vai te ajudar a compreender certos “fenômenos” e até planejar melhor seu ambiente. Imagine como esta query seria afetada se o tempo de cada instrução dobrasse…

No próximo  post vou mostrar todos estes conceito na prática, quando você executa uma query no SQL Server!

Até lá!

UPDATE: Obrigado ao Luiz Vitor pelas indicações de correção no texto!
UPDATE 2: Muito obrigado José Diz pelas dicas, principalmente sobre o sistema internacional de medidas!