Связанный с: текущая мудрость на 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 ПИСЬМО 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 снизить нагрузку на процессор и увеличить пропускную способность?
источник
Ответы:
Я все еще чувствую, что тестирование вашей конкретной рабочей нагрузки , согласно первоначальному ответу, является единственным способом быть уверенным. Это не идеальный ответ, когда вы пытаетесь настроить производственную систему (поэтому я бы спросил, можно ли получить идентичный испытательный стенд в системах, где важны как производительность, так и доступность), но это единственное, что мне действительно удобно с.
Мы можем говорить о теории того, должен ли Hyperthreading навредить или улучшить ситуацию в целом (я считаю, что это скорее повредит, чем помощь на серверах, поэтому для «общего» развертывания я бы, вероятно, отключил его), но есть Есть только один способ убедиться, что в вашем конкретном случае что-то изменится, - попробуйте и посмотрите.
источник
я согласна с тем что
Похоже, мы должны настроить две вещи:
MAXDOP (максимальные степени параллелизма). Все, что я читаю, указывает на то, что иметь это неограниченное, вероятно, плохая идея, а документация Microsoft гласит:
что-либо выше, чем
8обычно не рекомендуется .. поэтому я установил его4на данный момент. Первоначально он был нулевым (неограниченным).Порог стоимости для параллелизма. По-видимому, значение по умолчанию
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% устойчивого использования ЦП почти до нуля.
Удачи и, пожалуйста, не стесняйтесь, напишите мне, если вы найдете решение, так как я хотел бы добавить дело в мой блог.
Благодарность
Оскар
источник
Хороший или плохой ХТ сложно определить.
Это действительно зависит от схемы загрузки сервера, основанной на опыте и чтении. То есть, когда это влияет на производительность, это так плохо, иначе вы этого не замечаете.
Теория, которую я прочитал, состояла в том, что потоки совместно используют кэш, что означает, что в неблагоприятных условиях каждый поток может перезаписывать кэш другого потока. Если у вас нет большого параллелизма, или у вас много коротких запросов, то это может не повлиять на вас.
Я пробовал с MAXDOP и привязкой к процессору (вернувшись к моей последней реальной роли администратора баз данных на SQL Server 2000), но так и не смог найти ничего убедительного: но только для моего магазина в то время.
В качестве быстрого теста вы можете установить привязку процессора к использованию только физических ядер (младшие цифры) и посмотреть, что произойдет.
Однако самое большее вы теряете половину своих ядер. В настоящее время это может не иметь значения по сравнению с тем, с чем я играл несколько лет назад, когда было 2 против 4 или 4 против 8. Теперь это 8 против 16 или 16 против 32.
Изменить: тест Слава Окс
источник
К сожалению, я не думаю, что вы получите более определенный ответ, чем «попытайтесь отключить гиперпоточность и посмотрите, поможет ли это».
Несмотря на полезный ответ Джонатана в моей первоначальной ветке (которую вы связали в своем вопросе), мне так и не удалось получить каких-либо убедительных доказательств влияния HT на конкретные серверы, которые я исследовал. В моем случае серверы уже были запланированы для замены, поэтому мы просто позволяем этим заменам, так сказать, «позаботиться о проблеме».
Мой совет:
Попробуйте установить параметр МАКСИМАЛЬНАЯ степень параллелизма на уровне сервера, равный 1 . Параллелизм в SQL в любом случае наиболее полезен для больших и более длинных запросов, и ваша нагрузка (я полагаю) в любом случае состоит из огромного числа меньших запросов. Это должно полностью исключить ожидания CXPACKET. Это может привести к тому, что некоторые отдельные запросы будут выполняться немного дольше, но должны обеспечивать большую «пропускную способность» общих запросов на сервере.
Я добился хороших результатов, делая это на серверах OLTP. Другие типы серверов (серверы отчетов, серверы обработки, хранилища данных), безусловно, нуждаются в установке MAXDOP выше.
И, чтобы быть ясным, этот параметр все еще позволяет SQL использовать несколько потоков для каждой отдельной таблицы в JOIN, так что вы на самом деле не устраняете параллелизм полностью.
По крайней мере, стоит попробовать, поскольку это изменение настроек вступает в силу немедленно и даже не требует перезапуска службы SQL: http://msdn.microsoft.com/en-us/library/ms181007.aspx
Это означает, что вы можете переключиться немедленно, если дела пойдут в ад.
Отключение гиперпоточности в BIOS потребует полной перезагрузки сервера, так что это немного более рискованно.
источник
Для справки, у нас также была неожиданно плохая производительность после обновления сервера. Оказалось, что это связано с проблемами с BIOS и энергосбережением процессора. Настройка по умолчанию на сервере (HP) состояла в том, чтобы игнорировать управление скоростью процессора ЦП и использовать собственный алгоритм. Изменение этого параметра на управление ОС и обновление BIOS привело к значительным улучшениям. Были некоторые заметки о выпуске (не могу найти их сейчас), что была ошибка BIOS, которая блокировала процессор в состоянии самой низкой производительности.
/server//a/196329/6390
источник