Discussion :

[NULL008]

hello ,

Est ce que l'Edition standard est limité sur le nbre du cœur détectable pendant le démarrage du Windows server

Si oui comment je peut récupérer cette information

cordialement

[mikedavem]

La règle pour l'édition standard est la suivante:

4 sockets physiques max ou 24 coeurs

Tu peux utiliser la requête suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT 
	cpu_count,
	hyperthread_ratio,
	cpu_count / hyperthread_ratio AS [Physical CPU Count]
FROM sys.dm_os_sys_info

Attention cependant aux environnements virtualisés qui ne te montrent pas l'implémentation réelle de l'infrastructure sous-jascente.
Autre tip, avec VMWare par exemple, tu peux tout à fait décider du nombre de coeurs par socket comme tu l'entends. Le gros piège de certains environnements que j'ai vu étaient de configurer plus de 4 sockets et donc le surplus était non exploitable par SQL Server du fait de la limitation citée plus haut.

++

[SQLpro]

La règle pour l'édition standard est la suivante:

4 sockets physiques max ou 24 coeurs

Je peut pas te laisser dire ça parce que c'est faux !!!

la limite est de 4 sockets physiques de 6 cœurs, soit au plus 24 cœurs...

Récemment sur une VM, un de mes clients à mis 8 socket de 1 cœur. Bilan des opérations, serveur bancal, performances cata....

A +

[mikedavem]

Citation Envoyé par mikedavem Voir le message
La règle pour l'édition standard est la suivante:

4 sockets physiques max ou 24 coeurs

...

Je peut pas te laisser dire ça parce que c'est faux !!!

la limite est de 4 sockets physiques de 6 cœurs, soit au plus 24 cœurs...

Je suis sûrement fatigué mais est-ce qu'on est pas en train de dire la même chose ici ?

Récemment sur une VM, un de mes clients à mis 8 socket de 1 cœur. Bilan des opérations, serveur bancal, performances cata....

Bien probable en effet, surtout si le système voit 8 sockets, alors SQL n'en n'utilisera que 4 .... chez le client qui avait cette config sur VMWare on voyait un nb de schedulers VISIBLE à 4 au lieu de 8.

++

[SQLpro]

En conclusion, c'est un peu plus sioux que ta phrase :

"4 sockets physiques max ou 24 cœurs"

A +

[hmira]

La phrase telle qu’elle est extraite du BOL est la suivante :
"Limited to lesser of 4 sockets or 24 cores"

Dans sa version française du BOL, elle est traduite, peut être incorrectement, en :
"Limité à moins de 4 sockets ou 24 cœurs"

Est-ce que la traduction exacte ne serait-elle pas la suivante ?
"Limité à la plus petite des deux valeurs suivantes : 4 sockets ou 24 cœurs"

Qui ne me parait pas clair non plus, puisqu'on compare les torchons et les serviettes et on ne précise nul part, du moins dans le BOL, la notion ou le chiffre de 6 cœurs par sockets (?).

[mikedavem]

Qui ne me parait pas clair non plus, puisqu'on compare les torchons et les serviettes et on ne précise nul part, du moins dans le BOL, la notion ou le chiffre de 6 cœurs par sockets (?).

A mon sens on parle bien de la même chose mais sous différents points de vue (concept physique ou logique).

De manière générale toute édition SQL Server possède 2 limites de capacité:
- Nombre de sockets physiques
- Nombre de coeurs reportés par le système d'exploitation

La limite du nombre de coeurs varie en fonction du type d'environnement (eh oui la virtualisation est arrivée entre temps ..):
- Coeurs pour une implémentation physique
- Processeurs logiques pour une implémentation virtuelle. Processeur logique inclut ici coeur + hyperthreading si celui-ci est activé.

Pour exemple un serveur à base d'Intel® Xeon® Gold 5222:
- 1 socket avec 4 coeurs et si hyperthreading activé 8 threads. Sur un environnement virtuel, ce nombre de threads représenterait le nombre de coeurs logiques vu par le système et SQL Server se baserait sur ce nombre pour la limitation. En revanche, sur une implémentation physique c'est le nombre de coeurs indépendement du nb de threads.

Qui ne me parait pas clair non plus, puisqu'on compare les torchons et les serviettes et on ne précise nul part, du moins dans le BOL, la notion ou le chiffre de 6 cœurs par sockets (?).

Parce qu'il n'existe aucune limitation basée sur 6 coeurs par socket.

1) Si je reprends mon exemple à base d'Intel® Xeon® Gold 5222. En assumant de ne pas activer l'hyperthreading, prenons un scénario avec 6 sockets x 4 coeurs = 24 coeurs.
Dans ce cas, c'est la 1ère limitation physique qui s'imposerait et SQL Server ne serait pas capable d'utiliser 2 sockets au délà de la limite des 4. SQL Server sera limité à utiliser 4 x 4 coeurs soit 16 coeurs.

