Очень неравномерная загрузка ЦП с SQL Server 2012 на 2-х процессорном компьютере с 16 ядрами / процессор

8

После установки SQL Server Enterprise 2012 с моделью лицензий Server + Cal на компьютере с двумя процессорами, каждый с 16 ядрами (без использования гиперпоточности), и при чрезмерной нагрузке на сервер 16 ядер на первом процессоре были загружены недостаточно. первые 4 ядра на 2-м процессоре были интенсивно использованы, а последние 12 ядер вообще не использовались (из-за ограничения в 20 ядер для этой версии сервера sql). Общая загрузка ЦП составляла около 25%. К сожалению, сервер страдает от крайне низкой производительности, даже если бы задачи были равномерно распределены по 20 ядрам, это было бы не так плохо.

Windows Server работал на виртуальном образе VMWare под ESX Server, но весь ЦП был выделен серверу Windows.

Мы попытались изменить настройки соответствия (например, выделив большинство ядер для ЦП, а остальные для ввода / вывода), но это не помогло решить проблемы с производительностью.

Обновление редакции продукта до SQL Server Enterprise Core 2012 не только позволило SQL Server использовать 12 ранее неиспользуемых ядер на 2-м процессоре, но также привело к гораздо более равномерному распределению задач по всем процессорам. Чтобы преодолеть отставание в запросах, загрузка ЦП возросла до 90%, а затем снизилась до 33% после того, как она была достигнута, но производительность значительно улучшилась, так как мы перешли на новую обновленную версию, а проблемы с производительностью исчезли.

Мне было интересно, если кто-нибудь знает, что может привести к тому, что SQL Server будет неравномерно распределять нагрузку, полагаясь почти исключительно на первые 4 ядра 2-го процессора, которые простаивают по 12 ядер, и выделяет только несколько задач каждому из 16 ядер на первом процессор. Кроме того, есть ли способ, которым мы могли бы более равномерно распределить нагрузку на 20 ядер, которые использовались без обновления редакции продукта?

Обратная сторона этого вопроса заключается в том, что произошло с обновлением продукта, что привело к тому, что SQL Server начал равномерно распределять нагрузку по всем распознаваемым ядрам?

Спасибо любому пониманию, чтобы ответить на эти вопросы и / или ссылки, которые могли бы помочь мне лучше понять, как понять происходящее.

cooplarsh
источник
Вы говорите, что рассматриваемая машина является виртуальной машиной с 32 виртуальными ЦП? В обоих сценариях?
Mfinni
Да, это была та же самая машина, на которой было 2 процессора, каждый с 16 ядрами (без гиперпоточности).
Cooplarsh
1
Почему во имя Господа у вас есть 32 виртуальных ЦП? Вы пытались уменьшить это? Я знаю, что ESXi улучшил групповое планирование процессоров, но вы просто напрашиваетесь на такие проблемы. На какой версии ESXi вы работаете и какое аппаратное обеспечение лежит в основе?
mfinni

Ответы:

4

Неравномерная производительность, вероятно, была комбинацией ограничения в 20 ядер в сочетании с тем, как сервер sql планирует потоки на компьютерах NUMA. К сожалению, SQL Server 2012 не использует какой-либо интеллект для определения того, какие 20 ядер использовать, что приводит к несбалансированному количеству ядер на узел NUMA. С 32 ядрами, распределенными по 2 узлам NUMA, вы, скорее всего, получите разделение 16/4. Это проблематично, потому что SQL будет пытаться равномерно распределить активность между узлами NUMA циклическим образом (при условии, что вы не навязываете привязку с регулятором ресурсов).

В вашем случае 1/2 нагрузки распределяется на 4 ядра, а 1/2 - на 16 ядер. Узкое место в 4-ядерном узле эффективно действует как дроссель, ограничивая емкость машины до 2x 4 ядра = 8 ядер = 25% загрузки ЦП.

После обновления до базовой версии sql использовал все 32 ядра на 2 узлах numa (разделение 16/16). Улучшена производительность и т. Д.

Одним из вариантов, который мог бы улучшить вашу производительность, было бы использование регулятора ресурсов сервера sql для привязки большей части рабочей нагрузки к одному узлу numa. Например, вы можете создать пул ресурсов WEB_APP и аффинитизировать его, чтобы он работал только на 16-ядерном узле numa. Нагрузка, назначенная пулу WEB_APP, может использовать 50% емкости сервера плюс оставшиеся 12,5% емкости от 4-ядерного узла.

Другой вариант - ограничить количество ядер, доступных для сервера sql, до 10 с каждого узла numa.

StrayCatDBA
источник