Pb performances SQL 2008 x64

[cthugha34]

Bonjour
Je rencontre des problèmes de performance sous SQL2008 R2.

J'ai une requête (générée par Analysis services) qui renvoie un nombre relativement important de lignes (> 3M)

Lorsque cette requête est exécutée sur un serveur 32bit (2K, 2K5 ou 2K8) elle prend environ 5min.

Lorsque je l'exécute sur un serveur 2K8 64bits, même base donc même nombre de lignes en sortie, elle prend 2h15 et occupe la totalité des processeurs.

Après de nombreuses recherches et quelques pistes (utilisation d'indexs non clustered, gestion de la mémoire...) je ne parviens toujours pas à isoler le problème.

Quelqu'un aurait-il une idée?

Merci par avance.

[dbaffaleuf]

Essayer de forcer la sérialisation du plan

Code :

1
2
3
SELECT 
...
OPTION (MAXDOP 1)

[cthugha34]

Envoyé par dbaffaleuf

Essayer de forcer la sérialisation du plan

Code :

Merci de votre réponse.
Ce n'est pas mieux.
La charge processeur est moins importante en limitant le parallélisme mais les temps de réponse sont identiques.
En fait lorsque j'exécute la requete sur le serveur x64, elle commence à renvoyer des lignes très rapidement (après 10sec de traitement) mais les renvoie par petits lots de 60 lignes.
Alors que sur le serveur 32bits la requetes s'exécute pendant environ 2min avant de renvoyer le résultat mais affiche ensuite la totalité des lignes en moins de 3min

[mikedavem]

Quelle configuration sur votre serveur 32 bits ? (CPU, RAM, version OS etc ..)
Même chose sur votre serveur 64 bits ?

Quel est le plan d'exécution généré dans les 2 cas ?
Quelles sont les statistiques d'exécution générées dans les 2 cas ? (SET STATISTICS TIME ON .. SET STATISTICS IO ON)

++

[iberserk]

D'ou exécutez vous vos 2 requêtes? sur SSMS en local sur chaque serveur?

[elsuket]

Bonjour,

Il est aussi possible que les jointures se fassent sur des colonnes de type int (4 octets), ce qui n'est pas pour aider sur un processeur 64 bits.

Si c'est le cas, il faudrait passer en bigint (8 octets), et voir l'effet ...
Pas forcément simple à faire

3 millions de lignes et SSAS ... construiriez-vous un cube ?

@++

[mikedavem]

Envoyé par elsuket

Il est aussi possible que les jointures se fassent sur des colonnes de type int (4 octets), ce qui n'est pas pour aider sur un processeur 64 bits.

Ah bon ? Pourtant un processeur 64 bits acceptera des mots de 8 octets. Il pourra donc en théorie traiter 2 INT plus rapidement qu'un processeur 32 bits.

Si c'est le cas, il faudrait passer en bigint (8 octets), et voir l'effet ...

Cela voudrait donc dire qu'il faudrait plus de stockage pour les clés et donc ramener plus de pages pour traiter l'information ...

++

[dbaffaleuf]

Pour pouvoir comparer, il faut voir les deux plans.

Sur chaque environnement:

Code :

1
2
3
4
SET showplan_text ON
GO
SELECT ....
GO

Merci,

[iberserk]

Envoyé par elsuket
Il est aussi possible que les jointures se fassent sur des colonnes de type int (4 octets), ce qui n'est pas pour aider sur un processeur 64 bits.

Ah bon ? Pourtant un processeur 64 bits acceptera des mots de 8 octets. Il pourra donc en théorie traiter 2 INT plus rapidement qu'un processeur 32 bits.


Citation:
Si c'est le cas, il faudrait passer en bigint (8 octets), et voir l'effet ...

Cela voudrait donc dire qu'il faudrait plus de stockage pour les clés et donc ramener plus de pages pour traiter l'information ...

++
__________________

L'éternel débat, mettre la même taille de clé que la taille du processeur ou privilégier les pages gagnées avec la taille moindre?


Personnelement je 'taille' mes clefs pour la volumétrie sans tenir compte de la taille du processeur.

Il faudrait faire des tests approfondis.

[SQLpro]

Tu n 'as pas entièrement tort. C'était plus sensible en 2000 qu'en 2005. Dans mon cours à Orsys je montrais que même un SMALLINT dans un OS 32 bits perdait de 5 à 10% de temps pour vérifier les bits de poids haut, ce qui n'est plus le cas dans 2005.

A +

[mikedavem]

Il y a aussi l'architecture des processeurs à prendre en compte. Les caches internes L2 et L3 peuvent être un point de contention sur certains processeurs 64 bits alors que sur des architectures 32 bits le problème ne sera pas forcément présent. Le fameux CPI (Cost Per Instruction).

Il y a aussi les problèmes liés à l'alignement des données en mémoire et qui sont lues par les processeurs et qui sont plus sensibles pour des architectures 32 bits que 64 bits mais bon en principe les processeurs actuels règlent ce problème en ajoutant des bits supplémentaires pour forcer cet alignement.

Il y a des cas où passer de 32 bits à 64 bits n'est pas forcément gage de performances (j'ai pû le constater d'ailleurs chez un client). Cela dépend à mon avis de la charge (requêtes) et des caractéristiques physiques du serveur.

Lorsque cette requête est exécutée sur un serveur 32bit (2K, 2K5 ou 2K8) elle prend environ 5min.

Lorsque je l'exécute sur un serveur 2K8 64bits, même base donc même nombre de lignes en sortie, elle prend 2h15 et occupe la totalité des processeurs.

Encore une fois (et comme le disait aussi dbaffaleuf) il faudrait pouvoir comparer les 2 plans d'exécutions , voir ce qui prend le plus de temps et éventuellement comparer les config de serveur.

++