Schlechtere Leistung auf einem neuen Server

Wir waren auf einem dedizierten Server (Single Quad-Core, 6 GB RAM) und wechseln auf einen neuen dedizierten Server (2x Hex-Core, 32 GB RAM). Beide sind Windows Server 2008 und SQL Server 2008. Die Leistung auf dem neuen Server ist etwas schlechter als auf dem alten, langsameren Server.

Beim Testen läuft unsere ASP.NET-Anwendung 10 bis 20% langsamer. Wenn Sie einzelne teure Abfragen mit STATISTICS IO und STATISTICS TIME ausführen, wird auf dem neuen Server eine um 10 bis 20% längere verstrichene Zeit angezeigt. Das SQL-Abfrageprofil zeigt eine höhere CPU-Auslastung bei teuren Abfragen.

Der Task-Manager auf dem neuen Server zeigt, dass sqlserver.exe 22 GB RAM verbraucht, die CPU-Werte jedoch immer sehr niedrig bleiben.

Ich habe alle Statistiken, neu erstellten oder neu organisierten Indizes usw. aktualisiert. Ausführungspläne sollten zu diesem Zeitpunkt auf dem neuen Server gespeichert werden, da ich viele Tests durchgeführt habe. Wenn Indizes fehlen (ich glaube nicht), wirken sie sich gleichermaßen auf den alten und den neuen Server aus. Neu hat eine wiederhergestellte Sicherung der gleichen Daten auf dem alten.

Ich hatte erwartet, dass die Leistung auf dem neuen Server besser sein würde, aber die Last ist besorgniserregender. Wenn der alte Server auch unter Last eine bessere Leistung erbringt, was passiert dann, wenn dieser neue, etwas schlechtere Server diese Last aufnehmen muss?

Was könnte ich hier noch vermissen?

EDIT: MAXDOP auf 6 gesetzt.

Der alte Server verfügt über Betriebssysteme, Datenbanken und Tempdbs auf denselben physischen Laufwerken (RAID 10). Insgesamt 4 15k 3 Gb / s 3,5 Zoll SAS. Der neue Server verfügt über drei Laufwerkssätze: Betriebssystem unter RAID 1, Datenbank unter RAID 10, Tempdb unter RAID 5. Insgesamt 9 15 KB 6 Gbit / s 2,5-Zoll-SAS.

Der alte Server verfügt über 1 x Intel Xeon E5620 2,40 GHz Quad-Core 8-Threads (mit H / T). Der neue Server verfügt über 2 x Intel Xeon E5-2640 2,5-GHz-Sechs-Kern-12-Threads (mit H / T).

EDIT 2: Hier ist die endgültige Analyse:

Der Energieplan war ausgewogen und nicht leistungsstark. Schaltete das um.

Tempdb befand sich auf einem RAID 5, nicht auf RAID 10. Es wurde eine weitere Festplatte hinzugefügt, um zwei physisch unterschiedliche RAID 10-Konfigurationen zu erstellen, eine für Tempdb und eine für alles andere.

SQL-bezogene Dateien (mdf, ldf, ndf, bak) wurden vom Virenscan ausgeschlossen.

Alle Indizes nach dem Wechsel auf den neuen Server neu erstellt. Sie waren sehr fragmentiert - möglicherweise als Ergebnis von Sicherung, Kopie, Wiederherstellung?

Und mir wurde klar, dass der Prozessorsprung nicht so groß war. Die Abfragen werden nicht viel schneller ausgeführt, aber mit mehr Prozessoren, mehr Kernen und mehr RAM sind wir skalierbarer.

Raid 5 ist langsamer als Raid 10, insbesondere für schreibintensive Workloads. Daher wird es im Allgemeinen nicht für SQL Server und schon gar nicht für Tempdb empfohlen. Dies allein könnte den Leistungsunterschied leicht erklären.

Meine Empfehlung wäre, tempdb auf Raid 10 zu verschieben.

Dies ist ein sehr allgemeines Problem, daher ist es schwierig, einen spezifischen Rat zu geben. Aber wenn ich in dieser Situation wäre, würde ich von den Grundlagen ausgehen und die teuersten Abfragen überprüfen. Welche Funktionalität dauert länger? Was kostet die meiste Zeit, wenn Sie Abfragen mit Statistikzeit ausführen? Sobald Sie Ihren Fokus ein wenig eingegrenzt haben, können Sie die Dinge mit dem alten Server vergleichen. Außerdem muss überprüft werden, ob sich beide Server auf derselben Patch-Ebene befinden (SQL und Windows).

Nun, Sie sagen nichts über Ihre Festplatten und die Anzahl der Tempdb-Dateien, die Sie haben. Es gibt eine allgemeine Empfehlung, dass nr von tempdbs = Anzahl von Kernen bis zu 32, es gibt auch einen Schalter zu werfen, um sicherzustellen, dass die temp dbs gleichermaßen verwendet werden.

Jedoch ausführlich: 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 haben Sie auch das Packen für Tabellen und Indizes während der Migration geändert? Für das Sichern und Wiederherstellen wird möglicherweise standardmäßig ein anderer Abstand für Indizes (einschließlich Clustered) verwendet.