No último treinamento de SQL Server Internals realizado pela CrespiDB, falamos sobre Scheduling e discutimos muito sobre Priority Boost. Sendo assim, decidi postar um material complementar aqui.
É importante começar este post, lembrando que esta é uma opção disponível apenas para o SQL Server instalado em Windows, ou seja, em sistemas operacionais Linux esta opção não permite alteração. Veja abaixo a imagem e retorno de erro:
Verdade seja dita, no Windows essa opção faz mais sentido. O Windows Server possui 32 níveis de prioridade isso é uma maneira de privilegiar threads que estão na fila.
Para compreender a intimidade do thread scheduling do Windows recomendo o livro Windows Internals 5ª edição.
Retornando ao assunto, há uma classificação desses níveis em 3 partes onde o nível 0 é para o sistema e utilizado para página de controle. Já do nível 1 até o 15 são níveis variáveis e do nível 16 ao 31 são os níveis real-time.
Vide imagem abaixo extraída do livro Windows Internals 5ª edição.
A imagem acima nos deixar empolgados a alterar esta opção, mas é importante compreender que quando o SQL Server estiver com o Priority Boost desligado, ou seja, valor igual a 0 ele irá trabalhar com a prioridade base 8. Ao ligar esta opção definindo-a para 1 você irá privilegiar o SQL Server e levando assim o nível de prioridade para 13. Veja a imagem abaixo do procexp64:
… e se configurarmos no SQL Server o Boost Priority como ficará no procexp64?
Conferindo no procexp64 a prioridade já esta como alta.
Crespi devo ativar o Priority Boost?
A resposta é depende. Se eu responder a esta pergunta cegamente irei dizer não.
Primeiro vamos definir prioridade segundo o dicionário Oxford. Para a língua portuguesa prioridade é a condição do que é primeiro em tempo, ordem ou dignidade.
Exemplificando:
Se você tiver um processo de cluster rodando, ele deixará o lugar ou irá compartilhar o lugar em prioridade com o SQL Server. Isso pode não ser uma boa ideia!
Imagine que no servidor do SQL Server você está rodando o SSIS, não será desejável que o sqlservr.exe tome todos os recursos de processamento quando estamos executando aquela carga de dados, certo?
No entanto, imagine que o seu servidor só roda o SQL Server, nada mais além do básico, ou seja, Windows Core e o SQL Server. Como o SQL Server não tem com o que competir você poderá ter alguma vantagem. Correto? Não! Errado.
Se o processo do SQL Server não tem com o que competir, perde-se o sentido de prioridade. Além de que, alguns recursos básicos do Windows podem ser impedidos de serem executados por falta de recursos, como drivers e outros.
… então Crespi, quando devo habilitar o Priority Boost?
Desde a versão 7 tento descobrir isso. Já me deparei com algumas documentações de ERPs que dizem para habilitar esta opção e todas as vezes que me deparei com esta opção, tive que posteriormente desabilitar, pois juntando algumas queries com hash join acontecia blue screen.
Minha dica antes de mexer neste parâmetro é considerar os pontos que apresentei neste post e fazer alguns benchmarks. Não há milagres, mas sim uma análise detalhada antes de usar essa opção.
… era isso PessoALL!
Abraço, Rodrigo
Sugestão de leituras:
https://www.microsoftpressstore.com/articles/article.aspx?p=2233328&seqNum=7
https://docs.microsoft.com/en-us/windows/win32/procthread/priority-boosts
Excelente post!
Bem esclarecedor e objetivo.
Obrigado por compartilhar.
👍🏻