Question simple

Comment le SQL Server Quantum (4 ms) est-il synchronisé avec le serveur OS Quantum (normalement: 187,5 ms)?

Explication d'une question simple

Après 184 ms de quantum OS utilisé (ce qui correspond à 46 quantums SQL complets), le quantum OS dispose de 3,5 ms de temps avant de devoir transférer le planning à un processus différent. Le système d'exploitation SQL démarre un quantum (4 ms) et après 3,5 ms, le quantum du système d'exploitation a décidé d'arrêter le thread SQL OS actuel qui a encore 0,5 ms avant de produire le calendrier. Que se passe-t-il maintenant?

---

Deep Dive sur OS Quantum

Dans les prochaines sections, j'écrirai ce que j'ai trouvé jusqu'à présent concernant le quantum du système d'exploitation et comment la durée d'un quantum peut être calculée. La durée d'un "quantum" OS est basée sur des "ticks" et la durée du "tick" lui-même est basée sur "l'intervalle d'horloge" qui est normalement de 15,625000 ms. Mais laissez-moi élaborer un peu ...

Cocher

Dans l'article du blog Know Thy Tick, l'auteur Jim explique les principes de base des intervalles d'horloge (aka "ticks") et à quoi ils servent.

Quand je lis quelque chose comme «l'intervalle d'horloge… pour la plupart des multiprocesseurs x86 est d'environ 15 millisecondes», je suis obligé de déterminer la valeur de mon horloge, ou «tick», intervalle. Heureusement, le livre dans lequel j'ai lu cette citation, Windows Internals Fourth Edition fournit une référence pour m'aider avec mon affliction. ... L'auteur, Mark Russinovich, du livre susmentionné a gracieusement mis l'utilitaire ClockRes à disposition sur son site Web. En exécutant cet utilitaire, j'ai pu déterminer que l'intervalle d'horloge sur mon PC multiprocesseur x86 est de 15,625000 ms. Intéressant, mais mon esprit curieux veut en savoir plus.

Quantum

L'auteur de l'article poursuit en expliquant dans son deuxième article cette...

Bien sûr, la vraie raison pour laquelle l'intervalle de tick est important est qu'il affecte la planification des threads . Le planificateur Windows donne à chaque thread un «quantum» de temps à exécuter avant d'autoriser l'exécution d'une autre tâche, au même niveau de priorité. Le quantum que le planificateur affecte à un thread est un multiple de l'intervalle de tick . La valeur quantique spécifique choisie pour un thread spécifique est un peu au-delà de l'endroit où je veux aller avec cet article.

Ok, donc je sais ce qu'est un quantum, mais pas combien de temps un quantum va fonctionner.

Pour l'instant, examinons simplement la valeur quantique par défaut pour un thread de premier plan dans XPe. Dans ce cas, le planificateur Windows attribue un quantum de 18 ou 6 intervalles de tick. (Oui, pour convertir le quantum en intervalles de tick, il faut diviser par 3. ..., mais la raison du multiple est de permettre au planificateur de "charger" un thread pour effectuer une opération qui le fait suspendre.)

Nous savons maintenant qu'un intervalle d'horloge (tick) devrait être d'environ 15,625000 ms et sur un OS de bureau Windows où le quantum par défaut est 18, cela se traduira par 6 ticks ou 93,750000 ms (18/3 * 15,625000 ms).

Sur un système d'exploitation Windows Server, le quantum par défaut est différent. Le paramètre "Planification du processeur" est défini sur "Services d'arrière-plan"

^{Ce paramètre peut être trouvé via "Paramètres système | Avancé (onglet) | Performance (section) | Paramètres ..." qui ouvrira "Options de performance | Avancé (onglet) | Planification du processeur"}

Les paramètres quantiques par défaut sont alors de 36 (arrière-plan) à 36 (premier plan). Le quantum est plus grand et donc plus long. C'est le double du 93,750000 ms du paramètre de premier plan quantique 18 (6 tick) sur un OS de bureau Windows, qui sur un OS de serveur configuré pour les services d'arrière-plan est d'environ 187 500 000 ms.

