Gorsza wydajność na nowym serwerze

Jesteśmy na dedykowanym serwerze (pojedynczy czterordzeniowy, 6 GB pamięci RAM) i przechodzimy na nowy serwer dedykowany (2x sześciordzeniowy, 32 GB pamięci RAM). Oba systemy to Windows Server 2008, SQL Server 2008. Wydajność na nowym serwerze jest nieco gorsza niż na starym, wolniejszym serwerze.

Podczas testowania nasza aplikacja ASP.NET działa o 10-20% wolniej. Uruchamianie pojedynczych kosztownych zapytań za pomocą STATISTICS IO i STATISTICS TIME pokazuje o 10-20% dłuższy czas, który upłynął na nowym serwerze. Profil zapytania SQL pokazuje większe użycie procesora w przypadku kosztownych zapytań.

Menedżer zadań na nowym serwerze pokazuje, że sqlserver.exe zużywa 22 GB pamięci RAM, ale wartości procesora zawsze pozostają bardzo niskie.

Zaktualizowałem wszystkie statystyki, przebudowałem lub zreorganizowałem indeksy itp. Plany wykonania powinny być w tym momencie przechowywane na nowym serwerze, biorąc pod uwagę ilość testów, które wykonałem. Jeśli brakuje jakichś indeksów (nie sądzę, by istniały), wpływają one w równym stopniu na stary i nowy serwer. Nowy ma przywróconą kopię zapasową tych samych danych na starym.

Spodziewałem się, że wydajność na nowym serwerze będzie lepsza, ale bardziej niepokojące jest obciążenie. Jeśli stary serwer działa lepiej nawet pod obciążeniem, to co się stanie, gdy ten nowy, nieco gorszy serwer będzie musiał wziąć to obciążenie?

Czego jeszcze mógłbym tutaj brakować?

EDYCJA: MAXDOP ustawiony na 6.

Stary serwer ma system operacyjny, bazy danych i tempdb na tych samych dyskach fizycznych (RAID 10). Łącznie 4 15k 3 Gb / s 3,5 cala SAS. Nowy serwer ma trzy zestawy napędów: system operacyjny na RAID 1, baza danych na RAID 10, tempdb na RAID 5. Łącznie 9 15K 6 Gb / s 2,5 cala SAS.

Stary serwer ma 1 x czterordzeniowy 8 wątków Intel Xeon E5620 2,40 GHz (w H / T). Nowy serwer ma 2 x sześciordzeniowy rdzeń Intel Xeon E5-2640 2,5 GHz 2,5 GHz (w H / T).

EDYCJA 2: Oto końcowa analiza:

Plan zasilania opierał się na zrównoważonym, niezbyt wysokim poziomie wydajności. Przełączyłem to.

Tempdb był na RAID 5, a nie RAID 10. Dodano kolejny HD, aby utworzyć dwie fizycznie odrębne konfiguracje RAID 10, jedną dla tempdb i jedną dla wszystkiego innego.

Wykluczono pliki związane z SQL (mdf, ldf, ndf, bak) ze skanowania w poszukiwaniu wirusów.

Przebudowano wszystkie indeksy po przejściu na nowy serwer. Były bardzo rozdrobnione - być może w wyniku tworzenia kopii zapasowych, kopiowania, przywracania?

I zdałem sobie sprawę, że skok procesora nie był tak duży. Kwerendy nie będą wykonywane o wiele szybciej, ale przy większej liczbie procesorów, większej liczbie rdzeni, większej ilości pamięci RAM będziemy bardziej skalowalni.

Raid 5 jest wolniejszy niż raid 10, szczególnie w przypadku dużych obciążeń związanych z zapisem. Jako taki nie jest ogólnie zalecany dla serwera SQL, a na pewno nie dla tempdb. Już to samo może łatwo wyjaśnić różnicę wydajności.

Radzę przenieść tempdb na raid 10.

Jest to bardzo ogólny problem, dlatego trudno jest udzielić konkretnej porady. Ale gdybym był w takiej sytuacji, zacznę od podstaw, sprawdzę najdroższe zapytania. Jaka funkcjonalność trwa dłużej? Co pochłania najwięcej czasu na uruchamianie zapytań ze statystykami? Po ograniczeniu uwagi możesz porównać rzeczy ze starym serwerem. Warto również sprawdzić, czy oba serwery są na tym samym poziomie łatek (SQL i Windows).

Cóż, nie mówisz nic o swoich dyskach twardych i liczbie posiadanych plików tempdb. Istnieje ogólna rekomendacja, że ​​liczba tempdbs = liczba rdzeni do 32, istnieje również przełącznik do rzucania, aby zapewnić równomierne użycie temp dbs.

Jednak niezależność: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-%281230%29-tempdb-should-always-have-one-data- plik-na-procesor-rdzeń.aspx również zmieniłeś pakowanie tabel i indeksów podczas migracji? Kopie zapasowe i przywracanie może zakończyć się domyślnym stosowaniem innego wypełnienia indeksów (w tym indeksów klastrowych)