SQL Server 2012 медленнее, чем 2008

Я перенес большой веб-сайт и базу данных со старого сервера (Windows 2008 / SQL Server 2008/16 ГБ ОЗУ / 2 x 2,5 ГГц Quad Core / SAS-диски) на новый, гораздо лучший сервер (Windows 2008 R2 / SQL Server 2012 SP1 /). 64 ГБ ОЗУ / 2 x 2,1 ГГц 16-ядерные процессоры / SSD-диски).

Я отсоединил файлы базы данных на старом сервере, скопировал и прикрепил их на новом сервере. Все прошло очень хорошо.

После этого я перешел на уровень совместимости до 110, обновил статистику, перестроил индексы.

К моему огромному разочарованию, я заметил, что большинство SQL-запросов намного медленнее (в 2-3-4 раза медленнее) на новом сервере SQL 2012, чем на старом сервере SQL 2008.

Например, для таблицы, содержащей около 700 тыс. Записей, на старом сервере запрос по индексу занимал около 100 мс. На новом сервере тот же запрос занимает около 350 мс.

То же самое происходит для всех запросов.

Я был бы признателен за помощь здесь. Дайте мне знать, что проверить / проверить. Потому что мне очень трудно поверить, что на лучшем сервере с более новым SQL Server производительность хуже.

Больше деталей:

Память установлена ​​на макс.

У меня есть эта таблица и индекс:

