Autor Rodrigo Crespi
No último treinamento de SQL Server Internals realizado pela CrespiDB, falamos sobre Scheduling e discutimos muito sobre Priority Boost. Sendo assim, decidimos 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 Priority Boost como ficará no procexp:
Conferindo no procexp64 a prioridade já esta como alta.
Então devo ativar o Priority Boost?
A resposta é depende. Se respondermos a esta pergunta cegamente diremos 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 quando devo habilitar o Priority Boost? Não há resposta fechada. Já nos deparamos com algumas documentações de ERPs que dizem para habilitar esta opção e “todas as vezes”, infelizmente, tivemos que desabilitar posteriormente, pois juntando algumas queries com hash join acontecia blue screen.
Nossa dica é antes de mexer neste parâmetro considere os pontos aqui apresentados e faça alguns benchmarks. Não há milagres, mas sim uma análise detalhada antes de usar essa opção.
… era isso PessoALL!
Ficam as dicas e a “pulga atrás da orelha”. 
Abraço, Rodrigo.
Sugestão de leituras:
https://docs.microsoft.com/en-us/windows/win32/procthread/priority-boosts
