PLE faible sur le nœud NUMA 000, élevé sur 001

Je regarde PLE (Page Life Expectancy) à travers les nœuds NUMA sur nos serveurs SQL, et je suis tombé sur une distribution plutôt bizarre. Le nœud NUMA 000 a un PLE très faible par rapport à 001. Je ne sais pas pourquoi. J'ai vérifié plusieurs autres serveurs SQL Server dans notre environnement et les autres serveurs de production n'ont pas ce comportement.

Le système exécute SQL Server 2012 Enterprise Edition sur Dell m620 avec 256 Go de RAM. C'est une machine à 2 sockets, 6 cœurs (compatible HT). MAXDOP est réglé sur 6. Les modules de mémoire AFAIK sont installés uniformément sur les banques de mémoire des CPU

Quelque chose me dit que le nœud 000 de NUMA a d'autres tâches SQL à effectuer, que d'autres nœuds, mais j'ai oublié où je l'ai entendu / vu.

entrez la description de l'image ici

Image PLE

@@Version montre: Microsoft SQL Server 2012 (SP1) - 11.0.3412.0 (X64)

sql-server sql-server-2012 numa Kasper Brandenburg
la source

Le PLE à lui seul en dit peu. Il y a plus de compteurs comme Buffer Node et Memory Node qui peuvent éclairer un peu plus. Et finalement: y a-t-il un problème de performance, ou c'est juste une curiosité? Comment analyser les performances de SQL Server

Remus Rusanu

@RemusRusanu: Si nous avons un problème de performance entre nos mains, personne ne le sait :) je demande simplement par intérêt.

Kasper Brandenburg

Si vous voyez le compteur, stolen nodes memory KBsa valeur est 97G, ce qui est un IMO très élevé. La mémoire volée n'est pas utilisée à des fins de base de données, mais par SQL Server pour des opérations telles que le tri, le hachage et d'autres fins diverses. En revanche, la mémoire cible et la mémoire totale sont identiques. Cela semble étrange. Vous devez appliquer SP2 mais j'ai le sentiment que le PLE pourrait être mal calculé

Shanky

Bien. Nous pourrions aller voir SQL2014 au lieu d'installer SP2

Kasper Brandenburg

Réponses:

Si vous avez une requête à lecture intensive exécutée sur un nœud NUMA (dans ce cas, 0), elle peut connaître une durée de vie de page inférieure par rapport aux autres nœuds NUMA.

C'est tout à fait normal.

Pour voir quelles requêtes sont en cours d'exécution, vous pouvez utiliser l'excellent sp_WhoIsActive d'Adam Machanic . C'est totalement gratuit. Certaines personnes l'exécutent même toutes les X minutes et enregistrent les données dans une table afin de pouvoir revenir en arrière pour voir ce qui était en cours d'exécution au moment où PLE a plongé.

Brent Ozar
la source

-1

Ma compréhension de l'architecture NUMA est que chaque nœud s'isole à peu près. Dans ce cas, ils pourraient finir par faire un travail très différent. Par exemple, 0 pourrait exécuter des requêtes nécessitant beaucoup d'E / S physiques tandis que 1 a de la chance et trouve toutes ses données dans le pool de mémoire tampon.

SQL Nerd
la source