22
Chapitre 2. Architecture de SQL Server
laissent eux-mêmes la place aux autres, dans un mode collaboratif, ce qui permet
d’obtenir de meilleures performances. Un ordonnanceur est lié à un processeur physique. Il gère plusieurs threads, qui sont eux-mêmes liés à des workers. Le worker est le
processus de travail. Il exécute un travail complètement, ce qui évite les changements de contextes qui peuvent se produire en cas de multitâche préemptif. Un
changement de contexte (context switch) représente la nécessité, pour un processus,
de sauver son état lorsqu’il donne la main, puis de le recharger lorsqu’il reprend le
travail, comme un travailleur doit déposer ses affaires dans son placard en partant, et
les reprendre en revenant. Certains threads à l’intérieur de l’espace de SQL Server ne
sont pas lancés par SQL Server, c’est le cas lors de l’exécution de procédures stockées
étendues. Nous voyons tout cela schématiquement sur la figure 2.4, avec les vues de
gestions dynamique qui correspondent.
Figure 2.4 — SQLOS, l’ordonnanceur
Ces vues vous permettent de voir les processus en activité, la mémoire de travail
utilisée par chacun, s’ils sont en travail ou en attente, etc.
Outre la gestion locale des processus, SQLOS assure aussi la gestion locale de
l’allocation mémoire. Un Memory Broker calcule dynamiquement les quantités optimales de RAM pour les différents objets en mémoires. Ces objets sont des caches
(buffers), des pools, qui gèrent des objets plus simples que les caches, par exemple la
mémoire pour les verrous, et des clerks, qui sont des gestionnaires d’espace mémoire
fournissant des services d’allocation et de notification d’état de la mémoire. Ces différents éléments sont reproduits sur la figure 2.5.
Chapitre 2. Architecture de SQL Server
laissent eux-mêmes la place aux autres, dans un mode collaboratif, ce qui permet
d’obtenir de meilleures performances. Un ordonnanceur est lié à un processeur physique. Il gère plusieurs threads, qui sont eux-mêmes liés à des workers. Le worker est le
processus de travail. Il exécute un travail complètement, ce qui évite les changements de contextes qui peuvent se produire en cas de multitâche préemptif. Un
changement de contexte (context switch) représente la nécessité, pour un processus,
de sauver son état lorsqu’il donne la main, puis de le recharger lorsqu’il reprend le
travail, comme un travailleur doit déposer ses affaires dans son placard en partant, et
les reprendre en revenant. Certains threads à l’intérieur de l’espace de SQL Server ne
sont pas lancés par SQL Server, c’est le cas lors de l’exécution de procédures stockées
étendues. Nous voyons tout cela schématiquement sur la figure 2.4, avec les vues de
gestions dynamique qui correspondent.
Figure 2.4 — SQLOS, l’ordonnanceur
Ces vues vous permettent de voir les processus en activité, la mémoire de travail
utilisée par chacun, s’ils sont en travail ou en attente, etc.
Outre la gestion locale des processus, SQLOS assure aussi la gestion locale de
l’allocation mémoire. Un Memory Broker calcule dynamiquement les quantités optimales de RAM pour les différents objets en mémoires. Ces objets sont des caches
(buffers), des pools, qui gèrent des objets plus simples que les caches, par exemple la
mémoire pour les verrous, et des clerks, qui sont des gestionnaires d’espace mémoire
fournissant des services d’allocation et de notification d’état de la mémoire. Ces différents éléments sont reproduits sur la figure 2.5.