Priority Boost

Priority Boost

30 de julho de 2020 Off Por 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

https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms180943(v=sql.105)?redirectedfrom=MSDN