Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Problème de configuration soft-NUMA sur SQL Server 2005

4 réponses
Avatar
Noel
Bonjour,

Je travaille sur la base de données (SQL Server 2005 sous Win 2003)
d'une application qui est d'une part utilisée pour une application web
(partie transactionnelle 24/24) et d'autre part pour une partie
asynchrone (20h -> 06h).
Il apparait que la partie asynchrone arrive à consommer, par moment, la
totalité des ressources du serveur, rendant alors la partie
transactionnelle très lente voire inaccessible.

Je souhaiterais donc mettre en place une configuration soft-NUMA afin de
limiter l'accès CPU pour la partie asynchrone.

La plate-forme de test est constitué de 2 noeuds NUMA hardware,
disposant de 2 CPUs hyperthreadés (4 CPUs par noeud). Les CPUs sont
répartis de la façon suivante dans ces 2 noeud NUMA hardware :
- Node 0 : CPU 0, 1, 4 et 5
- Node 1 : CPU 2, 3, 6 et 7

Je teste actuellement la configuration suivante sur la plate-forme
décrite plus haut :
Configuration soft-NUMA (dans la base de registre)
CPUs 7 6 5 4 3 2 1 0
node 0 0 0 1 1 0 0 1 1
node 1 0 0 0 0 1 1 0 0
node 2 1 1 0 0 0 0 0 0
J'ai respecté le fait que l'on ne peut pas créer de noeuds softs avec
des CPUs de noeuds hardwares différents.

En parallèle, aucune affinité CPU n'est défini car je me trouve sur une
seule instance.

Ensuite au niveau SQL Server, j'ai défini un endpoint sur le port TCP n°
2000, en prenant bien soin de donner les droits de connexion sur cet
EndPoint.

Puis dans le SQL Server configuration manager, j'ai ajouté le port 2000.
Sachant que les ports ainsi saisis sont appliqués sur l'ensemble des
adresses IP.
J'ai ensuite ajouté un mapping sur mes ports TCP afin de créer mes
regroupements de nodes soft-NUMA. J'obtients la configuration suivante :
1433,2000[5].

Avec cette configuration, normalement, lorsque je me connecte à ma base
via le port 1433, je dois disposer de l'ensemble de mes CPUs. Par
contre, lorsque je me connecte sur le port 2000, je ne dois disposer que
des CPUs des mes nodes 0 et 2 soit les CPUS 0,1,4,5,6 et 7.

Or, et voici mon problème, lorsque je me connecte sur le port 2000 et
que je lance une requête qui consomme la totalité des ressources
systèmes, tous mes CPUs sont utilisés !
Afin de vérifier de nouveau, j'ai modifié le mapping noeud NUMA sur les
port TCP : 1433[2],2000[5].
Normalement, si je connecte sur le port 1433, je ne devrait disposer que
des CPUs du noeud NUMA 1, soit 2 CPUs. Or, si je relance ma requete,
tous mes CPUs sont à 100%

Lorque je regarde la configuration prise en compte par SQL Server, qui
se trouve dans l'error log, tout semble normal :
Multinode configuration: node 0: CPU mask: 0x0000000c Active CPU mask:
0x0000000c. This message provides a description of the NUMA
configuration for this computer. This is an informational message only.
No user action is required.
Multinode configuration: node 1: CPU mask: 0x00000033 Active CPU mask:
0x00000033. This message provides a description of the NUMA
configuration for this computer. This is an informational message only.
No user action is required.
Multinode configuration: node 2: CPU mask: 0x000000c0 Active CPU mask:
0x000000c0. This message provides a description of the NUMA
configuration for this computer. This is an informational message only.
No user action is required.
Server is listening on [ x.x.x.208 <ipv4> 2000].
Server is listening on [ x.x.x.245 <ipv4> 2000].
Server is listening on [ x.x.x.132 <ipv4> 2000].
SQL Network Interfaces initialized listeners on node 2 of a multi-node
(NUMA) server configuration with node affinity mask 0x00000005. This is
an informational message only. No user action is required.
Server is listening on [ x.x.x.208 <ipv4> 1433].
Server is listening on [ x.x.x.245 <ipv4> 1433].
Server is listening on [ x.x.x.132 <ipv4> 1433].
SQL Network Interfaces initialized listeners on node 1 of a multi-node
(NUMA) server configuration with node affinity mask 0x00000002. This is
an informational message only. No user action is required.

