Гірша продуктивність на новому сервері

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

У тестуванні наш додаток ASP.NET працює на 10 - 20% повільніше. Запуск окремих дорогих запитів за допомогою STATISTICS IO та STATISTICS TIME показує на 10 - 20% більше минулого часу на новому сервері. Профіль запитів SQL показує більш високе використання процесора на дорогих запитах.

Диспетчер завдань на новому сервері показує, що sqlserver.exe споживає 22 ГБ оперативної пам’яті, але значення CPU завжди залишаються дуже низькими.

Я оновлював всю статистику, перебудовував або реорганізовував індекси тощо. Плани виконання повинні зберігатися на новому сервері з цього моменту, враховуючи кількість проведених тестувань. Якщо є якісь відсутні індекси (я не думаю, що вони є), вони впливають на старий і новий сервери однаково. Новий має відновлену резервну копію тих же даних на старих.

Я очікував, що продуктивність на новому сервері буде кращою, але більше турбує навантаження. Якщо старий сервер працює краще навіть під навантаженням, то що буде, коли цей новий, трохи гірший сервер повинен прийняти це навантаження?

Що ще я міг пропустити тут?

EDIT: MAXDOP встановлено на 6.

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

Старий сервер має 1 x Intel Xeon E5620 2,40 ГГц чотирьохядерний 8 потоків (з H / T). Новий сервер має 2 x Intel Xeon E5-2640 2,5 ГГц Шість -Коре 12 потоків (з В / В).

EDIT 2: Ось підсумковий аналіз:

План електроживлення був збалансованим, не високими показниками. Перемкнув це над.

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

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

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

І я зрозумів, що стрибок процесора не такий вже й великий. Запити не будуть виконуватись набагато швидше, але, якщо більше процесорів, більше ядер, більше оперативної пам’яті, ми будемо масштабнішими.

Рейд 5 проходить повільніше, ніж рейд 10, особливо для важких робочих навантажень. Як правило, він зазвичай не рекомендується для SQL-сервера і, звичайно, не для tempdb. Це одне може легко пояснити різницю в продуктивності.

Моя рекомендація - перенести tempdb на рейд 10.

Це дуже загальна проблема, тому важко дати конкретну пораду. Але, якби я опинився в цій ситуації, я б почав з основ, перевірити найдорожчі запити. Яка функціональність займає більше часу? Що витрачає найбільше часу на те, що ви запускаєте запити зі статистичним часом? Коли ви трохи звузите фокус, ви зможете порівняти речі зі старим сервером. Також слід перевірити, чи обидва сервери знаходяться на одному рівні патчу (SQL та Windows).

Ну, ви нічого не говорите про ваші жорсткі диски та кількість файлів tempdb. Існує загальна рекомендація, що nr tempdbs = кількість ядер до 32, є також перемикач для кидання, щоб забезпечити однакове використання temp dbs.

Однак indepth: 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 Ви також змінили упаковку для таблиць та індексів під час міграції? Резервне копіювання та відновлення можуть призвести до дефолту до іншого прокладки в індексах (включаючи кластерні)