ARQUITETURA SQL Server Parte 3: O SQLOS Scheduler


Quando o SQL Server inicia o seu serviço, um scheduler é reservado para cada processador lógico visível para a instância do SQL Server.

Um scheduler controla a execução das requisições dos usuários (SPIDs ou session IDs). O scheduler não substitui o scheduler do Windows, mas gerencia a execução das requisições sem retornar o controle para ele, e isto diminui significativamente as trocas de contexto. O scheduler opera de modo não preemptivo, ou seja, são as requisições que têm a obrigação de devolver o controle para o scheduler quando seu tempo de CPU expirou ou são suspensas.

O scheduler provê mecanismos para a execução de I/Os assíncronos. Quem inicia a operação de I/O é o scheduler, mas cabe a qualquer thread que está deixando o processador (yielding) verificar se algum I/O já foi completado (I/O completion routine). Isto significa que nem sempre a thread que iniciou o I/O é que vai completar esta operação, e é isto que evita a troca de contexto.

Mais informações relacionadas ao SQL Server e IO no link abaixo:




O scheduler ajuda de forma que uma tarefa precisa aguardar por um recurso, a thread em execução é removida do scheduler e colocada em uma lista de espera até o recurso esteja disponível novamente. Isso garante que outras tarefas terminem seu trabalho ao invés de serem bloqueadas atrás de outra aguardando por um recurso, como um “lock” ou IO de disco para completar.

Uma tarefa no SQLOS é uma unidade de execução que é associada a uma thread ou fibra. É a thread que é associada a CPU para executar. A fibra é mais leve em sua execução o que ajuda a reduzir o custo das trocas de contexto.

No SQL Server 2005, houve uma mudança drástica quanto ao agendamento das tarefas. No SQL Server 2000, o número máximo de threads que podia ser criada para atender requisições de usuários, como definido no parâmetro “max worker threads”, era de 255 (em casos muito raros este valor poderia ser aumentado, como em instâncias rodando sob o IA-64).A partir do SQL Server 2005, este número passou a ser calculado automaticamente (o valor de “max worker threads” fica definido como 0) quando a instância é iniciada, com base na arquitetura e no número de processadores lógicos que estão visíveis.

Para sistemas x86 com 4 ou menos processadores, o SQL Server inicia com 256 threads associadas através dos schedulers, para cada CPU adicional sobre 4 o SQL adiciona 8 threads extras. A fórmula para calcular o valor do parâmetro é:


Maximum worker threads = (256+ (<processors> -4) * 8)


Para sistemas x64 com 4 ou menos processadores, o SQL Server inicia com 512 threads, para cada CPU adicional sobre 4 o SQL adiciona 16 thread extras. A fórmula para calcular o valor do parâmetro é:


Maximum worker threads = (512+ (<processors> -4) * 16)



O link abaixo tem o resultado destes cálculos:




Outra melhoria que o SQLOS trouxe com o SQL Server 2005 foi a afinidade das CPU’s. A mesma é dinâmica e você pode configura-la a qualquer momento, sem precisar reiniciar os serviços do SQL Server para que a alteração seja de fato efetivada. O parâmetro para configurar a afinidade das CPU’s se chama “affinity mask”, veja informações sobre ele no link abaixo:




A partir do SQL SERVER 2008 R2 e acima, podemos utilizar o ALTER SERVER CONFIGURATION para realizar certas alterações na instancia, como por exemplo a que acabamos de citar, de afinidade das CPU’s, mais informações no link abaixo:




O SQLOS balanceia a carga de trabalho entre os schedulers baseado no número de tarefas ativas associadas a cada um deles. Isso evita o problema que o SQL Server 2000 enfrentava de sobrecarga em alguns schedulers, enquanto outros estavam ociosos, era um balanceamento chamado de “round-robin”.


Espero que tenham gostado do post e até a próxima!

Nenhum comentário:

Postar um comentário