Domanda semplice

In che modo SQL Server Quantum (4 ms) è sincronizzato con Server OS Quantum (normalmente: 187,5 ms)?

Spiegazione della domanda semplice

Dopo aver utilizzato 184 ms di quantum OS (che corrisponde a 46 quantum SQL completi), il quantum OS ha 3,5 ms di tempo prima di dover consegnare la pianificazione a un processo diverso. Il sistema operativo SQL avvia un quantum (4 ms) e dopo 3,5 ms, il quantum del sistema operativo ha deciso di interrompere l'attuale thread del sistema operativo SQL che ha ancora 0,5 ms prima che producesse la pianificazione. Che succede ora?

---

Deep Dive su OS Quantum

Nelle prossime due sezioni scriverò quello che ho trovato finora riguardo al quantum OS e come può essere calcolata la durata di un quantum. La durata di un "quantum" del sistema operativo si basa su "tick" e la durata del "tick" stesso si basa sull'intervallo di clock, che normalmente è 15.625000 ms. Ma lasciami elaborare un po '...

zecca

Nell'articolo del blog Conosci il tuo tick l'autore Jim spiega le basi degli intervalli di clock (alias "tick") e a cosa servono.

Quando leggo qualcosa del tipo "l'intervallo di clock ... per la maggior parte dei multiprocessori x86 è di circa 15 millisecondi", sono costretto a determinare il valore del mio intervallo, o "tick", intervallo. Fortunatamente, il libro in cui ho letto questa citazione, Windows Internals Fourth Edition fornisce un riferimento per aiutarmi con la mia afflizione. ... L'autore, Mark Russinovich, del suddetto libro ha gentilmente reso disponibile l'utilità ClockRes sul suo sito web. Eseguendo questa utility, sono stato in grado di determinare che l'intervallo di clock sul mio PC multiprocessore x86 è 15.625000 ms. Interessante, ma la mia mente curiosa vuole saperne di più.

quantistico

L'autore dell'articolo continua spiegando nel suo secondo articolo quello...

Naturalmente il vero motivo per cui l'intervallo di tick è importante è che influenza la pianificazione dei thread . Lo scheduler di Windows fornisce a ciascun thread un "quantum" di tempo da eseguire prima di consentire l'esecuzione di un'altra attività, allo stesso livello di priorità. Il quanto assegnato dallo scheduler a un thread è un multiplo dell'intervallo di tick . Il valore quantico specifico scelto per un thread specifico è un po 'oltre il punto in cui voglio andare con questo articolo.

Ok, quindi so cos'è un quantum, ma non per quanto tempo durerà un quantum.

