Там много статей (см. Оригинальная статья Славы Окс о SQL 2000 и Обновление 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, вы можете посмотреть на отключение гиперпоточности, чтобы увидеть, сокращает ли это ваши ожидания.
На самом деле гиперпоточность никуда не делась, новые четырехъядерные чипы Intel Nehalem имеют гиперпоточность. Что касается того, рекомендуется это или нет, «это зависит», как всегда, каждая ситуация, вероятно, отличается.
Маловероятно, что HT является основной причиной каких-либо проблем с производительностью, но без более подробной информации трудно сказать, что это такое. Проведите несколько сеансов perfmon с довольно длинными частотами дискретизации, например, каждые 30-60 секунд, и получите процессор, длину дисковой очереди на дисках данных и журналов, ожидаемую продолжительность жизни страницы - хороший показатель того, достаточно ли у вас памяти. Если у вас постоянно более 80% ЦП или количество очередей на дисках исчисляется трехзначными цифрами, вы нашли свою проблему.
SQL Server 2000 на HP DL360 G3:
Я составлял отчет шесть раз, отбросил первый бег и записал последние пять. Затем я снова перезагрузил базу данных и снова включил Hyperthreading. Я запустил отчет еще шесть раз, сохранив данные последних пяти прогонов.
Наблюдения:
Повторные прогоны отчета:
With Hyperthreading: 20.95%, 21.1%, 21.9%, 20.8%, 20.5% Run times in ms: 20282, 21141, 20188, 22297, 25282. Average 21838 Without Hyperthreading: 29.4%, 28.2%, 29.1%, 28.2%, 27.1% Run times in ms: 20125, 20156, 19937, 21656, 21656. Average 20706