Хуже производительность на новом сервере

Мы были на выделенном сервере (одноядерный, 6 ГБ ОЗУ) и переходим на новый выделенный сервер (2x шестнадцатеричный, 32 ГБ ОЗУ). Оба Windows Server 2008, SQL Server 2008. Производительность на новом сервере немного хуже, чем на старом, более медленном сервере.

При тестировании наше приложение ASP.NET работает на 10 - 20% медленнее. Выполнение отдельных дорогостоящих запросов с STATISTICS IO и STATISTICS TIME показывает на 10–20% больше времени, прошедшего на новом сервере. Профиль SQL-запросов показывает более высокую загрузку ЦП при дорогих запросах.

Диспетчер задач на новом сервере показывает, что sqlserver.exe использует 22 ГБ ОЗУ, но значения ЦП всегда остаются очень низкими.

Я обновил всю статистику, перестроил или реорганизовал индексы и т. Д. На этом этапе планы выполнения должны храниться на новом сервере, учитывая количество проведенных испытаний. Если есть какие-либо отсутствующие индексы (я не думаю, что они есть), они одинаково влияют на старый и новый серверы. Новый имеет восстановленную резервную копию тех же данных на старых.

Я ожидал, что производительность на новом сервере будет лучше, но больше беспокоит нагрузка. Если старый сервер работает лучше даже под нагрузкой, то что произойдет, когда этот новый, немного худший сервер должен принять эту нагрузку?

Что еще я мог здесь упустить?

РЕДАКТИРОВАТЬ: MAXDOP установлен на 6.

Старый сервер имеет ОС, базы данных и базы данных tempdb на тех же физических дисках (RAID 10). Всего 4 15k 3 Гбит / с 3,5-дюймовый SAS. Новый сервер имеет три набора дисков: ОС на RAID 1, база данных на RAID 10, база данных tempdb на RAID 5. Всего 9 15K 6 Гбит / с 2,5-дюймовый SAS.

Старый сервер имеет 1 процессор Intel Xeon E5620 2,40 ГГц Quad-Core 8 Threads (с В / В). Новый сервер оснащен 2-мя процессорами Intel Xeon E5-2640 с частотой 2,5 ГГц и 6-ядерным 12-разрядным интерфейсом (с В / В).

РЕДАКТИРОВАТЬ 2: Вот окончательный анализ:

План питания был на сбалансированной, а не высокой производительности. Переключил это.

Tempdb был на RAID 5, а не на RAID 10. Добавлен еще один HD для создания двух физически различных конфигураций RAID 10, один для tempdb и один для всего остального.

Исключенные из проверки на вирусы файлы, связанные с SQL (mdf, ldf, ndf, bak).

Восстановите все индексы после перехода на новый сервер. Они были очень фрагментированы - возможно, в результате резервного копирования, копирования, восстановления?

И я понял, что скачок процессора был не таким большим. Запросы не будут выполняться намного быстрее, но с большим количеством процессоров, большим количеством ядер, большим объемом оперативной памяти мы будем более масштабируемыми.

Raid 5 медленнее, чем raid 10, особенно для рабочих нагрузок с большой нагрузкой при записи. Как таковой, он обычно не рекомендуется для сервера SQL и, конечно, не для базы данных tempdb. Одно это может легко объяснить разницу в производительности.

Я рекомендую переместить tempdb в рейд 10.

Это очень общая проблема, поэтому сложно дать конкретный совет. Но, если бы я оказался в такой ситуации, я бы начал с основ, проверил самые дорогие запросы. Какая функциональность занимает больше времени? Что занимает больше всего времени, что вы выполняете запросы со статистикой времени? Как только вы немного сузите фокус, вы можете сравнить вещи со старым сервером. Кроме того, кое-что нужно проверить, чтобы убедиться, что оба сервера находятся на одном уровне исправлений (SQL и Windows).

Ну, вы ничего не говорите о своих жестких дисках и количестве файлов tempdb. Существует общая рекомендация, что nr tempdbs = количество ядер до 32, также есть переключатель для броска, чтобы гарантировать, что временные базы данных используются одинаково.

Как бы то ни было: 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 также изменили ли вы упаковку для таблиц и индексов во время миграции? Резервное копирование и восстановление могут закончиться тем, что по умолчанию будут использоваться разные отступы для индексов (включая кластерные)