2) Prenons l'exemple d'une implémentation à base de Intel® Xeon® Gold 6250. En assumant toujours de ne pas activer l'hyperthreading pour simplifier le raisonnement, prenons un scénario avec 4 sockets x 8 coeurs (de base sur ce modèle de processeur). Dans ce 2ème cas, c'est la 2ème limite qui s'imposerait avec un nombre de coeurs maximum fixé à 24, soit 8 processeurs non exploitées par SQL Server.

3) Dans le cas des environnements virtuels, c'est l'hyperviseur qui expose la topologie processeur et ne fonction de l'activation de l'hyperthreading, c'est le nombre de coeurs logiques (nb de threads total) exposées par le système d'exploitation qui ferait foi.

++

[SQLpro]

C'est même bien pire... Reprenons !

...
1) Si je reprends mon exemple à base d'Intel® Xeon® Gold 5222. En assumant de ne pas activer l'hyperthreading, prenons un scénario avec 6 sockets x 4 coeurs = 24 coeurs.
Dans ce cas, c'est la 1ère limitation physique qui s'imposerait et SQL Server ne serait pas capable d'utiliser 2 sockets au délà de la limite des 4. SQL Server sera limité à utiliser 4 x 4 coeurs soit 16 coeurs.

Le problème est de savoir comment il limite la chose et là je crois me souvenir que les exécutables de SQL Server vont pouvoir utiliser tous 24 cœurs, mais le moteur SQL comme le moteur de stockage n'utilisera que 16 coeurs ! M'est avis qu'on peut le voir en s'amusant à faire des BULK INSERT ou de la sauvegarde...

En tout cas, le système sera fortement bancal

A +

[hmira]

Merci beaucoup mikedavem pour tes explications très détaillées et très claires.

Maintenant, personnellement, j’utilise la requêtes ci-dessous, sous SQL Server 2017, pour afficher et contrôler ces informations
J’ai rajouté dans la requête la colonne ci-dessous, extraite de ta requête SQL postée ci-haut
cpu_count / hyperthread_ratio AS [Physical CPU Count] -- colonne mikedavem

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
SELECT	  hyperthread_ratio  as Hyperthread_Ratio
	, socket_count       as Socket_Count
	, cpu_count          as Logical_CPU_Count
	, cores_per_socket   as Cores_per_Socket
	, (socket_count * cores_per_socket) as Physical_Core_Count
	, (cpu_count / hyperthread_ratio)  as Physical_CPU_Count   -- colonne mikedavem
	, cores_per_socket as Cores_per_Socket
	, scheduler_count    as Scheduler_Count
	, virtual_machine_type_desc as Virtual_Machine_Type
FROM sys.dm_os_sys_info

Maintenant, la question est d’établir le rapprochement, entre les concepts très clair que tu as exposés et les colonnes de la vue systèmes sys.dm_os_sys_info en faisant, si cela s’avèrerait nécessaire, la distinction entre les environnements virtualisés et les environnements non virtualisé. En d’autres termes, l’interprétation des colonnes de la vue système sys.dm_os_sys_info serait-elle différente selon que l’environnement est virtualisé ou pas ? Ou bien, peut-on se fier à la valeur de ces colonnes, et ce, quel que le type d’environnement virtualisé ou pas ?

Merci.

[SQLpro]

...
Maintenant, la question est d’établir le rapprochement, entre les concepts très clair que tu as exposés et les colonnes de la vue systèmes sys.dm_os_sys_info en faisant, si cela s’avèrerait nécessaire, la distinction entre les environnements virtualisés et les environnements non virtualisé. En d’autres termes, l’interprétation des colonnes de la vue système sys.dm_os_sys_info serait-elle différente selon que l’environnement est virtualisé ou pas ? Ou bien, peut-on se fier à la valeur de ces colonnes, et ce, quel que le type d’environnement virtualisé ou pas ?

Non la virtualisation ne change rien à la chose puisque dans ta VM tu peut opter pour 8 sockets de 1 cœurs ou bien 8 cœurs sur un seul socket, auxquels cas, SQL Server fonctionnera de manière bancale en version standard...

A +

[hmira]

Non la virtualisation ne change rien à la chose puisque dans ta VM tu peut opter pour 8 sockets de 1 cœurs ou bien 8 cœurs sur un seul socket, auxquels cas, SQL Server fonctionnera de manière bancale en version standard...

A +

OK. Merci SQLPro pour cette précision .

Concernant l’éventuel fonctionnement bancal, je laisse à l’auteur principal de cette discussion, le soin de prendre les précautions nécessaires pour éviter un tel fonctionnement.

A+