Quelqu'un sait-il pourquoi, malgré la limitation liée à la configuration
NUMA, tous les CPUS du serveur sont utilisés ?
Ai-je commis une erreur dans la configuration NUMA de SQL Server ?
Faut-il définir une affinité CPU en parallèle de la configuration NUMA ?
Mais comment faire, car je travaille sur une seule instance ?

Merci d'avance de vos réponses.

4 réponses

Avatar
Fred BROUARD
Bonjour,

Noel a écrit :
Bonjour,

Je travaille sur la base de données (SQL Server 2005 sous Win 2003)
d'une application qui est d'une part utilisée pour une application web
(partie transactionnelle 24/24) et d'autre part pour une partie
asynchrone (20h -> 06h).
Il apparait que la partie asynchrone arrive à consommer, par moment, la
totalité des ressources du serveur, rendant alors la partie
transactionnelle très lente voire inaccessible.

Je souhaiterais donc mettre en place une configuration soft-NUMA afin de
limiter l'accès CPU pour la partie asynchrone.

La plate-forme de test est constitué de 2 noeuds NUMA hardware,
disposant de 2 CPUs hyperthreadés (4 CPUs par noeud). Les CPUs sont
répartis de la façon suivante dans ces 2 noeud NUMA hardware :
- Node 0 : CPU 0, 1, 4 et 5
- Node 1 : CPU 2, 3, 6 et 7




L'hyper threading n'est franchement pas conseillé à cause du bug. Il
n'pporte réeelement qu'environ 15% de fluidité en sus mais peut devenir
bloquant.

Je teste actuellement la configuration suivante sur la plate-forme
décrite plus haut :
Configuration soft-NUMA (dans la base de registre)
CPUs 7 6 5 4 3 2 1 0
node 0 0 0 1 1 0 0 1 1
node 1 0 0 0 0 1 1 0 0
node 2 1 1 0 0 0 0 0 0
J'ai respecté le fait que l'on ne peut pas créer de noeuds softs avec
des CPUs de noeuds hardwares différents.

En parallèle, aucune affinité CPU n'est défini car je me trouve sur une
seule instance.

Ensuite au niveau SQL Server, j'ai défini un endpoint sur le port TCP n°
2000, en prenant bien soin de donner les droits de connexion sur cet
EndPoint.

Puis dans le SQL Server configuration manager, j'ai ajouté le port 2000.
Sachant que les ports ainsi saisis sont appliqués sur l'ensemble des
adresses IP.
J'ai ensuite ajouté un mapping sur mes ports TCP afin de créer mes
regroupements de nodes soft-NUMA. J'obtients la configuration suivante :
1433,2000[5].

Avec cette configuration, normalement, lorsque je me connecte à ma base
via le port 1433, je dois disposer de l'ensemble de mes CPUs. Par
contre, lorsque je me connecte sur le port 2000, je ne dois disposer que
des CPUs des mes nodes 0 et 2 soit les CPUS 0,1,4,5,6 et 7.

Or, et voici mon problème, lorsque je me connecte sur le port 2000 et
que je lance une requête qui consomme la totalité des ressources
systèmes, tous mes CPUs sont utilisés !
Afin de vérifier de nouveau, j'ai modifié le mapping noeud NUMA sur les
port TCP : 1433[2],2000[5].
Normalement, si je connecte sur le port 1433, je ne devrait disposer que
des CPUs du noeud NUMA 1, soit 2 CPUs. Or, si je relance ma requete,
tous mes CPUs sont à 100%

