Повлияет ли отключение гиперпоточности на производительность при установке SQL Server?

Связанный с: текущая мудрость на SQL Server и Hyperthreading

Недавно мы обновили наш сервер баз данных Windows 2008 R2 с X5470 до X5560. Теория заключается в том, что оба процессора имеют очень схожую производительность, во всяком случае, X5560 немного быстрее.

Тем не менее, производительность SQL Server 2008 R2 в последние дни была довольно плохой, а загрузка ЦП была довольно высокой.

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

Когда я побежал:

SELECT * FROM sys.dm_os_wait_stats 
order by signal_wait_time_ms desc

Я получил:

wait_type wait_tasks_count  wait_time_ms         max_wait_time_ms     signal_wait_time_ms
------------------------------------------------------------ -------------------- -------------------- -------------------- --------------------
XE_TIMER_EVENT                                               115166               2799125790           30165                2799125065
REQUEST_FOR_DEADLOCK_SEARCH                                  559393               2799053973           5180                 2799053973
SOS_SCHEDULER_YIELD                                          152289883            189948844            960                  189756877
CXPACKET                                                     234638389            2383701040           141334               118796827
SLEEP_TASK                                                   170743505            1525669557           1406                 76485386
LATCH_EX                                                     97301008             810738519            1107                 55093884
LOGMGR_QUEUE                                                 16525384             2798527632           20751319             4083713
WriteLog 16850119             18328365             1193                 2367880
PAGELATCH_EX                                                 13254618             8524515              11263                1670113
ASYNC_NETWORK_IO                                             23954146             6981220              7110                 1475699

(10 строк (ы) пострадавших)

Я тоже побежал

-- Isolate top waits for server instance since last restart or statistics clear
WITH Waits AS (
   SELECT 
        wait_type, 
        wait_time_ms / 1000. AS [wait_time_s],
        100. * wait_time_ms / SUM(wait_time_ms) OVER() AS [pct],
        ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS [rn]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE',
    'SLEEP_TASK','SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR','LOGMGR_QUEUE',
    'CHECKPOINT_QUEUE','REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH',
    'BROKER_TASK_STOP','CLR_MANUAL_EVENT','CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE',
    'FT_IFTS_SCHEDULER_IDLE_WAIT','XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN'))

SELECT W1.wait_type, 
    CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
    CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
    CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
INNER JOIN Waits AS W2 ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 95; -- percentage threshold

И получил

wait_type           wait_time_s     pct  running_pct
CXPACKET              554821.66   65.82        65.82
LATCH_EX              184123,16 21,84 87,66
SOS_SCHEDULER_YIELD    37541,17 4,45 92,11
PAGEIOLATCH_SH         19018,53 2,26 94,37
FT_IFTSHC_MUTEX        14306.05    1,70 96,07

Это показывает огромное количество синхронизирующих запросы времени с параллелизмом (высокий CXPACKET). Кроме того, по многим причинам многие из этих проблемных запросов выполняются на нескольких ядрах (в нашем коде нет подсказок MAXDOP)

Сервер не находился под нагрузкой более суток. Мы наблюдаем большое расхождение с выполнением запросов, обычно многие запросы выполняются медленнее, чем на нашем предыдущем сервере БД, а ЦП действительно высок.

Поможет ли отключение Hyperthreading снизить нагрузку на процессор и увеличить пропускную способность?

Источник

8 ответов

Решение

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

Мы можем говорить о теории того, должен ли Hyperthreading вредить или улучшать вещи в целом (я считаю, что это скорее повредит, чем помощь на серверах, поэтому для "общего" развертывания я бы, вероятно, отключил его), но есть Есть только один способ убедиться, что в вашем конкретном случае что-то изменится, - это попробовать и посмотреть.

Источник

Я согласна с тем что

  • в лучшем случае рекомендуется "попробовать HyperThreading на своей рабочей нагрузке и посмотреть, что произойдет". Мы делаем это прямо сейчас, когда я печатаю, и... это не хорошо!
  • Вы, вероятно, должны всегда начинать с отключенной HyperThreading, так как это наиболее безопасно

