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.

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 ***********************

Fred BROUARD <brouardf@club-internet.fr> wrote in
news:u$$vC4r2HHA.2064@TK2MSFTNGP03.phx.gbl:

> 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

@+

Noel a écrit :
> Fred BROUARD <brouardf@club-internet.fr> wrote in
> news:u$$vC4r2HHA.2064@TK2MSFTNGP03.phx.gbl:
>
>> 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...12/492119.aspx
http://www.pcinpact.com/actu/news/LH...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 ***********************

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 : Xns998861B2BA76Cncante@207.46.248.16...
> Fred BROUARD <brouardf@club-internet.fr> wrote in
> news:u$$vC4r2HHA.2064@TK2MSFTNGP03.phx.gbl:
>
>> 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
>
> @+