Lorque je regarde la configuration prise en compte par SQL Server, qui
se trouve dans l'error log, tout semble normal :
Multinode configuration: node 0: CPU mask: 0x0000000c Active CPU mask:
0x0000000c. This message provides a description of the NUMA
configuration for this computer. This is an informational message only.
No user action is required.
Multinode configuration: node 1: CPU mask: 0x00000033 Active CPU mask:
0x00000033. This message provides a description of the NUMA
configuration for this computer. This is an informational message only.
No user action is required.
Multinode configuration: node 2: CPU mask: 0x000000c0 Active CPU mask:
0x000000c0. This message provides a description of the NUMA
configuration for this computer. This is an informational message only.
No user action is required.
Server is listening on [ x.x.x.208 <ipv4> 2000].
Server is listening on [ x.x.x.245 <ipv4> 2000].
Server is listening on [ x.x.x.132 <ipv4> 2000].
SQL Network Interfaces initialized listeners on node 2 of a multi-node
(NUMA) server configuration with node affinity mask 0x00000005. This is
an informational message only. No user action is required.
Server is listening on [ x.x.x.208 <ipv4> 1433].
Server is listening on [ x.x.x.245 <ipv4> 1433].
Server is listening on [ x.x.x.132 <ipv4> 1433].
SQL Network Interfaces initialized listeners on node 1 of a multi-node
(NUMA) server configuration with node affinity mask 0x00000002. This is
an informational message only. No user action is required.

Quelqu'un sait-il pourquoi, malgré la limitation liée à la configuration
NUMA, tous les CPUS du serveur sont utilisés ?
Ai-je commis une erreur dans la configuration NUMA de SQL Server ?
Faut-il définir une affinité CPU en parallèle de la configuration NUMA ?
Mais comment faire, car je travaille sur une seule instance ?

Merci d'avance de vos réponses.



