Início / dba / Perguntas / 237749
Accepted
John K. N.
Asked: 2019-05-10 06:40:32 +0800 CST

SO Windows Quantum vs. SO SQL Quantum

  • 772

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 do quantum do SO sendo usado (o que corresponde a 46 quantums SQL completos), o quantum do SO tem 3,5 ms de tempo antes de ter que entregar o agendamento para um processo diferente. O SO SQL inicia um quantum (4 ms) e após 3,5 ms, o quantum do SO decidiu parar o thread atual do SO SQL que ainda tem 0,5 ms antes de produzir o agendamento. 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 sistema operacional "quântico" é baseada em "ticks" e a duração do "tick" em si é baseada no "intervalo de clock" que normalmente é 15,625000 ms. Mas deixe-me explicar um pouco...

Carraça

No artigo do blog Know Thy Tick , o autor Jim explica os fundamentos dos 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 compelido 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 acima mencionado graciosamente disponibilizou o utilitário ClockRes em seu site. Executando este utilitário, consegui determinar que o intervalo de clock no meu PC multiprocessador x86 é de 15,625000 ms. Interessante, mas minha mente curiosa quer saber mais.

Quântico

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

É claro que a verdadeira razão pela qual o intervalo de ticks é importante é que ele afeta o agendamento de threads . O agendador do Windows dá 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 escalonador atribui a um encadeamento é um múltiplo do intervalo de escala . O valor quântico específico escolhido para um segmento específico está um pouco além de onde quero ir com este artigo.

Ok, então eu sei o que é um quantum, mas não quanto tempo um quantum vai durar.

Por enquanto, vamos apenas examinar o valor quântico padrão para um thread de primeiro plano no XPe. Nesse caso, o agendador do Windows atribui um quantum de intervalos de 18 ou 6 ticks. (Sim, para converter quantum em intervalos de ticks, deve-se dividir por 3. ..., mas a razão para o múltiplo é permitir que o escalonador a capacidade de “carregar” um thread para fazer uma operação que faz com que ele seja suspenso.)

Agora sabemos que um intervalo de clock (tick) deve ser em torno de 15,625000 ms e em um sistema operacional Windows Desktop, onde o quantum padrão é 18, isso 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 "Agendamento do processador" está definida como "Serviços em segundo plano"

Essa configuração pode ser encontrada em "Configurações do sistema | Avançado (guia) | Desempenho (seção) | Configurações ..." que abrirá "Opções de desempenho | Avançado (guia) | Agendamento do processador"

As configurações quânticas padrão são, então, de 36 (Background) a 36 (Foreground). O quantum é maior e, portanto, mais longo. Isso é o dobro da quantidade de 93,750000 ms da configuração de primeiro plano quântico de 18 (6 ticks) em um sistema operacional de desktop Windows, que em um sistema operacional de servidor configurado para serviços em 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 SO.

O padrão para esses campos para XPe & XP Pro é: Short & Variable que é o mesmo que ter os seguintes bits adicionais definidos: 0x24.

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

Referência: Comentário para "Domine seu Quantum" (Blogs do MSDN)

A tabela explicando 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 citações de artigos, sabemos que um quantum não é um tamanho fixo, mas sim derivado de uma configuração do sistema operacional nas Propriedades do sistema. Um quantum varia de acordo com a Win32PrioritySeparationconfiguração no registro que normalmente corresponde a uma das configurações nas "Propriedades do sistema" (ou "Serviços em segundo plano" ou "Aplicativos").

Um quantum no nível do SO é

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

Portanto, agora sabemos que um quantum de SO em uma configuração do Windows Server a ser otimizado para serviços em segundo plano é ...

36 / 3 * 15.625000 ms = 187.5 ms

SQL OS Quantum

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

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 encadeamento foi capaz de executar seu quantum de encadeamento completo (4 milissegundos em todas as versões do SQL Server, imutável ) e, assim, voluntariamente cedeu o agendador, movendo-se para a parte inferior da Fila Executável em seu agendador.

Referência: SOS_SCHEDULER_YIELD (tipos de espera SQLSkills.com)

Agendadores em DMVs do SQL Server

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

[...] o Windows usa um mecanismo de agendamento preemptivo 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.

Em oposição, o SQL Server usa um mecanismo de agendamento cooperativo quando os threads 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, pois quando um thread é sinalizado para execução, mas não está pronto para ser executado, ele pode render seu quantum de tempo em favor de outros threads .

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