Observation / explication

Lorsque vous modifiez le paramètre de «Services d'arrière-plan» à «Applicaitons» sur un serveur ou un bureau, la clé HKLM \ SYSTEM \ CurrentControlSet \ Control \ PriorityControl \ Win32PrioritySeparation dans le Registre est modifiée de 0x18 à 0x02. Quelle est la valeur quantique par défaut pour 0x02? Cela peut être trouvé dans un commentaire:

La valeur 0x02 implique que les champs "Court vs. Long" et "Variable vs. Fixe" sont les champs par défaut pour l'OS.

La valeur par défaut pour ces champs pour XPe et XP Pro est: Courte et variable, ce qui revient à avoir les bits supplémentaires définis: 0x24.

OU cette valeur avec 0x02 vous donne 0x26, que vous trouverez dans le tableau de l'article.

^{Référence: Commentaire à "Maîtrisez votre Quantum" (Blogs MSDN)}

Le tableau expliquant les paramètres quantiques du même article:

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

Bref résumé d'OS Quantum

Sur la base des informations ci-dessus et des citations d'articles, nous savons qu'un quantum n'est pas une taille fixe, mais plutôt dérivé d'un paramètre de système d'exploitation dans les propriétés du système. Un quantum varie en fonction du Win32PrioritySeparationparamètre du registre qui correspond normalement à l'un des paramètres des "Propriétés système" (soit "Services d'arrière-plan" ou "Applications").

Un quantum au niveau du système d'exploitation est

• pour le paramètre "Applications"
  • 18 (soit 6 graduations) pour les applications de premier plan (93,75 ms)
  • 6 (soit 2 graduations) pour les applications en arrière-plan (31,25 ms)
• pour le paramètre "Background Services"
  • 36 (soit 18 graduations) pour les applications de premier plan (187,5 ms)
  • 36 (soit 18 graduations) pour les applications en arrière-plan (187,5 ms)

Alors maintenant, nous savons qu'un quantum de système d'exploitation sur une configuration de Windows Server à optimiser pour les services d'arrière-plan est ...

36 / 3 * 15.625000 ms = 187.5 ms

---

SQL OS Quantum

Cette section répertorie ce que j'ai trouvé sur SQL OS quantum ...

Type d'attente SOS_SCHEDULER_YIELD

D'après la description de Paul Randall sur le type d'attente SOS_SCHEDULER_YIELD:

Ce type d'attente est lorsqu'un thread a pu s'exécuter pour son quantum de thread complet (4 millisecondes dans toutes les versions de SQL Server, immuable ), et a donc volontairement donné le planificateur, se déplaçant vers le bas de la file d'attente d'exécution dans son planificateur.