Per ora, esaminiamo solo il valore quantico predefinito per un thread in primo piano in XPe. In questo caso lo scheduler di Windows assegna un quantum di 18 o 6 intervalli di tick. (Sì, per convertire quantum in intervalli di tick, si deve dividere per 3. ..., ma il motivo del multiplo è consentire allo scheduler la possibilità di "caricare" un thread per eseguire un'operazione che lo fa sospendere.)

Ora sappiamo che un intervallo di clock (tick) dovrebbe essere di circa 15.625000 ms e su un sistema operativo desktop Windows in cui il quantum predefinito è 18, ciò comporterà 6 tick o 93.750000 ms (18/3 * 15.625000 ms).

Su un sistema operativo Windows Server il quantum predefinito è diverso. L'impostazione "Pianificazione processore" è impostata su "Servizi in background"

^{Questa impostazione è disponibile tramite "Impostazioni di sistema | Avanzate (scheda) | Prestazioni (sezione) | Impostazioni ..." che aprirà "Opzioni perofrmance | Avanzate (scheda) | Programmazione del processore"}

Le impostazioni quantistiche predefinite sono quindi da 36 (Sfondo) a 36 (Primo piano). Il quanto è più grande e quindi più lungo. Si tratta del doppio della quantità di 93.750000 ms dell'impostazione di primo piano quantico 18 (6 tick) su un sistema operativo desktop Windows, che su un sistema operativo server impostato per i servizi in background è di circa 187.500000 ms.

Osservazione / Spiegazione

Quando si modifica l'impostazione da "Servizi in background" a "Applicazioni" su un server o desktop, la chiave HKLM \ SYSTEM \ CurrentControlSet \ Control \ PriorityControl \ Win32PrioritySeparation nel registro viene modificata da 0x18 a 0x02. Qual è il valore quantico predefinito per 0x02? Questo può essere trovato in un commento:

Il valore 0x02 implica che i campi "Breve vs. Lungo" e "Variabile vs. Fisso" sono quelli predefiniti per il sistema operativo.

L'impostazione predefinita per questi campi per XPe & XP Pro è: Short & Variable, che equivale a impostare i seguenti bit bit aggiuntivi impostati: 0x24.

OPPURE inserire questo valore con 0x02 ti dà 0x26, che troverai nella tabella nell'articolo.

^{Riferimento: commento a "Master Your Quantum" (MSDN Blogs)}

La tabella che spiega le impostazioni quantistiche dello stesso articolo:

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 riepilogo di OS Quantum

Sulla base delle informazioni precedenti e delle citazioni degli articoli, sappiamo che un quanto non è una dimensione fissa, ma piuttosto derivato da un'impostazione del sistema operativo nelle Proprietà del sistema. Un quanto varia in base Win32PrioritySeparationall'impostazione nel registro che normalmente corrisponde a un'impostazione nelle "Proprietà del sistema" ("Servizi in background" o "Applicazioni").

Un quanto a livello di OS è

• per l'impostazione "Applicazioni"
  • 18 (ovvero 6 tick) per le applicazioni in primo piano (93.75 ms)
  • 6 (ovvero 2 tick) per applicazioni in background (31,25 ms)
• per l'impostazione "Servizi in background"
  • 36 (ovvero 18 tick) per le applicazioni in primo piano (187,5 ms)
  • 36 (ovvero 18 tick) per applicazioni in background (187,5 ms)

Quindi ora sappiamo che un quantum del sistema operativo su un'installazione di Windows Server da ottimizzare per i servizi in background è ...

36 / 3 * 15.625000 ms = 187.5 ms

---

Quantum del sistema operativo SQL

Questa sezione elenca ciò che ho trovato sul quantum del sistema operativo SQL ...

SOS_SCHEDULER_YIELD Tipo di attesa

Dalla descrizione di Paul Randall sul tipo di attesa SOS_SCHEDULER_YIELD:

Questo tipo di attesa è quando un thread è stato in grado di eseguire per il suo quantum di thread completo (4 millisecondi in tutte le versioni di SQL Server, immutabile ), e così ha prodotto volontariamente lo scheduler, spostandosi in fondo alla coda eseguibile nel suo scheduler.

^{Riferimento: SOS_SCHEDULER_YIELD (Tipi di attesa di SQLSkills.com)}

Utilità di pianificazione nei DMV di SQL Server

In una spiegazione sui DMV di SQL Server per il DMV sys.dm_os_schedulers.

[...] Windows utilizza un meccanismo di pianificazione preventiva e assegna un quantum di tempo CPU a ogni thread, quando un thread consuma il suo quantum viene inviato a una coda e altri thread vengono eseguiti.

Al contrario, SQL Server utilizza un meccanismo di pianificazione cooperativa quando i thread possono cedere volontariamente il suo quantum di tempo (puoi vedere questo comportamento quando hai un tipo di attesa SOS_SCHEDULER_YIELD). Ciò consente a SQL Server di ottimizzare l'utilizzo della CPU, poiché quando un thread viene segnalato per l'esecuzione ma non è pronto per l'esecuzione, può produrre il suo quantum di tempo a favore di altri thread .

^{Riferimento: informazioni sugli scheduler, i lavoratori e le attività di SQL Server (MSSQLTips.com)}

Rileva la pressione della CPU di SQL Server

Questa è una sezione molto piccola di un articolo riguardante la pressione della CPU in SQL Server.

Si verifica quando un'attività restituisce volontariamente lo scheduler per l'esecuzione di altre attività. Durante questa attesa il compito è in attesa del rinnovo del suo quanto .

^{Riferimento: Rileva la pressione della CPU di SQL Server (MSSQLTips.com)}

sys.dm_os_schedulers (Microsoft Docs)

Immagino che la seguente citazione sia il frammento più importante di informazioni sul quantum del sistema operativo SQL che sono riuscito a trovare:

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

^{Riferimento: sys.dm_os_schedulers (Transact-SQL) (Microsoft | Docs)}

---

Il mio enigma

Il sistema operativo server Quantum regola quanto tempo viene concesso al servizio SQL Server per eseguire "attività". Il sistema operativo SQL Server Quantum è definito come 4 ms. Se divido i 187,5 ms per 4 ms, allora rimango con 3,5 ms.

E non abbiamo nemmeno iniziato la discussione su quando l'intervallo di clock è impostato su un valore diverso da quello predefinito di 15,625000 ms ....

Domanda semplice

In che modo SQL Server Quantum (4 ms) è sincronizzato con Server OS Quantum (normalmente: 187,5 ms)?

Spiegazione della domanda semplice

Dopo aver utilizzato 184 ms di quantum OS (che corrisponde a 46 quantum SQL completi), il quantum OS ha 3,5 ms di tempo prima di dover consegnare la pianificazione a un processo diverso. Il sistema operativo SQL avvia un quantum (4 ms) e dopo 3,5 ms, il quantum del sistema operativo ha deciso di interrompere l'attuale thread del sistema operativo SQL che ha ancora 0,5 ms prima che producesse la pianificazione. Che succede ora?

Anche se lo scheduler non è preventivo, lo scheduler di SQL Server aderisce ancora al concetto di un quanto. Più di quanto le attività di SQL Server siano costrette a rinunciare alla CPU dal sistema operativo, possono richiedere di essere messe periodicamente in coda di attesa e se hanno superato il quantum di 4 millisecondi definito internamente e non sono nel mezzo di un'operazione che non può essere fermato, abbandonano volontariamente la CPU.

- " Interni di Microsoft SQL Server 2012 ", Kalen Delaney et. al. PP38

-Capitolo 2 "The SQLOS" Jonathan Kehayias

Quindi la nozione di "quantum" all'interno di SQL Server è più una "linea guida" per le attività di programmazione. IE quando si scrive un'attività, come ad esempio un'attività che esegue una scansione di tabella, se non si preme alcun latch di pagina, IO latch o blocco in attesa per un po ', è necessario interrompere ciò che si sta facendo e chiedere di essere rimettere sulla coda eseguibile, nel caso ci siano altre attività in attesa.

Ma spetta al programmatore delle attività implementarlo e potrebbe non essere esattamente 4ms per ogni tipo di attività. Ad esempio, l'attività di scansione delle tabelle potrebbe utilizzare una semplice euristica basata sul numero di pagine scansionate per implementare i punti di snervamento.

Così

Il sistema operativo SQL avvia un quantum (4 ms) e dopo 3,5 ms, il quantum del sistema operativo ha deciso di interrompere l'attuale thread del sistema operativo SQL che ha ancora 0,5 ms prima che producesse la pianificazione. Che succede ora?

Se il thread di SQL Server viene preceduto da Windows mentre è in esecuzione un'attività, verrà messo in pausa e quando il thread verrà successivamente programmato su una CPU, continuerà da dove era stato interrotto. Presumibilmente continuerà a consumare l'equilibrio del suo quantico di 4 ms, in quanto non conoscerebbe alcuna differenza. Ma ancora una volta, il comportamento alla resa è un dettaglio dell'implementazione dell'attività, non un comportamento di SQLOS, quindi attività diverse potrebbero comportarsi diversamente qui.

_{I contributi di risposta inizialmente lasciati come commenti}

In che modo SQL Server Quantum (4 ms) è sincronizzato con Server OS Quantum (normalmente: 187,5 ms)?

Non lo è e SQL Server non utilizza la pianificazione preventiva. Ci si aspetta che gli oggetti di lavoro raggiungano punti di snervamento e, in caso contrario, si ottengono cose come gli NONYIELDINGscheduler. Non c'è parità. SQL Server non distribuisce il tempo. Rende certi thread interessanti per Windows da pianificare e Windows li pianifica. Quantum è solo nomenclatura per un periodo di tempo. Questo è tutto. SQL Server non è preventivo, è responsabilità di tutto ciò che è in esecuzione per cedere a se stesso in tutto il codice. - Sean Gallardy

Quando il quantum OS scade, il thread viene riprogrammato con forza. Questo è trasparente per SQL Server. SQLOS non ha modo di rilevare quando ciò accade. Non esiste un'API Win32 per questo. La pianificazione è trasparente per i thread in modalità utente. Lo scheduler di Windows non sa né si preoccupa di cosa stanno facendo i thread in modalità utente. Windows rileva solo i thread eseguibili e li consente di eseguire fino alla fine del quantum del sistema operativo o fino a quando non si bloccano. - usr

In Come gestire valori eccessivi del tipo di attesa SOS_SCHEDULER_YIELD in SQL Server di Nikola Dimitrijevic, il termine "quantum" viene utilizzato essenzialmente per "il tempo che un'attività trascorre effettivamente assegnata a un lavoratore", ma non è lo stesso senso di un quantum di Windows, che è un periodo di tempo dopo il quale il sistema operativo rimuoverà un thread da una CPU. Sono solo concetti diversi. Se il sistema operativo forza un thread a terminare l'esecuzione perché è stato raggiunto il quantum del sistema operativo, si verifica un cambio di contesto. Il thread di SQL Server è sospeso, proprio come qualsiasi altro programma. - David Browne - Microsoft e George.Palacios .

---

Estratti dalla documentazione: all'interno dell'utilità di pianificazione della modalità utente di SQL Server 2000 (scritta per SQL Server 2000, ma ancora rilevante):

Compiti preventivi e cooperativi

UMS, al contrario, si affida ai thread per produrre volontariamente. UMS adotta l'approccio adottato per evitare di coinvolgere il kernel di Windows più del necessario. In un sistema in cui i thread di lavoro possono essere contati per produrre quando dovrebbero, uno scheduler cooperativo può effettivamente essere più efficiente di uno preventivo perché il processo di pianificazione può essere adattato alle esigenze specifiche dell'applicazione. Come ho detto in precedenza, UMS conosce le esigenze di pianificazione di SQL Server meglio di quanto ci si possa aspettare dal sistema operativo.

In che modo UMS rileva la pianificazione

Se UMS deve gestire le esigenze di pianificazione di SQL Server piuttosto che consentire a Windows di farlo, UMS deve in qualche modo impedire al sistema operativo di fare ciò che fa con ogni altro processo: pianificare i thread dentro e fuori i processori del sistema come meglio ritiene opportuno. Come si fa in un sistema operativo preventivo? UMS risolve questo problema con alcuni trucchi intelligenti con gli oggetti evento di Windows. A ogni thread in UMS è associato un oggetto evento. Ai fini della pianificazione, Windows ignora i thread che non considera validi: thread che non possono essere eseguiti perché si trovano in uno stato di attesa infinito. Sapendo questo, UMS mette in sleep i thread che non vuole essere programmati facendoli chiamare WaitForSingleObject sul loro oggetto evento corrispondente e passando INFINITE per il valore di timeout.

Al fine di impedire a Windows di pianificare più thread sullo stesso processore e quindi sostenere il sovraccarico e il costo dei cambi di contesto, UMS tenta di mantenere vitale solo un thread, ovvero non in uno stato di attesa infinito, per processore.