CREATE TABLE [dbo].[Answer_Details_23](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [UserID] [int] NOT NULL,
    [SurveyID] [int] NOT NULL,
    [CustomerID] [int] NOT NULL default 0,
    [SummaryID] [int] NOT NULL,
    [QuestionID] [int] NOT NULL,
    [RowID] [int] NOT NULL default 0,
    [OptionID] [int] NOT NULL default 0,
    [EnteredText] [ntext] NULL,
 CONSTRAINT [Answer_Details_23_PK] PRIMARY KEY NONCLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

CREATE NONCLUSTERED INDEX [IDX_Answer_Details_23_SummaryID_QuestionID] ON [dbo].[Answer_Details_23]
(
    [SummaryID] ASC,
    [QuestionID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

Я выполнил этот запрос:

set statistics time on;
select summaryid, count(summaryid) from Answer_Details_23 group by summaryid order by count(summaryid) desc;
set statistics time off;

СТАРЫЙ СЕРВЕР - Время выполнения SQL Server: время ЦП = 419 мс, прошедшее время = 695 мс.

НОВЫЙ СЕРВЕР - Время выполнения SQL Server: время ЦП = 1340 мс, прошедшее время = 1636 мс.

ПЛАНЫ ИСПОЛНЕНИЯ выложены здесь: http://we.tl/ARbPuvf9t8

Позднее обновление:

• 16-ядерные процессоры AMD 2.1GHz Opteron выглядят намного хуже четырехъядерных процессоров Intel 2.5GHz
• Большое улучшение, изменяющее параметры электропитания стеклоподъемников от сбалансированного к мощному
• Дальнейшее улучшение изменяет максимальную степень параллелизма до 8 и порог стоимости до 4

Теперь время выполнения SQL Server: время ЦП = 550 мс, прошедшее время = 828 мс.

Это все еще хуже чем старый сервер, но не так плохо. Если у вас есть другие предложения (кроме оптимизации локальных запросов), пожалуйста, не стесняйтесь комментировать.

У меня были похожие проблемы с SQL Server, возможно, ваш сервер настроен не оптимально. Более новые Xeons поставляются с TurboBoost, HT и т. Д., Которые могут значительно повлиять на производительность сервера.

Например, у нас был успех с; Конфигурация с низкой задержкой для серверов Dell

Настройки будут применимы к серверам сторонних производителей, они могут просто иметь разные имена.

Мы также улучшили производительность, настроив профиль управления питанием Windows на высокую производительность, от Balanced. И последнее, что рекомендуется зарезервировать до 8 ГБ памяти для ОС на серверах x64, установка SQL по умолчанию занимает всю память. Возможно, вы захотите попробовать резервирование 4/8 ГБ, установив максимальную конфигурацию памяти SQL Server на 4/8 ГБ меньше, чем общий объем памяти.

Я рекомендую вернуться к старому серверу, если это возможно. Если у вас нет доступных сценариев регрессии / автоматизации / загрузки, то лучшее, что вы можете сделать, - это записывать активность вашей системы в течение 1-4 часов в течение периода высокой активности. Затем настройте веб-сервер так же, как рабочий, и клиентский компьютер для запуска сценария. Запустите то же действие на новом сервере, внесите изменения в конфигурацию и снова выполните то же действие. На самом деле вы хотели бы сделать гораздо больше, но не похоже, что это было бы жизнеспособным и выходит за рамки этого вопроса.

Дайте мне знать, что проверить / проверить

У вас проблемы с производительностью. Следуйте методологии устранения неполадок производительности, такой как Ожидания и очереди, чтобы определить узкое место. Связанная методология показывает, что измерять и как. Опубликуйте здесь результаты, и мы можем помочь с конкретными советами, основанными на ваших фактических измерениях. Поскольку это слишком открыто и никто не знает. Сужение до конкретной проблемы устранит догадки.

После обновления

Планы совсем другие. У старого плана был совокупный низкий уровень потока в стеке, который на самом деле имеет плохую оценку мощности (141 тыс. Против 108 тыс.), А хэш-математика еще больше неверно предсказывает, наоборот (35 тыс. Против 108 тыс.). Новый план не имеет совокупного потока и имеет точные оценки вплоть до вершины. Конечно, это не объясняет, почему старый план выполнялся быстрее .

Нижние сканы имеют немного другой номер строки (не значительный), но довольно разные затраты: старый - 2.49884 (IO 2.28979 CPU 0.20905) по сравнению с новым 1.59109 (IO 1.53868 CPU 0.0524084). Опять же, это указывает на лучшее выполнение в 2012 году (перестройка индекса, возможно, уменьшила фрагментацию?).

Что сильно отличается, так это количество потоков: 32 в новых (каждый получает ~ 23k строк) против 8 в старых (каждый получает ~ 95k строк). Стол довольно узкий. Это может быть , что большое количество потоков на самом деле вредит производительность из - за гораздо более частой инвалидацией кэша . Я бы попробовал:

1. устранить HyperThreading в новой конфигурации сервера (если есть) и / или
2. попробуйте запрос с DOP 8.

Заметил ваш комментарий:

Добавлен план выполнения с maxdop 8 Query на самом деле быстрее, таким образом

Вероятно, это просто процессоры, наступающие друг на друга. С SSD на месте IO, вероятно, почти ничего не значит, и таблица определенно слишком мала, чтобы гарантировать 32 сканера. Этот обменный своп, вероятно, постоянно лишает законной силы L1 / L2.

Для большинства современных многоядерных систем и, в частности, для систем с несколькими процессорами, аппаратная архитектура такова, что определенные части памяти находятся далеко от определенных ядер / процессоров, а определенные части памяти - близко к определенным ядрам / процессорам. Это называется неоднородной архитектурой памяти или NUMA для краткости. Вы хотите, чтобы ваш параметр MAXDOP совпадал с числом ядер на узел NUMA, чтобы минимизировать количество раз, которое данный узел numa должен выходить за пределы своей собственной памяти для данных.

Вы можете использовать следующее, чтобы проверить конфигурацию вашей новой машины и убедиться, что MAXDOP настроен на лучшую настройку, аппаратно :

DECLARE @CPUs int;
DECLARE @NumaNodes int;
DECLARE @ServerRAMInMB int;

SET @ServerRAMinMB = (SELECT (i.physical_memory_kb / 1024) AS ServerMemory 
    FROM sys.dm_os_sys_info i);
SET @CPUs = (SELECT i.cpu_count from sys.dm_os_sys_info i);
SET @NumaNodes = (SELECT MAX(c.memory_node_id) + 1 FROM sys.dm_os_memory_clerks c 
    WHERE memory_node_id < 64);

SELECT @ServerRamInMB, @CPUs, @NumaNodes;

IF @CPUs > 4 /* this would be 4 cores, not 4 CPUs */
BEGIN
    DECLARE @MaxDOP int;
    SET @MaxDOP = @CPUs * 0.75;
    IF @MaxDOP > (@CPUs / @NumaNodes) SET @MaxDOP = (@CPUs / @NumaNodes);
    EXEC sp_configure 'max degree of parallelism', @MaxDOP;
    EXEC sp_configure 'cost threshold for parallelism', 4; 
END

Я включил @ServerRamInMBпараметр здесь, так как я использую его для настройкиMax Server MemoryMin Server Memory конфигурации и на значения, подходящие для данного сервера.

В каком издании и режиме лицензирования вы находитесь? Вы, вероятно, не используете все ядра. Смотрите примечание на этой странице - http://msdn.microsoft.com/en-us/library/ms143760.aspx

«Enterprise Edition с лицензией на основе сервера + клиентского доступа (CAL) ограничивается максимум 20 ядрами на экземпляр SQL Server».

У меня была та же проблема, что и описанная на этой странице: переключение настроек мощности со «сбалансированного» на «высокопроизводительное» имело огромное значение - более чем удвоение времени отклика. Теперь, когда мы используем твердотельные накопители, я не думаю, что энергопотребление - это проблема, которая могла возникнуть.

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

Наконец, резолюция выглядит следующим образом:

1. Я сбросил совместимость с 010 до 011

2. Сброс совместимости основной базы данных тоже. По умолчанию sql сохранит старые настройки совместимости. Это нам нужно изменить вручную.

Всего наилучшего