Pires performances sur un nouveau serveur

Nous avons été sur un serveur dédié (quadricœur unique, 6 Go de RAM) et passons à un nouveau serveur dédié (2x hex-core, 32 Go de RAM). Les deux sont Windows Server 2008, SQL Server 2008. Les performances sur le nouveau serveur sont légèrement inférieures à celles de l'ancien serveur plus lent.

Lors des tests, notre application ASP.NET s'exécute 10 à 20% plus lentement. L'exécution de requêtes coûteuses individuelles avec STATISTICS IO et STATISTICS TIME indique une augmentation de 10 à 20% du temps écoulé sur le nouveau serveur. Le profil de requête SQL montre une utilisation plus élevée du processeur pour les requêtes coûteuses.

Le Gestionnaire des tâches sur le nouveau serveur montre que sqlserver.exe consomme 22 Go de RAM, mais les valeurs du processeur restent toujours très faibles.

J'ai mis à jour toutes les statistiques, les index reconstruits ou réorganisés, etc. Les plans d'exécution doivent être stockés sur le nouveau serveur à ce stade, compte tenu de la quantité de tests que j'ai effectués. S'il y a des index manquants (je ne pense pas qu'il y en ait), ils affectent également les anciens et les nouveaux serveurs. Nouveau a une sauvegarde restaurée des mêmes données sur l'ancien.

Je m'attendais à ce que les performances sur le nouveau serveur soient meilleures, mais la charge est plus préoccupante. Si l'ancien serveur fonctionne mieux même sous charge, que se passera-t-il lorsque ce nouveau serveur légèrement pire devra prendre cette charge?

Que pouvais-je manquer d'autre ici?

EDIT: MAXDOP réglé sur 6.

L'ancien serveur a un système d'exploitation, des bases de données et des tempdb sur les mêmes disques physiques (RAID 10). Un total de 4 disques SAS 15 pouces 3 Gbits / s 3,5 pouces. Le nouveau serveur dispose de trois ensembles de disques: OS sur RAID 1, base de données sur RAID 10, tempdb sur RAID 5. Total de 9 SAS 15 pouces 6 Gbits / s 2,5 pouces.

L'ancien serveur possède 1 x Intel Xeon E5620 2,40 GHz Quad-Core 8 Threads (w H / T). Le nouveau serveur possède 2 x Intel Xeon E5-2640 2,5 GHz à six cœurs 12 fils (avec H / T).

EDIT 2: Voici l'analyse finale:

Le plan d'alimentation était basé sur des performances équilibrées et non sur des performances élevées. Commuté cela.

Tempdb était sur un RAID 5, pas sur RAID 10. Ajout d'un autre disque dur pour créer deux configurations RAID 10 physiquement distinctes, une pour tempdb et une pour tout le reste.

Exclusion de fichiers liés à SQL (mdf, ldf, ndf, bak) de l'analyse antivirus.

Reconstruit tous les index après le passage au nouveau serveur. Ils étaient très fragmentés - peut-être à cause de la sauvegarde, de la copie, de la restauration?

Et j'ai réalisé que le saut du processeur n'était pas si grand. Les requêtes ne vont pas s'exécuter beaucoup plus rapidement, mais avec plus de processeurs, plus de cœurs, plus de RAM, nous serons plus évolutifs.

Le raid 5 est plus lent que le raid 10, en particulier pour les charges de travail lourdes en écriture. En tant que tel, il n'est généralement pas recommandé pour SQL Server et certainement pas pour tempdb. Cela seul pourrait facilement expliquer la différence de performances.

Ma recommandation serait de déplacer tempdb vers le raid 10.

Il s'agit d'un problème très général, il est donc difficile de donner un conseil spécifique. Mais, si j'étais dans cette situation, je commencerais par les bases, vérifier les requêtes les plus chères. Quelle fonctionnalité prend plus de temps? Qu'est-ce qui consomme le plus de temps ce que vous exécutez des requêtes avec le temps des statistiques? Une fois que vous avez un peu réduit votre concentration, vous pouvez comparer les choses avec l'ancien serveur. En outre, il convient de vérifier que les deux serveurs sont au même niveau de correctif (SQL et Windows).

Eh bien, vous ne dites rien de vos disques durs et du nombre de fichiers tempdb dont vous disposez. Il y a une recommandation générale que nr de tempdbs = nombre de cœurs jusqu'à 32, il y a aussi un interrupteur à lancer pour s'assurer que les temp dbs sont utilisés également.

Cependant, en profondeur: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-%281230%29-tempdb-should-always-have-one-data- file-per-processor-core.aspx avez-vous également modifié le conditionnement des tables et des index lors de la migration? La sauvegarde et la restauration peuvent finir par défaut avec un remplissage différent sur les index (y compris ceux en cluster)