Questão simples

Como o SQL Server Quantum (4 ms) é sincronizado com o Server OS Quantum (normalmente: 187,5 ms)?

Pergunta simples explicada

Após 184 ms de quantum do SO sendo usado (o que corresponde a 46 quantum SQL completos), o quantum do SO tem 3,5 ms de tempo antes de ter que passar o cronograma para um processo diferente. O SQL OS inicia um quantum (4 ms) e após 3,5 ms, o quantum do SO decidiu parar o encadeamento atual do SQL OS que ainda possui 0,5 ms antes de produzir o cronograma. O que acontece agora?

---

Mergulho Profundo no OS Quantum

Nas próximas seções, escreverei o que encontrei até agora sobre o quantum do SO e como a duração de um quantum pode ser calculada. A duração de um "quantum" do sistema operacional é baseada em "ticks" e a duração do "tick" em si é baseada no "intervalo do relógio", que normalmente é de 15.625000 ms. Mas deixe-me elaborar um pouco ...

Carraça

No artigo do blog Know Thy Tick, o autor Jim explica os conceitos básicos de intervalos de relógio (também conhecidos como "ticks") e para que servem.

Quando leio algo como "o intervalo do relógio ... para a maioria dos multiprocessadores x86 é de cerca de 15 milissegundos", sou obrigado a determinar o valor do meu relógio, ou "tick", intervalo. Felizmente, o livro em que li esta citação, Windows Internals Fourth Edition fornece uma referência para me ajudar com minha aflição. ... O autor, Mark Russinovich, do livro mencionado, graciosamente disponibilizou o utilitário ClockRes disponível em seu site. Executando este utilitário, eu pude determinar que o intervalo do relógio no meu PC com multiprocessador x86 é de 15.625000 ms. Interessante, mas minha mente curiosa quer saber mais.

Quantum

O autor do artigo continua explicando em seu segundo artigo aquele...

Obviamente, a verdadeira razão pela qual o intervalo de tick é importante é que ele afeta o agendamento de threads . O agendador do Windows fornece a cada thread um "quantum" de tempo para executar antes de permitir que outra tarefa, no mesmo nível de prioridade, seja executada. O quantum que o planejador atribui a um encadeamento é um múltiplo do intervalo de tick . O valor quântico específico escolhido para um segmento específico está um pouco além do que eu quero ir com este artigo.

Ok, então eu sei o que é um quantum, mas não por quanto tempo ele será executado.

Por enquanto, vamos apenas examinar o valor quântico padrão para um encadeamento em primeiro plano no XPe. Nesse caso, o agendador do Windows atribui um quantum de 18 ou 6 intervalos de tick. (Sim, para converter quantum em intervalos de tick, é necessário dividir por 3. ..., mas a razão para o múltiplo é permitir ao agendador a capacidade de "cobrar" um encadeamento por executar uma operação que faz com que seja suspenso.)

Agora sabemos que um intervalo de relógio (tick) deve estar em torno de 15,625000 ms e em um sistema operacional Windows Desktop em que o quantum padrão é 18, o que resultará em 6 ticks ou 93,750000 ms (18/3 * 15,625000 ms).

Em um sistema operacional Windows Server, o quantum padrão é diferente. A configuração "Programação do processador" está definida como "Serviços em segundo plano"

^{Essa configuração pode ser encontrada em "Configurações do sistema | Avançadas (guia) | Desempenho (seção) | Configurações ...", que abrirá "Opções de desempenho | Avançadas (guia) | Programação do processador"}

As configurações quânticas padrão são 36 (Plano de fundo) a 36 (Primeiro plano). O quantum é maior e, portanto, mais longo. Isso é o dobro da quantidade de 93,7500000000 da configuração quântica de primeiro plano de 18 (6 tick) em um sistema operacional Windows, que em um sistema operacional de servidor configurado para os Serviços de segundo plano é de cerca de 187.500000 ms.

Observação / Explicação

Quando você altera a configuração de "Serviços em segundo plano" para "Aplicativos" em um servidor ou área de trabalho, a chave HKLM \ SYSTEM \ CurrentControlSet \ Control \ PriorityControl \ Win32PrioritySeparation no registro é alterada de 0x18 para 0x02. Qual é o valor quântico padrão para 0x02? Isso pode ser encontrado em um comentário:

O valor 0x02 implica que os campos "Curto vs. Longo" e "Variável vs. Fixo" são o padrão para o sistema operacional.

O padrão desses campos para o XPe e XP Pro é: Curto e variável, que é o mesmo que ter os seguintes bits adicionais definidos: 0x24.

OR'ing esse valor com 0x02 fornece 0x26, que você encontrará na tabela no artigo.

^{Referência: comentário para "Domine seu Quantum" (Blogs do MSDN)}

A tabela que explica as configurações quânticas do mesmo artigo:

Win32PrioritySeparation   Foreground   Background
0x28, 0x29, 0x2A                  18           18
0x18, 0x19, 0x1A                  36           36
0x24                               6            6
0x25, 0x14                        12            6
0x26                              18            6
0x15                              24            6
0x16                              36            6

