Текущая мудрость в SQL Server и Hyperthreading?

Во многих статьях (см . Оригинальную статью SQL 2000 от Slava Oks и обновление SQL 2005 от Кевина Клайна ) рекомендуется отключить гиперпоточность на серверах SQL или, по крайней мере, протестировать конкретную рабочую нагрузку, прежде чем включать ее на своих серверах.

Эта проблема постепенно становится менее актуальной, так как настоящие многоядерные процессоры заменяют многопоточные, но какова текущая мудрость в этом вопросе? Меняется ли этот совет с 64-разрядной версией SQL 2005, SQL 2008 или Windows Server 2008?

В идеале, это должно быть проверено заранее в промежуточной среде, но как быть с серверами, которые уже включили его в работу с поддержкой HT? Как я могу определить, связаны ли проблемы с производительностью, с которыми мы сталкиваемся, с HT? Есть ли какая-то конкретная комбинация счетчиков perfmon, которая может указывать мне в этом направлении, в отличие от всех других вещей, которыми я обычно занимаюсь при работе над улучшением производительности SQL?

Изменить : Это особенно привлекательно из-за потенциального общего улучшения для некоторых из моих серверов с высоким процессором, но клиент захочет увидеть что-то конкретное, что поможет мне определить, какие серверы действительно могут извлечь выгоду из отключения гиперпоточности. Конечно, обычное устранение неполадок производительности продолжается, но иногда немного помогает.

В SQLOS планировщик создается для каждого логического процессора, который видит SQL Server. При включенной гиперпоточности это равняется удвоению планировщиков. Одной из целей SQLOS является минимизация и предотвращение переключения контекста, поэтому для каждого логического процессора создается только один планировщик. Как только SQLOS создает планировщики, общее количество рабочих делится между планировщиками. В SQLOS реализована форма совместного планирования, при которой работники выдают планировщик, поскольку он требует недоступных ресурсов или достигает своего кванта выполнения, позволяя другим работникам выполнять планировщик. Это сохраняет переключение контекста до минимума, так как планировщик выполняет работу, и они связаны один за другим.

Понимая этот фон, гиперпоточность работает несколько противоположно тому, как SQLOS специально предназначена для функционирования. В частности, параллелизм может быть проблематичным с гиперпоточностью и может привести к большим ожиданиям CXPACKET, поскольку SQLOS может попытаться выполнить запрос в DOP 8 в реальной системе DOP 4. Если загрузка процессора низкая, вы можете не заметить, но чем выше загрузка процессора, тем более проблематичным оно может стать. У меня недавно была дискуссия в твиттере по этому поводу, и консенсус был «Это зависит» от того, поможет это или нет.

Если на вашем сервере много ожидающих сигналов, но у вас низкая загрузка ЦП, вы можете увидеть преимущество, включающее гиперпоточность, которая удвоит ваши внутренние планировщики и увеличит нагрузку на сотрудников, что означает, что они не будут ждать выполнения в очереди, которую можно запустить как долго. Однако, если ваша рабочая нагрузка интенсивно использовала параллелизм, вы получаете тяжелые ожидания CXPACKET в sys.dm_os_wait_stats, вы можете посмотреть на отключение гиперпоточности, чтобы увидеть, уменьшает ли это ваши ожидания.

На самом деле гиперпоточность не исчезла, новые четырехъядерные чипы Nehalem от Intel имеют гиперпоточность. Что касается того, рекомендуется это или нет, «это зависит», как всегда, каждая ситуация, вероятно, отличается.

Маловероятно, что HT является основной причиной проблем с производительностью, но без подробностей сложно сказать, что именно. В некоторых сеансах Perfmon с достаточно большой частотой дискретизации, например, каждые 30–60 секунд, и с получением процессора, длины дисковой очереди на дисках данных и журналов, ожидаемая продолжительность жизни страницы является хорошим показателем того, достаточно ли у вас памяти. Если у вас стабильно более 80% ЦП или у вас дисковые очереди в трехзначных цифрах, вы нашли свою проблему.

SQL Server 2000 на HP DL360 G3:

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

Замечания:

• Отключение Hyperthreading не требует двухкратного увеличения нагрузки на процессор, только примерно в 1,5 раза.
• Отключение Hyperthreading ускоряет случайный длительный отчет на 5,2% (в среднем).

Повторные прогоны отчета:

С гиперпоточностью: 20,95%, 21,1%, 21,9%, 20,8%, 20,5%
Время выполнения в мс: 20282, 21141, 20188, 22297, 25282. Среднее 21838

Без гиперпоточности: 29,4%, 28,2%, 29,1%, 28,2%, 27,1%
Время выполнения в мс: 20125, 20156, 19937, 21656, 21656. Среднее 20706