Detectar pressão da CPU do SQL Server

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

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

Referência: Detectar pressão de CPU do SQL Server (MSSQLTips.com)

sys.dm_os_schedulers (Documentos da Microsoft)

Acho que a citação a seguir é o trecho mais importante de informações sobre o quantum do SQL OS que 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)

Meu enigma

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

E ainda nem começamos a discussão de quando o Intervalo do Relógio está definido para 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 do quantum do SO sendo usado (o que corresponde a 46 quantums SQL completos), o quantum do SO tem 3,5 ms de tempo antes de ter que entregar o agendamento para um processo diferente. O SO SQL inicia um quantum (4 ms) e após 3,5 ms, o quantum do SO decidiu parar o thread atual do SO SQL que ainda tem 0,5 ms antes de produzir o agendamento. O que acontece agora?

sql-server

2 respostas

  1. Best Answer

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

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

    -Capítulo 2 "O SQLOS" Jonathan Kehayias

    Portanto, a noção de um "quântico" dentro do SQL Server é mais uma "diretriz" para tarefas de programação. IE quando você escreve uma tarefa, como digamos, uma tarefa que executa uma varredura de tabela, se você não acertar nenhuma trava de página, trava de E/S ou travar espera por um tempo, você deve parar o que está fazendo e pedir para ser colocado de volta na fila executável, caso haja outras tarefas esperando.

    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 baseada no número de páginas verificadas para implementar os pontos de rendimento.

    Então

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

    Se o thread do SQL Server for impedido pelo Windows enquanto uma tarefa estiver em execução, ele será pausado e, quando seu thread for agendado em uma CPU, ele continuará de onde parou. Presumivelmente, continuará consumindo o saldo de seu quantum de 4ms, pois não conheceria nenhuma diferença. Mas, novamente, o comportamento de rendimento é um detalhe de implementação da tarefa, não um comportamento do SQLOS, portanto, tarefas diferentes podem se comportar de maneira diferente aqui.

    • 14

  2. Responda às contribuições deixadas originalmente 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 preventivo. Espera-se que os itens de trabalho atinjam os pontos de rendimento e, se não atingirem, você obtém coisas como NONYIELDINGagendadores. Não há paridade. O SQL Server não distribui o tempo. Isso torna certos threads atraentes para o Windows agendar e o Windows os agenda. Quantum é apenas nomenclatura por um tempo. É isso. O SQL Server não é preventivo, é responsabilidade de tudo o que está sendo executado para se render em todo o código. – Sean Gallardy

    Quando o quantum do SO expira, o encadeamento é desprogramado com força. 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 encadeamentos 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 sistema operacional ou até que sejam bloqueados. – usr

    Em Como lidar com valores excessivos do 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 gasta atribuído a um trabalhador", mas isso 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. São apenas conceitos diferentes. Se o sistema operacional forçar um thread a encerrar a execução porque o quantum do sistema operacional foi atingido, ocorre uma troca de contexto. A thread do SQL Server está suspensa, assim como qualquer outro programa. – David Browne - Microsoft e George.Palacios .

    Extratos da documentação: Inside the SQL Server 2000 User Mode Scheduler (escrito para SQL Server 2000, mas ainda relevante):

    Tarefas preventivas vs. cooperativas

    O UMS, por outro lado, depende de threads para produzir voluntariamente. O UMS adota a abordagem que adota para evitar envolver o kernel do Windows mais do que o absolutamente necessário. Em um sistema em que se pode contar com threads de trabalho para produzir quando deveriam, um escalonador cooperativo pode ser mais eficiente do que um preemptivo porque o processo de escalonamento 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 esperar.

    Como o UMS assume o agendamento

    If UMS is to handle SQL Server's scheduling needs rather than allowing Windows to do so, UMS must somehow prevent the OS from doing what it does with every other process: schedule threads on and off the system's processor(s) as it sees fit. How do you do that in a preemptive OS? UMS pulls this off through some clever tricks with Windows event objects. Each thread under UMS has an associated event object. For purposes of scheduling, Windows ignores threads it does not consider viable—threads that cannot run because they are in an infinite wait state. Knowing this, UMS puts threads to sleep that it does not want to be scheduled by having them call WaitForSingleObject on their corresponding event object and passing INFINITE for the timeout value.

    In order to prevent Windows from scheduling multiple threads on the same processor and thereby incurring the overhead and expense of context switches, UMS attempts to keep just one thread viable—that is, not in an infinite wait state—per processor.

    • 5

relate perguntas