Problèmes de performances avec SQL Server 2012 Enterprise Edition sous licence CAL

De nombreuses modifications de licence ont été introduites dans SQL Server 2012; le plus important a été le passage des licences basées sur les sockets aux licences basées sur les cœurs pour Enterprise Edition. L'un des défis auxquels Microsoft a dû faire face avec ce changement consistait à fournir une voie de migration pour les clients qui utilisaient auparavant des licences basées sur Server+CAL pour Enterprise Edition avant SQL Server 2012. Les clients sous Software Assurance peuvent effectuer une mise à niveau vers SQL Server 2012 Enterprise Edition et continuer à utiliser Server Licence +CAL (également connue sous le nom de "grand-père") mais avec une limitation à 20 processeurs logiques, comme documenté dans le Guide des licences SQL Server 2012. Cette licence s'étend également aux machines virtuelles avec une limite de 4 machines virtuelles couvertes par la licence Enterprise Server + CAL, mais toujours avec la même limitation de 20 processeurs logiques, comme indiqué dans le Guide des licences de virtualisation SQL Server 2012.

Beaucoup de gens ont été pris au dépourvu par la limitation de 20 processeurs logiques, même si elle est documentée dans les guides de licence.

Une entrée est faite dans le fichier ERRORLOG au démarrage de l'instance, spécifiant le nombre de processeurs logiques et que la limitation de 20 processeurs est appliquée :

Avec la configuration par défaut que SQL Server applique sous la limite de 20 processeurs logiques à l'aide de Server+CAL, les 20 premiers planificateurs sont VISIBLES EN LIGNE et tous les planificateurs restants sont VISIBLES HORS LIGNE. Par conséquent, des problèmes de performances peuvent survenir pour l'instance, en raison de déséquilibres du planificateur de nœud NUMA. Pour le démontrer, j'ai créé une machine virtuelle sur notre serveur de test Dell R720 qui a deux sockets et des processeurs Intel Xeon E5-2670 installés, chacun avec 8 cœurs et Hyperthreading activé, fournissant un total de 32 processeurs logiques disponibles sous Windows Server 2012 Datacenter Edition. La VM a été configurée pour avoir 32 CPU virtuels avec 16 processeurs virtuels alloués dans deux nœuds vNUMA.

Figure 1 – Paramètres vNUMA

Dans SQL Server sous le modèle de licence Enterprise Server + CAL, cela se traduit par une configuration du planificateur semblable à la suivante :

SELECT parent_node_id, [status], scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulers ;

Figure 2 – Affectation du planificateur sous Enterprise Server+CAL

Comme vous pouvez le voir, les 16 processeurs logiques du premier nœud NUMA et seuls quatre des processeurs logiques du deuxième nœud NUMA sont utilisés par l'instance. Il en résulte un déséquilibre important des ordonnanceurs entre les deux nœuds NUMA qui peut entraîner des problèmes de performances importants sous charge. Pour le démontrer, j'ai lancé 300 connexions exécutant la charge de travail AdventureWorks Books Online sur l'instance, puis j'ai capturé les informations de planificateur pour les planificateurs VISIBLE ONLINE dans l'instance à l'aide de la requête suivante :

SELECT parent_node_id, scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VISIBLE EN LIGNE' ;

Un exemple de sortie de cette requête sous charge est illustré dans la figure 3 ci-dessous.

Figure 3 – Planificateurs sous charge avec Enterprise Server+CAL

Vous pouvez également voir ce symptôme visuellement dans des outils de surveillance tels que SQL Sentry Performance Advisor :

Figure 4 – Déséquilibre NUMA comme indiqué dans SQL Sentry Performance Advisor

Ces informations montrent un déséquilibre important et les performances vont en être affectées. Cela est clairement évident dans le nombre de tâches exécutables pour les quatre planificateurs du deuxième nœud NUMA, qui sont trois à quatre fois plus grands que ceux des planificateurs du premier nœud NUMA. Quel est exactement le problème et pourquoi cela se produit-il ?

À première vue, vous pourriez penser qu'il s'agit d'un bogue dans SQL Server, mais ce n'est pas le cas. C'est quelque chose qui se produit par conception, même si je doute que ce scénario était prévu lorsque la limitation de 20 processeurs logiques a été initialement mise en œuvre. Sur les systèmes basés sur NUMA, les nouvelles connexions sont attribuées aux nœuds NUMA de manière circulaire, puis à l'intérieur du nœud NUMA, la connexion est attribuée à un planificateur en fonction de la charge. Si nous modifions la façon dont nous examinons ces données et agrégeons les données en fonction de parent_node_id, nous verrons que les tâches sont en fait équilibrées entre les nœuds NUMA. Pour ce faire, nous utiliserons la requête suivante, dont la sortie est illustrée à la figure 5.