Pourquoi ne pas utiliser le paramétrage MAXDOP (sp_configure 'max degree
of parrallelisme' ou dans les requêtes option MAXDOP) ?

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Noel
Fred BROUARD wrote in
news:u$$:

Bonjour,

Noel a écrit :
Bonjour,

Je travaille sur la base de données (SQL Server 2005 sous Win 2003)
d'une application qui est d'une part utilisée pour une application
web (partie transactionnelle 24/24) et d'autre part pour une partie
asynchrone (20h -> 06h).
Il apparait que la partie asynchrone arrive à consommer, par moment,
la totalité des ressources du serveur, rendant alors la partie
transactionnelle très lente voire inaccessible.

Je souhaiterais donc mettre en place une configuration soft-NUMA afin
de limiter l'accès CPU pour la partie asynchrone.

La plate-forme de test est constitué de 2 noeuds NUMA hardware,
disposant de 2 CPUs hyperthreadés (4 CPUs par noeud). Les CPUs sont
répartis de la façon suivante dans ces 2 noeud NUMA hardware :
- Node 0 : CPU 0, 1, 4 et 5
- Node 1 : CPU 2, 3, 6 et 7




L'hyper threading n'est franchement pas conseillé à cause du bug. Il
n'pporte réeelement qu'environ 15% de fluidité en sus mais peut
devenir bloquant.

Je teste actuellement la configuration suivante sur la plate-forme
décrite plus haut :
Configuration soft-NUMA (dans la base de registre)
CPUs 7 6 5 4 3 2 1 0
node 0 0 0 1 1 0 0 1 1
node 1 0 0 0 0 1 1 0 0
node 2 1 1 0 0 0 0 0 0
J'ai respecté le fait que l'on ne peut pas créer de noeuds softs avec
des CPUs de noeuds hardwares différents.

En parallèle, aucune affinité CPU n'est défini car je me trouve sur
une seule instance.

Ensuite au niveau SQL Server, j'ai défini un endpoint sur le port TCP
n° 2000, en prenant bien soin de donner les droits de connexion sur
cet EndPoint.

Puis dans le SQL Server configuration manager, j'ai ajouté le port
2000. Sachant que les ports ainsi saisis sont appliqués sur
l'ensemble des adresses IP.
J'ai ensuite ajouté un mapping sur mes ports TCP afin de créer mes
regroupements de nodes soft-NUMA. J'obtients la configuration
suivante : 1433,2000[5].

Avec cette configuration, normalement, lorsque je me connecte à ma
base via le port 1433, je dois disposer de l'ensemble de mes CPUs.
Par contre, lorsque je me connecte sur le port 2000, je ne dois
disposer que des CPUs des mes nodes 0 et 2 soit les CPUS 0,1,4,5,6 et
7.

Or, et voici mon problème, lorsque je me connecte sur le port 2000 et
que je lance une requête qui consomme la totalité des ressources
systèmes, tous mes CPUs sont utilisés !
Afin de vérifier de nouveau, j'ai modifié le mapping noeud NUMA sur
les port TCP : 1433[2],2000[5].
Normalement, si je connecte sur le port 1433, je ne devrait disposer
que des CPUs du noeud NUMA 1, soit 2 CPUs. Or, si je relance ma
requete, tous mes CPUs sont à 100%

Lorque je regarde la configuration prise en compte par SQL Server,
qui se trouve dans l'error log, tout semble normal :
Multinode configuration: node 0: CPU mask: 0x0000000c Active CPU
mask: 0x0000000c. This message provides a description of the NUMA
configuration for this computer. This is an informational message
only. No user action is required.
Multinode configuration: node 1: CPU mask: 0x00000033 Active CPU
mask: 0x00000033. This message provides a description of the NUMA
configuration for this computer. This is an informational message
only. No user action is required.
Multinode configuration: node 2: CPU mask: 0x000000c0 Active CPU
mask: 0x000000c0. This message provides a description of the NUMA
configuration for this computer. This is an informational message
only. No user action is required.
Server is listening on [ x.x.x.208 <ipv4> 2000].
Server is listening on [ x.x.x.245 <ipv4> 2000].
Server is listening on [ x.x.x.132 <ipv4> 2000].
SQL Network Interfaces initialized listeners on node 2 of a
multi-node (NUMA) server configuration with node affinity mask
0x00000005. This is an informational message only. No user action is
required. Server is listening on [ x.x.x.208 <ipv4> 1433].
Server is listening on [ x.x.x.245 <ipv4> 1433].
Server is listening on [ x.x.x.132 <ipv4> 1433].
SQL Network Interfaces initialized listeners on node 1 of a
multi-node (NUMA) server configuration with node affinity mask
0x00000002. This is an informational message only. No user action is
required.

Quelqu'un sait-il pourquoi, malgré la limitation liée à la
configuration NUMA, tous les CPUS du serveur sont utilisés ?
Ai-je commis une erreur dans la configuration NUMA de SQL Server ?
Faut-il définir une affinité CPU en parallèle de la configuration
NUMA ? Mais comment faire, car je travaille sur une seule instance ?

Merci d'avance de vos réponses.



Pourquoi ne pas utiliser le paramétrage MAXDOP (sp_configure 'max
degree of parrallelisme' ou dans les requêtes option MAXDOP) ?

A +




Merci pour ta réponse.

Pour l'hyperthreading, malheureusement ce n'est pas moi qui décide :(

Pour le maxdop, c'est une solution aussi envisagée mais qui oblige à
toucher au code ... et là ... bah ça va prendre du temps et il risque
d'y avoir des oublis compte-tenu de la quantité de code à modifier.
C'est pour cela que j'essaie de mettre ce soft-NUMA en place. En effet,
je n'aurais alors qu'à modifier la chaine de connexion afin de se
connecter sur le bon port et donc disposer des ressources allouées aux
différents traitements.
De plus le soft-NUMA optimise la gestion de la mémoire.
Pour exemple, sur des tests fait en activant le soft NUMA mais sur 4 CPU
(les 4 CPU virtuels), je vais 2 fois plus vite qu'avec un MAXDOP 4 :)

@+
Avatar
Fred BROUARD
Noel a écrit :
Fred BROUARD wrote in
news:u$$:

Bonjour,

Noel a écrit :
Bonjour,

Je travaille sur la base de données (SQL Server 2005 sous Win 2003)
d'une application qui est d'une part utilisée pour une application
web (partie transactionnelle 24/24) et d'autre part pour une partie
asynchrone (20h -> 06h).
Il apparait que la partie asynchrone arrive à consommer, par moment,
la totalité des ressources du serveur, rendant alors la partie
transactionnelle très lente voire inaccessible.

Je souhaiterais donc mettre en place une configuration soft-NUMA afin
de limiter l'accès CPU pour la partie asynchrone.

La plate-forme de test est constitué de 2 noeuds NUMA hardware,
disposant de 2 CPUs hyperthreadés (4 CPUs par noeud). Les CPUs sont
répartis de la façon suivante dans ces 2 noeud NUMA hardware :
- Node 0 : CPU 0, 1, 4 et 5
- Node 1 : CPU 2, 3, 6 et 7



L'hyper threading n'est franchement pas conseillé à cause du bug. Il
n'pporte réeelement qu'environ 15% de fluidité en sus mais peut
devenir bloquant.

Je teste actuellement la configuration suivante sur la plate-forme
décrite plus haut :
Configuration soft-NUMA (dans la base de registre)
CPUs 7 6 5 4 3 2 1 0
node 0 0 0 1 1 0 0 1 1
node 1 0 0 0 0 1 1 0 0
node 2 1 1 0 0 0 0 0 0
J'ai respecté le fait que l'on ne peut pas créer de noeuds softs avec
des CPUs de noeuds hardwares différents.

En parallèle, aucune affinité CPU n'est défini car je me trouve sur
une seule instance.

Ensuite au niveau SQL Server, j'ai défini un endpoint sur le port TCP
n° 2000, en prenant bien soin de donner les droits de connexion sur
cet EndPoint.

Puis dans le SQL Server configuration manager, j'ai ajouté le port
2000. Sachant que les ports ainsi saisis sont appliqués sur
l'ensemble des adresses IP.
J'ai ensuite ajouté un mapping sur mes ports TCP afin de créer mes
regroupements de nodes soft-NUMA. J'obtients la configuration
suivante : 1433,2000[5].

Avec cette configuration, normalement, lorsque je me connecte à ma
base via le port 1433, je dois disposer de l'ensemble de mes CPUs.
Par contre, lorsque je me connecte sur le port 2000, je ne dois
disposer que des CPUs des mes nodes 0 et 2 soit les CPUS 0,1,4,5,6 et
7.

Or, et voici mon problème, lorsque je me connecte sur le port 2000 et
que je lance une requête qui consomme la totalité des ressources
systèmes, tous mes CPUs sont utilisés !
Afin de vérifier de nouveau, j'ai modifié le mapping noeud NUMA sur
les port TCP : 1433[2],2000[5].
Normalement, si je connecte sur le port 1433, je ne devrait disposer
que des CPUs du noeud NUMA 1, soit 2 CPUs. Or, si je relance ma
requete, tous mes CPUs sont à 100%

Lorque je regarde la configuration prise en compte par SQL Server,
qui se trouve dans l'error log, tout semble normal :
Multinode configuration: node 0: CPU mask: 0x0000000c Active CPU
mask: 0x0000000c. This message provides a description of the NUMA
configuration for this computer. This is an informational message
only. No user action is required.
Multinode configuration: node 1: CPU mask: 0x00000033 Active CPU
mask: 0x00000033. This message provides a description of the NUMA
configuration for this computer. This is an informational message
only. No user action is required.
Multinode configuration: node 2: CPU mask: 0x000000c0 Active CPU
mask: 0x000000c0. This message provides a description of the NUMA
configuration for this computer. This is an informational message
only. No user action is required.
Server is listening on [ x.x.x.208 <ipv4> 2000].
Server is listening on [ x.x.x.245 <ipv4> 2000].
Server is listening on [ x.x.x.132 <ipv4> 2000].
SQL Network Interfaces initialized listeners on node 2 of a
multi-node (NUMA) server configuration with node affinity mask
0x00000005. This is an informational message only. No user action is
required. Server is listening on [ x.x.x.208 <ipv4> 1433].
Server is listening on [ x.x.x.245 <ipv4> 1433].
Server is listening on [ x.x.x.132 <ipv4> 1433].
SQL Network Interfaces initialized listeners on node 1 of a
multi-node (NUMA) server configuration with node affinity mask
0x00000002. This is an informational message only. No user action is
required.

Quelqu'un sait-il pourquoi, malgré la limitation liée à la
configuration NUMA, tous les CPUS du serveur sont utilisés ?
Ai-je commis une erreur dans la configuration NUMA de SQL Server ?
Faut-il définir une affinité CPU en parallèle de la configuration
NUMA ? Mais comment faire, car je travaille sur une seule instance ?

Merci d'avance de vos réponses.


Pourquoi ne pas utiliser le paramétrage MAXDOP (sp_configure 'max
degree of parrallelisme' ou dans les requêtes option MAXDOP) ?

A +




Merci pour ta réponse.

Pour l'hyperthreading, malheureusement ce n'est pas moi qui décide :(



Là il serait fortement conseillé de leurs donner les articles à lire sur
le bug intel :
http://blogs.msdn.com/slavao/archive/2005/11/12/492119.aspx
http://www.pcinpact.com/actu/news/LHyperthreading_ralentit_les_serveurs_SQL_et_Citri.htm?vc=1



Pour le maxdop, c'est une solution aussi envisagée mais qui oblige à
toucher au code ... et là ... bah ça va prendre du temps et il risque
d'y avoir des oublis compte-tenu de la quantité de code à modifier.
C'est pour cela que j'essaie de mettre ce soft-NUMA en place. En effet,
je n'aurais alors qu'à modifier la chaine de connexion afin de se
connecter sur le bon port et donc disposer des ressources allouées aux
différents traitements.
De plus le soft-NUMA optimise la gestion de la mémoire.
Pour exemple, sur des tests fait en activant le soft NUMA mais sur 4 CPU
(les 4 CPU virtuels), je vais 2 fois plus vite qu'avec un MAXDOP 4 :)




L'un n'empêche pas l'autre ! Tu peut le faire pour le serveur entier
avec sp_configure. C'est ce que je recommande généralement pour de l'OLTP.

@+



A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Christian Robert
Bonjour

Attention le Soft NUMA n'apporte strictement rien en terme de gestion de
mémoire, le seul qui le permet est le Hard NUMA et ce dernier nécessite un
matériel le supportant. Exemple les processeurs AMD multi-coeurs sont Hard
NUMA (configurable dans le BIOS). Certains serveurs un peu plus haut de
gamme modulable le sont.

Dans votre cas je ne pense pas que votre serveur le soit (Hyper Threading =
Intel et suffisement peu de proc pour avoir une machine de type NUMA)

Cordialement

Christian Robert
SQL Server MVP

"Noel" <ncante(a_supprimer)@free.fr> a écrit dans le message de groupe de
discussion :
Fred BROUARD wrote in
news:u$$:

Bonjour,

Noel a écrit :
Bonjour,

Je travaille sur la base de données (SQL Server 2005 sous Win 2003)
d'une application qui est d'une part utilisée pour une application
web (partie transactionnelle 24/24) et d'autre part pour une partie
asynchrone (20h -> 06h).
Il apparait que la partie asynchrone arrive à consommer, par moment,
la totalité des ressources du serveur, rendant alors la partie
transactionnelle très lente voire inaccessible.

Je souhaiterais donc mettre en place une configuration soft-NUMA afin
de limiter l'accès CPU pour la partie asynchrone.

La plate-forme de test est constitué de 2 noeuds NUMA hardware,
disposant de 2 CPUs hyperthreadés (4 CPUs par noeud). Les CPUs sont
répartis de la façon suivante dans ces 2 noeud NUMA hardware :
- Node 0 : CPU 0, 1, 4 et 5
- Node 1 : CPU 2, 3, 6 et 7




L'hyper threading n'est franchement pas conseillé à cause du bug. Il
n'pporte réeelement qu'environ 15% de fluidité en sus mais peut
devenir bloquant.

Je teste actuellement la configuration suivante sur la plate-forme
décrite plus haut :
Configuration soft-NUMA (dans la base de registre)
CPUs 7 6 5 4 3 2 1 0
node 0 0 0 1 1 0 0 1 1
node 1 0 0 0 0 1 1 0 0
node 2 1 1 0 0 0 0 0 0
J'ai respecté le fait que l'on ne peut pas créer de noeuds softs avec
des CPUs de noeuds hardwares différents.

En parallèle, aucune affinité CPU n'est défini car je me trouve sur
une seule instance.

Ensuite au niveau SQL Server, j'ai défini un endpoint sur le port TCP
n° 2000, en prenant bien soin de donner les droits de connexion sur
cet EndPoint.

Puis dans le SQL Server configuration manager, j'ai ajouté le port
2000. Sachant que les ports ainsi saisis sont appliqués sur
l'ensemble des adresses IP.
J'ai ensuite ajouté un mapping sur mes ports TCP afin de créer mes
regroupements de nodes soft-NUMA. J'obtients la configuration
suivante : 1433,2000[5].

Avec cette configuration, normalement, lorsque je me connecte à ma
base via le port 1433, je dois disposer de l'ensemble de mes CPUs.
Par contre, lorsque je me connecte sur le port 2000, je ne dois
disposer que des CPUs des mes nodes 0 et 2 soit les CPUS 0,1,4,5,6 et
7.

Or, et voici mon problème, lorsque je me connecte sur le port 2000 et
que je lance une requête qui consomme la totalité des ressources
systèmes, tous mes CPUs sont utilisés !
Afin de vérifier de nouveau, j'ai modifié le mapping noeud NUMA sur
les port TCP : 1433[2],2000[5].
Normalement, si je connecte sur le port 1433, je ne devrait disposer
que des CPUs du noeud NUMA 1, soit 2 CPUs. Or, si je relance ma
requete, tous mes CPUs sont à 100%

Lorque je regarde la configuration prise en compte par SQL Server,
qui se trouve dans l'error log, tout semble normal :
Multinode configuration: node 0: CPU mask: 0x0000000c Active CPU
mask: 0x0000000c. This message provides a description of the NUMA
configuration for this computer. This is an informational message
only. No user action is required.
Multinode configuration: node 1: CPU mask: 0x00000033 Active CPU
mask: 0x00000033. This message provides a description of the NUMA
configuration for this computer. This is an informational message
only. No user action is required.
Multinode configuration: node 2: CPU mask: 0x000000c0 Active CPU
mask: 0x000000c0. This message provides a description of the NUMA
configuration for this computer. This is an informational message
only. No user action is required.
Server is listening on [ x.x.x.208 <ipv4> 2000].
Server is listening on [ x.x.x.245 <ipv4> 2000].
Server is listening on [ x.x.x.132 <ipv4> 2000].
SQL Network Interfaces initialized listeners on node 2 of a
multi-node (NUMA) server configuration with node affinity mask
0x00000005. This is an informational message only. No user action is
required. Server is listening on [ x.x.x.208 <ipv4> 1433].
Server is listening on [ x.x.x.245 <ipv4> 1433].
Server is listening on [ x.x.x.132 <ipv4> 1433].
SQL Network Interfaces initialized listeners on node 1 of a
multi-node (NUMA) server configuration with node affinity mask
0x00000002. This is an informational message only. No user action is
required.

Quelqu'un sait-il pourquoi, malgré la limitation liée à la
configuration NUMA, tous les CPUS du serveur sont utilisés ?
Ai-je commis une erreur dans la configuration NUMA de SQL Server ?
Faut-il définir une affinité CPU en parallèle de la configuration
NUMA ? Mais comment faire, car je travaille sur une seule instance ?

Merci d'avance de vos réponses.



Pourquoi ne pas utiliser le paramétrage MAXDOP (sp_configure 'max
degree of parrallelisme' ou dans les requêtes option MAXDOP) ?

A +




Merci pour ta réponse.

Pour l'hyperthreading, malheureusement ce n'est pas moi qui décide :(

Pour le maxdop, c'est une solution aussi envisagée mais qui oblige à
toucher au code ... et là ... bah ça va prendre du temps et il risque
d'y avoir des oublis compte-tenu de la quantité de code à modifier.
C'est pour cela que j'essaie de mettre ce soft-NUMA en place. En effet,
je n'aurais alors qu'à modifier la chaine de connexion afin de se
connecter sur le bon port et donc disposer des ressources allouées aux
différents traitements.
De plus le soft-NUMA optimise la gestion de la mémoire.
Pour exemple, sur des tests fait en activant le soft NUMA mais sur 4 CPU
(les 4 CPU virtuels), je vais 2 fois plus vite qu'avec un MAXDOP 4 :)

@+