^{Référence: SOS_SCHEDULER_YIELD (types d'attente SQLSkills.com)}

Planificateurs dans les DMV SQL Server

Dans une explication sur les DMV SQL Server pour le DMV sys.dm_os_schedulers.

[...] Windows utilise un mécanisme de planification préemptif et attribue un quantum de temps CPU à chaque thread, lorsqu'un thread consomme son quantum, il est envoyé dans une file d'attente et d'autres threads sont exécutés.

En opposition, SQL Server utilise un mécanisme de planification coopérative lorsque les threads peuvent volontairement produire son quantum de temps (vous pouvez voir ce comportement lorsque vous avez un type d'attente SOS_SCHEDULER_YIELD). Cela permet à SQL Server d'optimiser l'utilisation du processeur, car lorsqu'un thread est signalé pour exécution mais n'est pas prêt à s'exécuter, il peut céder son temps en faveur d'autres threads .

^{Référence: Comprendre les planificateurs, les travailleurs et les tâches SQL Server (MSSQLTips.com)}

Détecter la pression du processeur SQL Server

Il s'agit d'une toute petite section d'un article concernant la pression du processeur dans SQL Server.

Se produit lorsqu'une tâche renvoie volontairement le planificateur pour l'exécution d'autres tâches. Pendant cette attente, la tâche attend que son quantum soit renouvelé .

^{Référence: Détecter la pression du processeur SQL Server (MSSQLTips.com)}

sys.dm_os_schedulers (Microsoft Docs)

Je suppose que la citation suivante est l'extrait le plus important d'informations concernant le quantum SQL OS que j'ai pu trouver:

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

^{Référence: sys.dm_os_schedulers (Transact-SQL) (Microsoft | Docs)}

---

Mon énigme

Le serveur OS Quantum régule le temps accordé au service SQL Server pour exécuter des "tâches". SQL Server OS Quantum est défini sur 4 ms. Si je divise les 187,5 ms par 4 ms, il me reste 3,5 ms.

Et nous n'avons même pas commencé la discussion sur le moment où l'intervalle d'horloge est réglé sur autre chose que la valeur par défaut de 15,625000 ms ...

Question simple

Comment le SQL Server Quantum (4 ms) est-il synchronisé avec le serveur OS Quantum (normalement: 187,5 ms)?

Explication d'une question simple

Après 184 ms de quantum OS utilisé (ce qui correspond à 46 quantums SQL complets), le quantum OS dispose de 3,5 ms de temps avant de devoir transférer le planning à un processus différent. Le système d'exploitation SQL démarre un quantum (4 ms) et après 3,5 ms, le quantum du système d'exploitation a décidé d'arrêter le thread SQL OS actuel qui a encore 0,5 ms avant de produire le calendrier. Que se passe-t-il maintenant?

Même si le planificateur n'est pas préemptif, le planificateur SQL Server adhère toujours à un concept de quantum. Bien que les tâches SQL Server soient forcées d'abandonner le CPU par le système d'exploitation, elles peuvent demander à être mises en file d'attente périodiquement et si elles ont dépassé le quantum de 4 millisecondes défini en interne et ne sont pas au milieu d'une opération qui ne peuvent pas être arrêtés, ils abandonnent volontairement le CPU.

- « Microsoft SQL Server 2012 Internals », Kalen Delaney et. Al. pp38

-Chapitre 2 "Le SQLOS" Jonathan Kehayias

Ainsi, la notion de «quantum» à l'intérieur de SQL Server est plutôt une «directive» pour les tâches de programmation. IE lorsque vous écrivez une tâche, comme disons, une tâche qui effectue une analyse de table, si vous n'appuyez sur aucun verrou de page, verrou IO ou verrouille pendant un certain temps, vous devez arrêter ce que vous faites et demander à être remettre sur la file d'attente exécutable, au cas où d'autres tâches attendent.

Mais c'est au programmeur de tâches de l'implémenter, et ce n'est peut-être pas exactement ms pour chaque type de tâche. Par exemple, la tâche d'analyse de table peut utiliser une heuristique simple basée sur le nombre de pages numérisées pour implémenter les limites de rendement.

Donc

Le système d'exploitation SQL démarre un quantum (4 ms) et après 3,5 ms, le quantum du système d'exploitation a décidé d'arrêter le thread SQL OS actuel qui a encore 0,5 ms avant de produire le calendrier. Que se passe-t-il maintenant?

Si le thread SQL Server est préempté par Windows pendant qu'une tâche est en cours d'exécution, il sera suspendu et lorsque son thread sera planifié sur un processeur, il continuera là où il s'était arrêté. Vraisemblablement, il continuera à consommer le reste de son quantum de 4 ms, car il ne connaîtra aucune différence. Mais encore une fois, le comportement de rendement est un détail d'implémentation de la tâche, pas un comportement de SQLOS, donc différentes tâches peuvent se comporter différemment ici.

_{Répondre aux contributions initialement laissées sous forme de commentaires}

Comment le SQL Server Quantum (4 ms) est-il synchronisé avec le serveur OS Quantum (normalement: 187,5 ms)?

Ce n'est pas le cas et SQL Server n'utilise pas de planification préemptive. Les éléments de travail devraient atteindre des points de rendement et s'ils ne le font pas, vous obtenez des éléments tels que les NONYIELDINGplanificateurs. Il n'y a pas de parité. SQL Server ne distribue pas l'heure. Il rend certains threads attrayants pour Windows à planifier et Windows les planifie. Quantum n'est qu'une nomenclature pour un morceau de temps. C'est ça. SQL Server n'est pas préemptif, il est de la responsabilité de tout ce qui est en cours d'exécution de se produire tout au long du code. - Sean Gallardy

Lorsque le quantum du système d'exploitation expire, le thread est fortement replanifié. C'est transparent pour SQL Server. SQLOS n'a aucun moyen de détecter quand cela se produit. Il n'y a pas d'API Win32 pour cela. La planification est transparente pour les threads en mode utilisateur. Le planificateur Windows ne sait pas ou ne se soucie pas de ce que font les threads en mode utilisateur. Windows ne voit que les threads exécutables et les laisse s'exécuter jusqu'à la fin de leur quantum de système d'exploitation ou jusqu'à ce qu'ils se bloquent. - usr

Dans Comment gérer les valeurs de type d'attente SOS_SCHEDULER_YIELD excessives dans SQL Server par Nikola Dimitrijevic, le terme "quantique" est utilisé pour signifier essentiellement "le temps qu'une tâche passe réellement affecté à un travailleur", mais ce n'est pas le même sens qu'un quantum Windows, qui est une période de temps après laquelle le système d'exploitation supprimera un thread d'un CPU. Ce ne sont que des concepts différents. Si le système d'exploitation force un thread à terminer l'exécution parce que le quantum du système d'exploitation a été atteint, un changement de contexte se produit. Le thread de SQL Server est suspendu, comme tout autre programme. - David Browne - Microsoft et George.Palacios .

---

Extraits de la documentation: À l'intérieur du Planificateur de mode utilisateur SQL Server 2000 (écrit pour SQL Server 2000, mais toujours pertinent):

Tâches préemptives et coopératives

UMS, en revanche, s'appuie sur des threads pour céder volontairement. UMS adopte l'approche qu'elle utilise pour éviter d'impliquer le noyau Windows plus qu'absolument nécessaire. Dans un système où les threads de travail peuvent être comptés pour céder quand ils le devraient, un planificateur coopératif peut en fait être plus efficace qu'un plan préemptif car le processus de planification peut être adapté aux besoins spécifiques de l'application. Comme je l'ai dit plus tôt, UMS connaît mieux les besoins de planification de SQL Server que ce à quoi le système d'exploitation peut s'attendre.

Comment UMS prend le pas sur la planification

Si UMS doit gérer les besoins de planification de SQL Server plutôt que de permettre à Windows de le faire, UMS doit en quelque sorte empêcher le système d'exploitation de faire ce qu'il fait avec tous les autres processus: planifier les threads sur et hors du ou des processeurs du système comme bon lui semble. Comment faites-vous cela dans un système d'exploitation préemptif? UMS réussit à travers quelques astuces intelligentes avec des objets d'événement Windows. Chaque thread sous UMS a un objet événement associé. À des fins de planification, Windows ignore les threads qu'il ne considère pas comme viables - les threads qui ne peuvent pas s'exécuter car ils sont dans un état d'attente infini. Sachant cela, UMS met en veille les threads qu'il ne souhaite pas planifier en les faisant appeler WaitForSingleObject sur leur objet d'événement correspondant et en passant INFINITE pour la valeur de délai d'attente.

Afin d’empêcher Windows de planifier plusieurs threads sur le même processeur et d’encourir ainsi les frais généraux et les coûts des changements de contexte, UMS tente de maintenir un seul thread viable - c’est-à-dire pas dans un état d’attente infinie - par processeur.