Na última quarta-feira (29/06/2016) tive a oportunidade de apresentar o tema que gosto bastante: CPU. A apresentação “SQL Server: CPU Foundations” foi bem legal e apesar de ter falhado em umas das demos, gostei bastante.
Os scripts podem ser baixados no link https://drive.google.com/open?id=0B9MFBfb3HCHXNG9TM2pwcW1ILTg
A demo que falhou
Há uma demo nesta apresentação cujo o objetivo é demonstrar como é possível ter valores de CPU acima de 100%. Nesta demo, o SQL Server é configurado para rodar somente nas CPUs 2 e 3, além de abrir duas sessões que executam uma query que causa o uso de 100% de CPU. O que se espera é ver o processo do SQL Server consumindo duas CPUs em 100%, uma em cada sessão, e causando os 200% de CPU no perfmon.
Porém, ao realizar esta demonstração, o SQL Server jogava as sessões apenas em uma CPU. Após analisar esse comportamento com mais calma, eu notei um detalhe que havia esquecido de considerar ao realizá-la: Os schedulers. Os schedulers são uma espécie de porta para a CPU. O SQL Server usa os schedulers para gerenciar a execução de suas tarefas (workers, pra ser mais exato). Toda tarefa tem um scheduler associado. Baseado em alguns fatores, dentre eles, a carga do schedulers (quantas tarefas já estão “alocadas” no scheduler), o SQL Server escolhe em qual scheduler a task vai rodar. Se duas tasks estão configuradas para rodar no mesmo scheduler, então, essas tasks podem acabar na mesma CPU.
E era isso o que ocorreu na demonstração. Os scripts acima contém os detalhes de como reproduzir a demo que falhou e contornar quando o SQL Server tentar alocar as duas conexões no mesmo scheduler.
Obrigado!
[]’s
Rodrigo Ribeiro Gomes
DBA Team Leader na Power Tuning