Utilisation très inégale du processeur avec SQL Server 2012 sur un ordinateur à 2 processeurs avec 16 cœurs / processeur

Après avoir installé SQL Server Enterprise 2012 avec le modèle de licence Server + Cal, sur un ordinateur avec 2 processeurs chacun avec 16 cœurs (et sans hyperthreading impliqué) et mis le serveur sous une charge extrêmement lourde, les 16 cœurs du premier processeur étaient très sous-utilisés, le les 4 premiers cœurs du 2e processeur ont été largement utilisés et les 12 derniers cœurs n'ont pas été utilisés du tout (en raison de la limite de 20 cœurs pour cette version de serveur SQL). L'utilisation totale du processeur affichait environ 25%. Malheureusement, le serveur a souffert de performances extrêmement médiocres, même si les tâches étaient réparties uniformément sur les 20 cœurs, cela n'aurait pas été aussi mauvais.

Le serveur Windows s'exécutait sur une image virtuelle VMWare sous ESX Server, mais tout le processeur était alloué au serveur Windows.

Nous avons essayé de modifier les paramètres d'affinité (par exemple, allouer la plupart des cœurs au processeur et les autres aux E / S), mais cela n'a pas aidé à résoudre les problèmes de performances.

La mise à niveau de l'édition du produit vers SQL Server Enterprise Core 2012 a non seulement permis à SQL Server d'utiliser les 12 cœurs précédemment inutilisés sur le 2e processeur, mais a également entraîné une distribution beaucoup plus uniforme des tâches sur tous les processeurs. Pour surmonter l'arriéré des demandes, l'utilisation de l'unité centrale de traitement est passée à environ 90%, puis à environ 33% une fois qu'elle a été rattrapée, mais les performances se sont considérablement améliorées depuis que nous sommes passés à la nouvelle version mise à jour et les problèmes de performances ont disparu.

Je me demandais si quelqu'un savait ce qui pouvait provoquer une répartition inégale de la charge par SQL Server, en s'appuyant presque exclusivement sur les 4 premiers cœurs du 2e processeur qui avait 12 cœurs inactifs et en allouant seulement quelques tâches à chacun des 16 cœurs du premier processeur. De plus, existe-t-il un moyen de répartir plus uniformément la charge sur les 20 cœurs utilisés sans la mise à niveau de l'édition du produit?

Le revers de cette question est: qu'est-ce que la mise à niveau du produit a fait pour que SQL Server commence à répartir uniformément la charge sur tous les cœurs qu'il a reconnus?

Merci à toutes les informations pour répondre à ces questions et / ou liens qui pourraient m'aider à mieux comprendre comment donner un sens à ce qui se passait.

Les performances inégales étaient probablement une combinaison de la limite de 20 cœurs combinée à la façon dont le serveur SQL planifie les threads sur les machines NUMA. Malheureusement, SQL Server 2012 n'utilise aucune intelligence pour décider des 20 cœurs à utiliser, ce qui entraîne un nombre déséquilibré de cœurs par nœud NUMA. Avec 32 cœurs répartis sur 2 nœuds NUMA, vous vous retrouverez probablement avec une répartition 16/4. Cela est problématique car SQL essaiera d'équilibrer l'activité de manière égale entre les nœuds NUMA de manière circulaire (en supposant que vous ne forcez pas l'affinité avec le gouverneur de ressources).

Dans votre cas, la moitié de la charge est affectée à 4 cœurs et la moitié à 16 cœurs. Le goulot d'étranglement sur le nœud à 4 cœurs agit efficacement comme un étranglement, limitant la capacité de la machine à 2 x 4 cœurs = 8 cœurs = 25% d'utilisation du processeur.

Une fois que vous avez mis à niveau vers l'édition principale, sql a utilisé les 32 cœurs sur 2 nœuds numa (16/16). Amélioration des performances, etc.

Une option qui aurait pu améliorer vos performances aurait été d'utiliser le gouverneur de ressources du serveur SQL pour affiniter la majorité de votre charge de travail sur un nœud numa. Par exemple, vous pouvez créer un pool de ressources WEB_APP et l'affiniter pour qu'il ne s'exécute que sur le nœud numa 16 core. La charge affectée au pool WEB_APP pourrait utiliser 50% de la capacité du serveur, plus la capacité restante de 12,5% du nœud à 4 cœurs.

L'autre option serait de limiter le nombre de cœurs disponibles au serveur SQL à 10 seulement pour chaque nœud numa.