SELECT parent_node_id, SUM(current_tasks_count) AS current_tasks_count, SUM(runnable_tasks_count) AS runnable_tasks_count, SUM(active_workers_count) AS active_workers_count, AVG(load_factor) AS avg_load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VISIBLE ONLINE'GROUP BY parent_node_id ; 

 
Figure 5 – Équilibrage circulaire du nœud NUMA 
 

 Ce comportement est documenté dans la documentation en ligne de SQL Server (http://msdn.microsoft.com/en-us/library/ms180954(v=sql.105).aspx). Sachant ce que je sais sur SQLOS, SQL Server et le matériel, cela a du sens. Avant la limitation de 20 processeurs logiques dans SQL Server 2012 Enterprise Edition avec licence Server+CAL, il était rare que SQL Server ait un déséquilibre de planificateur entre les nœuds NUMA dans un serveur de production. L'un des problèmes dans ce cas spécifique est la manière dont le NUMA virtuel a été transmis à la machine virtuelle. Effectuer exactement la même installation sur le matériel physique permet à tous les planificateurs d'être VISIBLES EN LIGNE puisque les processeurs logiques supplémentaires présentés par les hyperthreads se distinguent par SQL et sont gratuits.
 

 En d'autres termes, la limite de 20 processeurs logiques se traduit en réalité par 40 ordonnanceurs EN LIGNE si (a) il ne s'agit pas d'une machine virtuelle, (b) les processeurs sont Intel et (c) l'hyper-threading est activé. 
 

 Nous voyons donc ce message dans le journal des erreurs :
 Date    14/11/2012 22:36:18
Journal     Serveur SQL (Actuel :14/11/2012 22:36)
Serveur  source
Message
SQL Le serveur a détecté 2 sockets avec 8 cœurs par socket et 16 processeurs logiques par socket, 32 processeurs logiques au total ; utilisant 32 processeurs logiques basés sur les licences SQL Server. Ceci est un message informatif; Aucune action de l'utilisateur n'est requise. 

 Et la même requête que ci-dessus a pour résultat que les 32 processeurs sont VISIBLES EN LIGNE :
 
SELECT parent_node_id, [status], scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VISIBLE EN LIGNE' ;
 

 
Figure 6 – Même configuration sur le matériel physique 
 

 Dans ce cas, puisqu'il n'y a que 32 processeurs logiques, la limite de 20 (enfin, 40) cœurs ne nous affecte pas du tout, et le travail est réparti uniformément sur tous les cœurs.
 

 Dans les scénarios où la limitation de 20 processeurs affecte l'équilibre NUMA des planificateurs, il est possible de modifier manuellement la configuration du serveur pour équilibrer le nombre de planificateurs VISIBLE EN LIGNE dans chacun des nœuds NUMA grâce à l'utilisation de ALTER SERVER CONFIGURATION . Dans l'exemple de machine virtuelle fourni, la commande suivante configurera les 10 premiers processeurs logiques de chaque nœud NUMA sur VISIBLE EN LIGNE.
 
ALTER SERVER CONFIGURATIONSET PROCESS AFFINITY CPU =0 TO 9, 16 TO 25 ;
 

 Avec cette nouvelle configuration, exécutant la même charge de travail de 300 sessions et la charge de travail AdventureWorks Books Online, nous pouvons constater que le déséquilibre de charge ne se produit plus.
 

 
Figure 7 – Équilibre restauré avec configuration manuelle 
 

 Et encore une fois, en utilisant SQL Sentry Performance Advisor, nous pouvons voir la charge du processeur répartie plus uniformément sur les deux nœuds NUMA :
 

 
Figure 8 – Équilibre NUMA comme indiqué dans SQL Sentry Performance Advisor 
 

 Ce problème n'est pas strictement limité aux machines virtuelles et à la manière dont les processeurs virtuels sont présentés au système d'exploitation. Il est également possible de rencontrer ce problème avec du matériel physique. Par exemple, un ancien Dell R910 avec quatre sockets et huit cœurs par socket, ou même un serveur basé sur AMD Opteron 6200 Interlagos avec deux sockets et 16 cœurs par socket, qui se présente comme quatre nœuds NUMA avec huit cœurs chacun. Dans l'une ou l'autre de ces configurations, le déséquilibre du processus peut également entraîner la mise hors ligne complète de l'un des nœuds NUMA. Par conséquent, d'autres effets secondaires tels que la mémoire de ce nœud distribuée sur les nœuds en ligne, entraînant des problèmes d'accès à la mémoire étrangère, peuvent également dégrader les performances.
 
Résumé
 

 La configuration par défaut de SQL Server 2012 utilisant la licence Enterprise Edition pour Server+CAL n'est pas idéale dans toutes les configurations NUMA qui peuvent exister pour SQL Server. Chaque fois que la licence Enterprise Server + CAL est utilisée, la configuration NUMA et les statuts du planificateur par nœud NUMA doivent être examinés pour s'assurer que SQL Server est configuré pour des performances optimales. Ce problème ne se produit pas avec les licences basées sur les cœurs puisque tous les planificateurs sont sous licence et VISIBLES EN LIGNE.