{"id":1086,"date":"2019-02-27T22:38:45","date_gmt":"2019-02-28T01:38:45","guid":{"rendered":"http:\/\/thesqltimes.com\/blog\/?p=1086"},"modified":"2019-03-01T23:50:29","modified_gmt":"2019-03-02T02:50:29","slug":"desempenho-do-processador-x-desempenho-do-sql-server-parte-3","status":"publish","type":"post","link":"https:\/\/thesqltimes.com\/blog\/2019\/02\/27\/desempenho-do-processador-x-desempenho-do-sql-server-parte-3\/","title":{"rendered":"Desempenho do Processador x Desempenho do SQL Server \u2013 Parte 3"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n <\/span>\r\n<\/div><\/div>
Post 3\/4. Este post \u00e9 parte da s\u00e9rie: Desempenho do Processador x Desempenho do SQL Server<\/a>\r\n<\/div>\r\nTempo de Leitura:<\/span> 6<\/span> minutos<\/span><\/span>

S\u00e3o 7 horas da manh\u00e3, e recebo uma liga\u00e7\u00e3o da Equipe de BI, dizendo que todas as cargas est\u00e3o 50% mais lentas. O caos se instaura na equipe, pois os relat\u00f3rios do dia n\u00e3o estariam prontos…<\/p>\n

Isso aconteceu depois de uma migra\u00e7\u00e3o. A m\u00e1quina antiga era virtual. A m\u00e1quina nova? F\u00edsica. Com configura\u00e7\u00f5es id\u00eanticas! Como pode? O m\u00ednimo, era ter desempenho igual, n\u00e3o inferior. O que aconteceu?<\/p>\n

Vou contar melhor essa hist\u00f3ria…<\/p>\n

\n

Bem vindo de volta!<\/p>\n

No \u00faltimo post desta s\u00e9rie, voc\u00ea viu como uma redu\u00e7\u00e3o de 50% no clock da CPU impactou diretamente no tempo das consultas de um SQL Server.<\/p>\n

Se voc\u00ea ficou surpreso com isso, saiba que n\u00e3o tem nada de novo. Isso se d\u00e1 por uma simples teoria matem\u00e1tica:\u00a0velocidade e tempo s\u00e3o grandezas inversamente proporcionais. Se eu dobrar a velocidade, eu fa\u00e7o na metade do tempo. Do mesmo jeito que, se eu usar metade da velocidade, eu gasto o dobro do tempo.<\/p>\n

E, foi exatamente isso que aconteceu no exemplo o post anterior: a velocidade da CPU diminui, e o tempo das instru\u00e7\u00f5es, e, consequentemente, da nossa query, aumentou.<\/p>\n

Mas por que voc\u00ea se preocuparia com isso? Afinal, quem seria louco o suficiente para baixar a velocidade da CPU pelo gerenciamento de energia? E \u00e9 a\u00ed que voltamos a nossa historinha…<\/p>\n

Um caso real e inesquec\u00edvel<\/h2>\n

Que absurdo \u00e9 esse, onde, uma m\u00e1quina f\u00edsica, id\u00eantica a virtual (pra ser mais preciso, id\u00eantica ao host da m\u00e1quina virtual), \u00e9 t\u00e3o mais lenta?<\/p>\n

\"\"<\/a><\/p>\n

N\u00f3s gastamos um bom tempo checando tudo, configura\u00e7\u00f5es da inst\u00e2ncia, bloqueios, disco, etc. At\u00e9 que, tive a ideia de fazer um simples teste de CPU: Vou comparar quanto tempo levo pra executar uma quantidade de instru\u00e7\u00f5es na inst\u00e2ncia antiga e na nova. Como fazer isso no SQL Server? Um simples loop:<\/p>\n

DECLARE @i bigint = 10000000, @start datetime = current_timestamp\r\nwhile @i > 0  set @i = @i - 1;\r\nselect datediff(ms,@start,current_Timestamp) as LoopTime<\/pre>\n
Este c\u00f3digo SQL \u00e9\u00a0 muito simples:<\/p>\n
    \n
  1. A vari\u00e1vel @i, come\u00e7a em 10 milh\u00f5es. O meu objetivo \u00e9 decrementar ela at\u00e9 que chegue em zero. O processador vai ser utilizado basicamente para opera\u00e7\u00f5es aritm\u00e9ticas… Que s\u00e3o simples e r\u00e1pidas…<\/li>\n
  2. Eu utilizo a vari\u00e1vel @start para gravar a data e hora atuais, antes de come\u00e7ar o loop WHILE…<\/li>\n
  3. Ao final do meu loop while, eu calculo quanto tempo se passou, subtraindo a data de agora, pelo valor gravado em @Start<\/li>\n<\/ol>\n
    \"\"<\/a><\/p>\n
    Este \u00e9 um c\u00f3digo que vai gastar apenas CPU. N\u00e3o tem disco, rede, mem\u00f3ria, ou outra coisa significativa<\/strong> envolvida.\u00a0 Mais de 99% do tempo desse script vai ser gasto executando instru\u00e7\u00f5es na CPU. Quando eu executei este script na m\u00e1quina antiga, ele me retornou um tempo de 5 segundos. Quando executei na nova, variava de 7 a 8 segundos.<\/p>\n
    \"\"<\/a>
    Comparando tempos de CPU usando T-SQL. O script demora aproximadamente 4 segundos para subtrair 10 milh\u00f5es em uma CPU de 3.1 Ghz! J\u00e1 em uma CPU de 1.39 Ghz, ele leva 10.5 segundo! \ud83d\ude2f \ud83d\ude2f \ud83d\ude2f \ud83d\ude2f<\/figcaption><\/figure>\n
     <\/p>\n
    Pronto, tinha achado um norte. O pr\u00f3ximo passo nesse caso, foi verificar se o problema estava dentro do SQL Server, ou era algo generalizado, no Sistema Operacional. Ent\u00e3o, fiz a mesma vers\u00e3o desse script, em powershell:<\/p>\n
    (Measure-Command {   [int]$i = 10000000;  while($i--){};   }).TotalMilliseconds<\/pre>\n
    E novamente, comparei o resultado com a m\u00e1quina nova e antiga! Mesma situa\u00e7\u00e3o. Agora exclu\u00ed o SQL Server do problema. O script na m\u00e1quina antiga (virtual) retornava um valor muito inferior ao da m\u00e1quina nova(f\u00edsica). A partir da\u00ed, 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\u00e1quina virtual, reportava 2.5 GHz. Uma diferen\u00e7a de apenas 300 MHz, foi suficiente para dar dor da cabe\u00e7a no ambiente de BI!<\/p>\n
    Voc\u00ea pode estar se perguntando o porqu\u00ea de apenas 300 MHz, causar 50% de lentid\u00e3o no processo de carga e a raz\u00e3o \u00e9 muito simples:<\/p>\n