Breve resumo do OS Quantum

Com base nas informações acima e nas citações de artigos, sabemos que um quantum não é um tamanho fixo, mas sim derivado de uma configuração de SO nas Propriedades do Sistema. Um quantum varia dependendo da Win32PrioritySeparationconfiguração no registro, que normalmente corresponde a uma das configurações nas "Propriedades do sistema" ("Serviços em segundo plano" ou "Aplicativos").

Um quantum no nível do SO é

• para a configuração "Aplicativos"
  • 18 (que são 6 ticks) para aplicativos em primeiro plano (93,75 ms)
  • 6 (que são 2 ticks) para aplicativos em segundo plano (31,25 ms)
• para a configuração "Serviços em segundo plano"
  • 36 (que são 18 ticks) para aplicativos em primeiro plano (187,5 ms)
  • 36 (que são 18 ticks) para aplicativos em segundo plano (187,5 ms)

Então agora sabemos que um quantum de SO em uma instalação do Windows Server a ser otimizado para os Serviços de Segundo Plano é ...

36 / 3 * 15.625000 ms = 187.5 ms

---

SQL OS Quantum

Esta seção lista o que encontrei no quantum do SQL OS ...

Tipo de espera SOS_SCHEDULER_YIELD

Da descrição de Paul Randall no tipo de espera SOS_SCHEDULER_YIELD:

Esse tipo de espera é quando um segmento é capaz de executar seu quantum de segmento completo (4 milissegundos em todas as versões do SQL Server, imutável ) e, portanto, gera voluntariamente o agendador, movendo-se para a parte inferior da Fila Runnable em seu agendador.

^{Referência: SOS_SCHEDULER_YIELD (tipos de espera do SQLSkills.com)}

Agendadores em DMVs do SQL Server

Em uma explicação sobre as DMVs do SQL Server para a DMV sys.dm_os_schedulers.

[...] O Windows usa um mecanismo de agendamento preventivo e atribui um quantum de tempo de CPU a cada thread, quando um thread consome seu quantum, ele é enviado para uma fila e outros threads recebem execução.

Por outro lado, o SQL Server usa um mecanismo de agendamento cooperativo quando os segmentos podem voluntariamente render seu quantum de tempo (você pode ver esse comportamento quando tiver um tipo de espera SOS_SCHEDULER_YIELD). Isso permite que o SQL Server otimize a utilização da CPU, porque quando um segmento é sinalizado para execução, mas não está pronto para ser executado, pode render seu quantum de tempo em favor de outros segmentos .

^{Referência: Noções básicas sobre agendadores, trabalhadores e tarefas do SQL Server (MSSQLTips.com)}

Detectar a pressão da CPU do SQL Server

Esta é uma seção muito pequena de um artigo sobre pressão da CPU no SQL Server.

Ocorre quando uma tarefa produz voluntariamente o planejador para que outras tarefas sejam executadas. Durante essa espera, a tarefa aguarda a renovação do seu quantum .

^{Referência: Detectar Pressão da CPU do SQL Server (MSSQLTips.com)}

sys.dm_os_schedulers (Microsoft Docs)

Acho que a citação a seguir é o trecho de informação mais importante sobre o quantum do SQL OS que eu pude encontrar:

quantum_length_us bigint  Identified for informational purposes only. 
                          Not supported. Future compatibility is not guaranteed. 
                          Exposes the scheduler quantum used by SQLOS.

^{Referência: sys.dm_os_schedulers (Transact-SQL) (Microsoft | Docs)}

---

My Conundrum

O Server OS Quantum regula quanto tempo o Serviço SQL Server é concedido para executar "tarefas". O SQL Server OS Quantum é definido como 4 ms. Se eu dividir os 187,5 ms por 4 ms, ficarei com 3,5 ms.

E ainda nem começamos a discussão sobre quando o Clock Interval está definido como algo diferente do padrão de 15.625000 ms ....

Questão simples

Como o SQL Server Quantum (4 ms) é sincronizado com o Server OS Quantum (normalmente: 187,5 ms)?

Pergunta simples explicada

Após 184 ms de quantum do SO sendo usado (o que corresponde a 46 quantum SQL completos), o quantum do SO tem 3,5 ms de tempo antes de ter que passar o cronograma para um processo diferente. O SQL OS inicia um quantum (4 ms) e após 3,5 ms, o quantum do SO decidiu parar o encadeamento atual do SQL OS que ainda possui 0,5 ms antes de produzir o cronograma. O que acontece agora?

Mesmo que o agendador não seja preventivo, o agendador do SQL Server ainda segue um conceito de quantum. Em vez das tarefas do SQL Server serem forçadas a desistir da CPU pelo sistema operacional, elas podem solicitar que sejam colocadas em uma fila de espera periodicamente e, se excederem o quantum de 4 milissegundos definido internamente e não estiverem no meio de uma operação que não pode ser parado, eles renunciam voluntariamente à CPU.

- " Microsoft SQL Server 2012 Internals ", Kalen Delaney et. al. pp38

-Capítulo 2 "O SQLOS" Jonathan Kehayias

