Текущая мудрость на SQL Server и Гиперпоточности?
В SQLOS планировщик создается для каждого логического процессора, который видит SQL Server. С гиперпоточностью, включенной это, приравнивается для удвоения планировщиков. Одна из целей для SQLOS состоит в том, чтобы минимизировать и препятствовать тому, чтобы контекстное переключение произошло, который является, почему только один планировщик создается для каждого логического процессора. После того как SQLOS создает планировщики, общее количество рабочих разделено между планировщиками. SQLOS реализует форму совместного планирования в этом, рабочие приводят к планировщику, поскольку это требует недоступных ресурсов или достигает его кванта выполнения, разрешающего другим рабочим выполниться на планировщике. Это сводит контекстное переключение к минимуму, так как планировщик делает работу, и они связываются один к одному.
Понимая, что фон, гиперпоточность несколько работает противоположность того, как SQLOS специально предназначен для функционирования. А именно, параллелизм может быть проблематичным с гиперпоточностью и может привести к высокому CXPACKET, ожидает, так как SQLOS может попытаться выполнить запрос в МЕДНОМ ЗАЖИМЕ 8 на том, что является действительностью МЕДНЫЙ ЗАЖИМ 4 системы. Если Ваша загрузка ЦП является низкой, Вы не могли бы заметить, но чем выше Ваша загрузка ЦП идет, тем более проблематичным это могло стать. У меня недавно было обсуждение Твиттера относительно этого, и согласие было, "Это Зависит" относительно того, помогло ли это или причинило бы боль.
Если у Вас есть много сигнала, ожидает на Вашем сервере, но у Вас есть низкая загрузка ЦП, можно видеть, что преимущество включает гиперпоточность, которая удвоит внутренние планировщики и распространит рабочих больше, что означает, что они не будут ожидать для выполнения в выполнимой очереди как долго. Однако, если Ваша рабочая нагрузка использовала параллелизм в большой степени, Вы добираетесь, тяжелый CXPACKET ожидает в sys.dm_os_wait_stats, Вы могли бы посмотреть на отключение гиперпоточности, чтобы видеть, уменьшает ли это Ваш, ожидает.
-
1Спасибо за деталь. Я принимаю DBCC SQLPERF (' WAITSTATS') должен дать мне эквивалентную информацию о SQL 2000? – BradC 30 June 2009 в 02:05
-
2Да. Это корректно. – Jonathan Kehayias 30 June 2009 в 02:42
На самом деле гиперпоточность не ушла, новый Nehalem Intel, четырехъядерные микросхемы имеют гиперпоточность. Что касается того, рекомендуется ли это или нет, "это зависит" как всегда, каждая ситуация, вероятно, отличается.
Это - маловероятный HT, первопричина любой проблемы производительности, но без большего количества деталей, трудно сказать, что. Сделайте некоторые perfmon сессии, с довольно длинными частотами дискретизации, как один раз в 30 - 60 секунд и получение CPU, дисковой длины очереди на данных и зарегистрируйте диски, продолжительность жизни страницы является хорошей мерой того, есть ли у Вас достаточно памяти. Если Вы - consistenly более чем 80% ЦП или Вас, дисковые очереди возросли в тройных цифрах, Вы нашли свою проблему.
SQL Server 2000 на HP DL360 G3:
Я выполнил отчет шесть раз, и я бросил начальную букву, убегает и записал последние пять. Я затем перезагрузил базу данных снова и снова включил Гиперпоточность. Я выполнил отчет еще шесть раз, сохранив данные из последних пяти выполнений.
Наблюдения:
- Выключение Гиперпоточности не стоит 2x в очевидном использовании ЦП, только о 1.5x.
- Выключение Гиперпоточности делает случайный длительный отчет выполненным на 5,2% быстрее (в среднем).
Повторные выполнения отчета:
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