Lien entre Affinité CPU et Parallélisme (?)

Bonjour,

Existe-t-il un lien entre l’affinité CPU et le parallélisme ?
Imaginons un Serveur SQL avec 4 CPU (serveur non dédié à SQL Server, Oui, je sais ce n’est pas bien !) et une affinité SQL Server avec les 3 premiers CPU (0, 1, et 2)
Est-ce que cela peut avoir un impact sur le parallélisme, par exemple inhiber le parallélisme ?
Est-il toujours préférable, dans ce contexte, d’activer le Trace Flag 8002 (Cœurs sans aucune affinité avec le ''Scheduler'') si toutefois ce trace flag est applicable à SQL server 2008 SP4 ?

Merci pour vos réponses.

L'affinité CPU aura un impact sur le nombre de threads que SQL Server pourra utiliser dans un plan d'exécution parallèle. Le fait de configurer l'affinité CPU désactive l'utilisation de schedulers.

L'activation du trace flag 8002 ne désactive pas le parallèlisme. Le fait d'activer l'affinité CPU fait qu'un scheduler est dédié à un processeur particulier. L'utilisation du trace flag revient à revenir à un comportement par défaut qui est qu'un scheduler n'est pas dédié à un processeur. Le fait de dédier un scheduler à un processeur particulier peut, en fonction de la charge de travail, avoir un effet non désiré, c'est à dire un processeur qui peut être saturé alors que les autres ne sont pas utilisés. A contrario, le fait d'avoir un comportement par défaut peut favoriser les switches de contextes qui sont couteux en cyle CPU. Si une tâche est reprise sur un autre processeur, il faut alors recharger le contexte de travail avant de résumer la tâche.

++

Merci mikedavem pour ta réponse.
Donc si je comprends bien, le revers de la médaille, c’est-à-dire le comportement par défaut qui '"peut favoriser les switches de contextes qui sont couteux en cyle CPU", c’est le comportement par défaut que nous avions déjà, avant d’appliquer l’affinité CPU, mais sur la totalité des cœurs (c.à.d. sur les 4 Cœurs.)
Donc, si je résume, appliquer l’affinité sur les 3 premiers CPU (0,1 et 2) et activer la trace flag 8002, revient à comportement "normal" (switches de contextes, parfois couteux en cyle CPU), mais uniquement sur 3 CPU au lieu de 4 . C’est bien cela ?

Merci.

Il n'y a pas de comportement normal.... Le comportement le plus sain avec 4 cœurs est de laisser faire le système... Surtout pour un si faible nombre. Il faut aussi penser à limiter le parallélisme à 2.

Le fait de switcher s'avére moins couteux que des attentes pour disposer du même cœur tout le temps d'exécution de la requête; Attente qui peuvent provoquer des famines !

A +

OK. Merci SQLpro pour ces précisions complémentaires. Je vais donc tenir compte de tes conseils.

Cela dépend en effet de la charge de travail et il faut une bonne raison de vouloir coller un scheduler à un processeur particulier.