Похоже, мы должны настроить две вещи:

  1. MAXDOP (максимальные степени параллелизма). Все, что я читаю, указывает на то, что иметь это неограниченное, вероятно, плохая идея, а в документации Microsoft говорится:

    Установка для этого параметра [MAXDOP] большего значения [чем 8] часто приводит к нежелательному потреблению ресурсов и снижению производительности.

    что-нибудь выше, чем 8 как правило, не рекомендуется.. поэтому я установил его 4 теперь. Первоначально он был нулевым (неограниченным).

  2. Порог стоимости для параллелизма. Видимо по умолчанию 5 здесь считается довольно низкое значение по умолчанию в соответствии с несколькими сообщениями SQL MVP, которые я нашел - мы можем настроить его, чтобы уменьшить количество попыток параллелизма даже при планировщике.

Но, честно говоря, это похоже на обходные пути; Я думаю, что истинное решение для нашей рабочей нагрузки (полнотекстового индекса) состоит в отключении HT.

Источник

Anandtech обнаружил, что с чистой нагрузкой чтения это немного больно, а с большой нагрузкой записи это было чем-то вроде победы. Я не видел ничего, что могло бы заставить меня думать, что это даст вам удар намного хуже, чем -5%, или выигрыш, намного лучше, чем 15%. Обратите внимание, что с Atom это огромная победа, но это очень странный процессор.

Все, что вы изменили, был процессор? Вы перешли от 12 МБ кеша и 4 потоков, то есть 3 МБ кеша на поток, до 8 МБ кеша и 8 потоков, то есть 1 МБ на поток. Это упрощает, но я уверен, что именно это вас и убивает, вы раньше запускали запросы в кеше, а теперь запускаете их из оперативной памяти, потому что им требуется больше 1 МБ, но меньше 3 МБ. Отключение HT, вероятно, поможет, но я бы вернулся к старому процессору. Выключите HT, и вы получите 2 МБ на поток, но если ваша рабочая нагрузка сильно возрастает, это не поможет. Вполне может быть, что старый 12-Мбайт кэш-процессор значительно быстрее для вашей рабочей нагрузки.

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

Источник

Гиперпоточность - это, в лучшем случае, просто способ абстрагирования задачи от переключения с операционной системы и помещения ее в состояние готовности с прямым доступом к кэш-памяти L1 и L2, что ускоряет переключение задач.

Тестирование с VMWare показало, что отключение HT не оказало заметного различия при стандартной нагрузке и на 5% увеличилось при большой нагрузке, потому что ESXi достаточно умен, чтобы знать разницу между "реальным" потоком и "поддельным" потоком (это намного больше, чем это, но это с точки зрения непрофессионалов). SQL Server 2005 не так уж и умен, но в сочетании с современной операционной системой отключение HT не должно иметь особых преимуществ.

Все, что сказал, я согласен с Рональдом, что это, скорее всего, будет ваш кэш второго уровня. Уменьшение размера кэша на 33% является существенным, и когда мы задаем наши SQL-серверы, мы всегда обращаемся к кэшу с более высокой тактовой частотой каждый раз.

Источник

Исходя из моего опыта, HT заставляла операции ввода-вывода бесконечно выполняться на моих активных узлах в кластере Windows 2008 R2 (под управлением SQL Server 2008 R2). Интересным фактом было то, что это не было отражено ни в статистике ожидания, ни в pssdiag, который я использовал для поддержки Microsoft.

То, как я заметил низкое число операций ввода-вывода, было просто путем наблюдения за счетчиками ОС на физическом диске. Как отметил Сэм, я писал об этом здесь и здесь

Если вы не испытываете проблемы с вводом / выводом и связаны с процессором, я предлагаю вам начать следующим образом:

Определите, какие процессы и блоки T-SQL вызывают наибольшую загрузку ЦП. По нашему опыту, после того, как мы исправили проблему с вводом / выводом (отключив HT), мы определили код, который работал ужасно в 2008 R2 и работал хорошо в 2005. Я написал об этом здесь.

