SQL Server 2012 повільніше, ніж 2008 рік

Я перемістив великий веб-сайт та базу даних зі старого сервера (Windows 2008 / SQL Server 2008/16 ГБ оперативної пам’яті / 2 х 2,5 ГГц Quad Core / SAS диски) на новий, набагато кращий сервер (Windows 2008 R2 / SQL Server 2012 SP1 / 64 ГБ оперативної пам’яті / 2 х 2,1 ГГц 16 ядерних процесорів / SSD дисків).

Я відокремив файли баз даних на старому сервері, скопіював і приєднав їх на новому сервері. Все пройшло дуже добре.

Після цього я змінив рівень сумісності до 110, оновив статистику, відновив індекси.

На моє величезне розчарування, я помітив, що більшість запитів sql набагато повільніше (у 2-3-4 рази повільніше) на новому сервері SQL 2012, ніж на старому сервері SQL 2008.

Наприклад, на таблиці з близько 700 к записів, на старому сервері запит на індекс займав близько 100 мс. На новому сервері цей самий запит займає близько 350 мс.

Те саме відбувається для всіх запитів.

Я би вдячний тут за допомогою. Дайте мені знати, що перевірити / перевірити. Оскільки мені дуже важко повірити, що на кращому сервері з новим SQL сервером продуктивність гірша.

Детальніше:

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

У мене є ця таблиця та індекс:

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

Пізніше оновлення:

• Ядра AMD 2.1GHz Opteron 16 виглядають набагато гірше, ніж чотириядерні процесори Intel 2.5GHz
• Значне вдосконалення, зміна параметрів живлення Windows з збалансованої на високу
• Подальше вдосконалення змінюючи максимальний ступінь паралелізму до 8 та поріг витрат до 4

Тепер час виконання SQL Server: час процесора = 550 мс, минулий час = 828 мс.

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

У мене були подібні проблеми з SQL Server, можливо, ваш сервер не налаштований оптимально. Нові Xeons поставляються з TurboBoost, HT тощо, що може суттєво вплинути на продуктивність сервера.

Наприклад, у нас був успіх; Конфігурація з низькою затримкою для серверів Dell

Налаштування застосовуватимуться до серверів, що не належать до Dell, вони можуть мати різні назви.

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

Моєю рекомендацією було б повернутися до старого сервера, якщо можливо. Якщо у вас немає сценаріїв регресії / автоматизації / завантаження, найкраще, що ви можете зробити, це записувати активність вашої системи протягом 1-4 годин протягом періоду високої активності. Потім встановіть веб-сервер, такий же як виробництво, і клієнтську машину для запуску сценарію. Запустіть ту саму діяльність на новому сервері, змініть конфігурацію та повторіть ту саму діяльність. Дійсно, ви б хотіли зробити набагато більше, але, схоже, це не було б життєздатним і не виходить за рамки цього питання.

Дайте мені знати, що перевірити / перевірити

У вас є проблеми з продуктивністю. Дотримуйтесь методології усунення несправностей, як-от " Чекання" та "Черги", щоб визначити вузьке місце. Зв'язана методологія показує, що вимірювати та як. Опублікуйте тут свої результати, і ми можемо допомогти конкретними порадами на основі ваших фактичних вимірювань. Оскільки він занадто відкритий, і це хтось здогадується. Звуження його до конкретного питання усуне здогадки.

Після оновлення

Плани зовсім інші. Старий план мав сукупність потоків низько на стеку, що насправді має погану оцінку кардинальності (141k проти 108k), а хеш-математика надалі непередбачує, інший спосіб (35k проти 108k). Новий план не має сукупності потоків і має точні оцінки аж до вершини. Звичайно, це не пояснює, чому старий план виконувався швидше .

Нижнє сканування має дещо інший номер рядка (не суттєво), але зовсім інші витрати: стара - 2,49884 (IO 2,28979 CPU 0,20905) проти нових 1,59109 (IO 1,53868 CPU 0,05404084). Знову вказувалося б на краще виконання 2012 року (відновлення індексу, можливо, зменшило фрагментацію?).

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

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

Помітили ваш коментар:

Доданий план виконання з maxdop 8 Query таким чином насправді швидший

Ймовірно, це просто CPU, що наступають один на одного пальцями ніг. Якщо 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 Memoryта Min Server Memoryпараметрів конфігурації до значень, відповідних даному серверу.

У якому виданні та режимі ліцензування ви перебуваєте? Ви, мабуть, не використовуєте всі ядра. Дивіться примітку на цій сторінці - http://msdn.microsoft.com/en-us/library/ms143760.aspx

"Enterprise Edition з ліцензуванням на основі сервера + клієнтського доступу (CAL) обмежується максимум 20 ядрами на екземпляр SQL Server."

У мене була та сама проблема, що описана на цій сторінці: перемикання параметрів живлення з "збалансованого" на "високу продуктивність" призвело до кардинальних змін - більш ніж удвічі збільшило час відгуку. Тепер, коли ми використовуємо жорсткі диски, я не вважаю, що це могло бути споживання енергії.

Я також пройшов цю проблему принаймні 2 тижні, не маючи надійного рішення, а не плутаючи одне питання з іншим.

Нарешті резолюція наступна:

1. Я відновив сумісність з 010 до 011

2. Скиньте також сумісність основної бази даних. За замовчуванням sql збереже старий параметр сумісності. Що нам потрібно змінити вручну.

Всього найкращого