Discussion :

[ApprentiJAVA]

Bonjour,

Nous rencontrons actuellement une lenteur sur un serveur virtualisé avec sqlserver 2016. Nous avons du mal à faire un delete sur 12 millions de lignes.

Sur le gestionnaire des tâches, il y a 8 CPU mais seules les 4 premières sont chargées, comme si les processeur 4 à 7 n'étaient pas utilisés par l'instance. Est-ce normal ?

Comment puis-je faire pour améliorer svp ?


Actuellement nous avons 8 socket pour 8 processeurs virtuels (voir image ci-dessous). Est ce que ça ne serait pas mieux d'avoir 1 socket pour 8 processeurs virtuels ?
Merci.

[KyoshiroKensei]

Bonjour,

Avez vous vérifié que tous les processeurs sont bien alloués à l'instance? Qu'est ce qui vous fait dire que la CPU est responsable du problème?

[ApprentiJAVA]

les processeurs :



C'est l'éditeur de l'appli qui pense que cela vient de la CPU et que les threads ne sont pas répartis sur les autres sockets.

J'ai toujours cru que la standard edition était limitée à 4 sockets.

[escartefigue]

Si le delete est très long, c'est possiblement non pas à cause de la CPU mais des accès disque.
12 millions de lignes, ce n'est pas énorme, mais s'il y a beaucoup d'index multiples, ça peut faire beaucoup plus.

Par ailleurs, le serveur devrait être dédié à SQL server, est-ce bien le cas ou bien y a-t-il d'autres applications sur ce serveur ?

[ApprentiJAVA]

il y a très peu d'index sur cette table. Il y a en 2 seulement.

j'ai jeté un oeil dans le moniteur d'activité. la requête est couteuse.

D'ailleurs, le plan d'exécution conseille de mettre un index :



le serveur est dédié à SQL Server. par contre il y a plusieurs instances. les autres instances ne rencontrent pas de problème.

J'ai également cela :

[KyoshiroKensei]

Le nombre de cpu dédié à l'instance est dispo dans les propriétés de l'instance. Si plusieurs instances, les ressources de la machines (cpu) sont partagées entre les instances, ce qui peut créer de la contention. Comme le dit escartefigue, il plus probable d'un problème d'accès disque que de cpu.

Si votre delete efface des données anciennes, alors les disques vont être utilisé pour rechercher les données puis pour les effacer. Vous pouvez également avoir d'autres requetes qui lock/ralentissent votre delete. Vous pouvez tenter l'index ou effacer par paquet plus petit pour voir les performances.

[SQLpro]

....
D'ailleurs, le plan d'execution conseille de mettre un index :

Commencez par le mettre ! Le gain est important. Il vous le dit !

le serveur est dédié à SQL Server. par contre il y a plusieurs instances. les autres instances ne rencontrent pas de probleme.

Il ne faut jamais mettre différentes instances sur une même machine. Cela n'a strictement aucun intérêt il y aura concurrence des ressources et vous dédoublez les exécutables, les métadonnées, les zones de diagnostics.....

Toutes vos bases peuvent tenir sur la même instance. En prod nous avons souvent plus de 100 bases sur une même machine. Géodis utilise 150 bases sur une même serveur avec plus de 20 To de données.... CDiscount, Veepee, Fnac.com ont plusieurs dizaines de TO sur une seule machine....

Il faut aussi régler la RAM utilisée par votre instance (qui doit être seule sur la machine) à 80 % de la RAM si égale ou plus de 32 Go

Il y a d'autres réglages...

A +

[SQLpro]

Bonjour,

Nous rencontrons actuellement une lenteur sur un serveur virtualisé avec sqlserver 2016. Nous avons du mal à faire un delete sur 12 millions de lignes.

Sur le gestionnaire des tâches, il y a 8 CPU mais seules les 4 premières sont chargées, comme si les processeur 4 à 7 n'étaient pas utilisés par l'instance. Est-ce normal ?

Il existe un guide de 82 pages sur les paramètres à mettre pour que SQL Server fonctionne correctement sur une VM VMWare. La plupart du temps, personne ne respecte le moindre des paramétrage de ce guide !
https://www.vmware.com/content/dam/d...ices-guide.pdf

Comment puis-je faire pour améliorer svp ?


Actuellement nous avons 8 socket pour 8 processeurs virtuels (voir image ci-dessous). Est ce que ça ne serait pas mieux d'avoir 1 socket pour 8 processeurs virtuels ?
Merci.

Ni l'un ni l'autre et il est normal que seul les 4 premiers CPU fonctionne. Les autres seront ignorés parce que votre configuration est bancale !

SQL Server version standard est limité à 4 CPU de 4 cœurs au maximum soit 16 cœurs au total (en machine physiques vous auriez droit à 32 cœurs du fait de l'hyperthreading.... Mais cela est impossible avec une VM !) Comme vous avez mis 8 CPU (socket) les 4 CPU numérotés 4, 5, 6, 7 sont ignorés et seul les CPU 0, 1, 2 et 3 sont utilisés....

Vous devez donc déclarer 2 CPU (sockets) ayant chacun 4 cœurs pour que SQL Server les prennent en compte....

Mais il n'y a pas que cela.... VMWare distribue des ressources (cœurs, ram, disques...) à d'autres machines. Il est impératif d'éviter cela en :

• Pour la RAM : fixer l'intégralité de la RAM à la VM SQL Server (Reservee All Guest Memory)
• Pour les CPU : fixer la réservation de fréquence des CPU à 92-95 % du total des cœurs et activer le mode turbo.

Pour ce dernier point par exemple si vous utilisez un processeur Intel Xeon Gold 5317 en fréquence de base 3 Ghz, vous devez réserver 3000 * 8 * 0.95 = 22 800 Mhz et après avoir activé le mode turbo (3,6 Ghz), réserver 27*360 Mhz...
Pour info, nous conseillons des CPU ayant au moins une fréquence nominale de 3,5 Ghz et plus de 4 en mode turbo pour utiliser SQL Server... En dessous c'est bon à foutre au chiotte ! C'est débile car vous payez des licences sur chaque processeurs.... Avec vos 8 CPU à 2,20 Ghz (soit une puissance de calcul de 17 600 Mhz) vous avez dépensé 12 000 € de licence versé à Microsoft, alors qu'avec un CPU Intel Xeon W9-3475X en mode turbo à 4,60 voire 4,80 (Turbo Boost Max 3) vous auriez plus de puissance de calcul (18 400 à 19 200 Mhz) avec seulement 4 cœurs en payant 6 000 € de licence !!!! (ce que je viens de m'offrir pour mes besoins perso... 32 cœurs soit 64 en hyperthreading...)

Vous devez enfin utiliser de préférences des disques "pass through" et non des disques virtuels et le formatage des disques doit être fait en 64 Ko.

Au n iveau de la RAM, le minimum aujourd'hui est de 32 Go.... Et beaucoup plus si grosses bases mal modélisées !

Enfin, il est extrêmement important d'avoir fait du "capacity planning" au niveau de tous les fichiers des bases de données SQL Server qui sont en fait des volumes UNIX...
En particulier dimensionner le journal de transaction pour éviter toute opération de croissances pendant la production...
En général je calcule le volume que la base va avoir entre 3 et 5 ans, je fixe cette valeur pour le fichier de données et je met 30% de cette valeur pour le JT.

Il existe évidemment beaucoup d'autres réglages et je vous invite à lire mon livre sur SQL Server....

A +