Portanto, a noção de "quantum" dentro do SQL Server é mais uma "diretriz" para tarefas de programação. IE, quando você escreve uma tarefa, como, por exemplo, uma tarefa que executa uma varredura de tabela, se você não encontrar nenhuma trava de página, trava de IO ou bloqueio aguardando um pouco, pare o que está fazendo e peça para ser recolocar na fila executável, caso haja outras tarefas aguardando.

Mas cabe ao programador de tarefas implementar isso, e pode não ser exatamente 4ms para cada tipo de tarefa. Por exemplo, a tarefa de verificação de tabela pode usar uma heurística simples com base no número de páginas digitalizadas para implementar os pontos de rendimento.

tão

O SQL OS inicia um quantum (4 ms) e após 3,5 ms, o quantum do SO decidiu parar o encadeamento atual do SQL OS que ainda possui 0,5 ms antes de produzir o cronograma. O que acontece agora?

Se o encadeamento do SQL Server for antecipado pelo Windows enquanto uma tarefa estiver em execução, ele será pausado e, quando o encadeamento for agendado em uma CPU, ele continuará de onde parou. Presumivelmente, ele continuará consumindo o equilíbrio de seus 4ms quânticos, pois não saberia nenhuma diferença. Porém, novamente, o comportamento do rendimento é um detalhe de implementação da tarefa, não um comportamento do SQLOS; portanto, tarefas diferentes podem se comportar de maneira diferente aqui.

_{Responda as contribuições originalmente deixadas como comentários}

Como o SQL Server Quantum (4 ms) é sincronizado com o Server OS Quantum (normalmente: 187,5 ms)?

Não é e o SQL Server não usa agendamento de preferência. Espera-se que os itens de trabalho atinjam pontos de rendimento e, se não, obtém itens como NONYIELDINGagendadores. Não há paridade. O SQL Server não distribui o tempo. Isso torna certos threads atraentes para o Windows agendá-los e agendá-los. Quantum é apenas nomenclatura por um tempo. É isso aí. O SQL Server não é preventivo, é responsabilidade do que estiver executando para render-se por todo o código. - Sean Gallardy

Quando o quantum do SO expira, o encadeamento é fortemente desmarcado. Isso é transparente para o SQL Server. O SQLOS não tem como detectar quando isso acontece. Não há API Win32 para isso. O agendamento é transparente para os threads do modo de usuário. O agendador do Windows não sabe ou se importa com o que os threads do modo de usuário estão fazendo. O Windows vê apenas threads executáveis ​​e permite que eles sejam executados até o final do quantum do SO ou até serem bloqueados. - usr

Em Como lidar com valores excessivos de tipo de espera SOS_SCHEDULER_YIELD no SQL Server por Nikola Dimitrijevic, o termo "quantum" é usado para significar essencialmente "o tempo que uma tarefa realmente passa atribuído a um trabalhador", mas esse não é o mesmo sentido que um quantum do Windows, que é um período de tempo após o qual o sistema operacional removerá um thread de uma CPU. Eles são apenas conceitos diferentes. Se o SO forçar um encadeamento para finalizar a execução porque o quantum do SO foi atingido, uma troca de contexto acontece. O encadeamento do SQL Server está suspenso, como qualquer outro programa. - David Browne - Microsoft e George.Palacios .

---

Extrai da documentação: Dentro do Agendador do Modo de Usuário do SQL Server 2000 (escrito para o SQL Server 2000, mas ainda relevante):

Tarefas preventivas vs. cooperativas

O UMS, por outro lado, conta com threads para render voluntariamente. O UMS adota a abordagem adotada para não envolver o kernel do Windows mais do que o absolutamente necessário. Em um sistema em que se pode contar com os encadeamentos de trabalho, quando necessário, um agendador cooperativo pode ser realmente mais eficiente que um preventivo, porque o processo de agendamento pode ser adaptado às necessidades específicas do aplicativo. Como eu disse anteriormente, o UMS conhece as necessidades de agendamento do SQL Server melhor do que o sistema operacional pode ser esperado.

Como o UMS assume o agendamento

Se o UMS deve lidar com as necessidades de agendamento do SQL Server, em vez de permitir que o Windows faça isso, o UMS deve, de alguma forma, impedir que o sistema operacional faça o que faz com todos os outros processos: agendar threads dentro e fora do (s) processador (es) do sistema, conforme entender. Como você faz isso em um sistema operacional preventivo? O UMS realiza isso com alguns truques inteligentes com objetos de evento do Windows. Cada segmento no UMS possui um objeto de evento associado. Para fins de agendamento, o Windows ignora os segmentos que não considera viáveis ​​- segmentos que não podem ser executados porque estão em um estado de espera infinito. Sabendo disso, o UMS coloca em suspensão os threads que não deseja que sejam agendados, chamando WaitForSingleObject em seu objeto de evento correspondente e passando INFINITE para o valor do tempo limite.

Para impedir o Windows de agendar vários threads no mesmo processador e, assim, incorrer na sobrecarga e nas despesas das alternâncias de contexto, o UMS tenta manter viável apenas um thread - ou seja, não em um estado de espera infinito - por processador.