Находясь под большой нагрузкой, запустите Адам Мачаник sp_whoisactive. Вы можете скачать его здесь. Мы испытывали очень высокую загрузку ЦП из-за чрезмерного количества логических операций чтения (20 миллионов на запрос) из-за очень плохого плана. Наши процессы выполняли анти-полусоединения с разделенными таблицами.

Моя следующая рекомендация - запустить профилировщик, чтобы идентифицировать набор кода T-SQL, который имеет высокий уровень загрузки ЦП и логического чтения ввода-вывода.

Благодаря вышеперечисленным шагам мы смогли настроить нарушающие процессы и перейти от 85% устойчивого использования ЦП почти до нуля.

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

Спасибо

Оскар

Источник

К сожалению, я не думаю, что вы получите более точный ответ, чем "попытайтесь отключить гиперпоточность и посмотрите, поможет ли это".

Несмотря на полезный ответ Джонатана в моей первоначальной ветке (которую вы связали в своем вопросе), мне так и не удалось получить каких-либо убедительных доказательств влияния HT на конкретные серверы, которые я исследовал. В моем случае серверы уже были запланированы для замены, поэтому мы просто позволяем этим заменам, так сказать, "позаботиться о проблеме".

Мой совет:

Попробуйте установить параметр МАКСИМАЛЬНАЯ степень параллелизма на уровне сервера, равный 1. Параллелизм в SQL в любом случае наиболее полезен для больших и более длинных запросов, и ваша нагрузка (я полагаю) в любом случае состоит из огромного числа меньших запросов. Это должно полностью исключить ожидания CXPACKET. Это может привести к тому, что некоторые отдельные запросы будут выполняться немного дольше, но должны обеспечивать большую "пропускную способность" общих запросов на сервере.

Я добился хороших результатов, делая это на серверах OLTP. Другие типы серверов (серверы отчетов, серверы обработки, хранилища данных), безусловно, нуждаются в установке MAXDOP выше.

И чтобы было ясно, этот параметр все еще позволяет SQL использовать несколько потоков для каждой отдельной таблицы в JOIN, так что вы на самом деле не исключаете параллелизм полностью.

По крайней мере, стоит попробовать, так как это изменение настроек вступает в силу немедленно и даже не требует перезапуска службы SQL: http://msdn.microsoft.com/en-us/library/ms181007.aspx
Это означает, что вы можете сразу же переключить его обратно, если дела пойдут в ад.

Отключение гиперпоточности в BIOS потребует полной перезагрузки сервера, так что это немного более рискованно.

Источник

Хороший или плохой ХТ сложно определить.

Это действительно зависит от схемы загрузки сервера, основанной на опыте и чтении. То есть, когда это влияет на производительность, это так плохо, иначе вы этого не замечаете.

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

Я пробовал с MAXDOP и привязкой к процессору (вернувшись к моей последней реальной роли администратора баз данных в SQL Server 2000), но так и не смог найти ничего убедительного: но только для моего магазина в то время.

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

Однако самое большее вы теряете половину своих ядер. В настоящее время это может не иметь значения по сравнению с тем, с чем я играл несколько лет назад, когда это было 2 против 4 или 4 против 8. Теперь это 8 против 16 или 16 против 32.

Изменить: тест Слава Окс

Источник

Для справки, у нас также была неожиданно плохая производительность после обновления сервера. Оказалось, что это связано с проблемами с BIOS и энергосбережением процессора. Настройка по умолчанию на сервере (HP) состояла в том, чтобы игнорировать управление скоростью процессора ЦП и использовать собственный алгоритм. Изменение этого параметра на управление ОС и обновление BIOS привело к значительным улучшениям. Были некоторые заметки о выпуске (не могу их найти сейчас), что была ошибка BIOS, которая блокировала процессор в состоянии самой низкой производительности.

/questions/126425/otklyuchit-masshtabirovanie-protsessora-v-windows-server-2008-r2/126435#126435

Источник
Другие вопросы по тегам