Тактовая частота ЦП в сравнении с количеством ядер ЦП - выше ГГц или больше ядер для SQL Server?

Мы начинаем предоставлять набор физических серверов для виртуального кластера узлов SQL Server 2016 в VMware. Мы будем использовать лицензии Enterprise Edition.

Мы планируем настроить 6 узлов, но ведется небольшая дискуссия о том, какой идеальный способ обеспечить физические серверы с точки зрения тактовой частоты ЦП и количества ядер ЦП.

Я знаю, что это в значительной степени зависит от объема транзакций и количества баз данных, хранящихся среди других специфичных для программного обеспечения факторов, но рекомендуется ли применять общее правило?

Например, является ли двойной 8-ядерный физический сервер 3,2 ГГц (16 ядер) более предпочтительным, чем двойной 16-ядерный сервер 2,6 ГГц (32 ядра)?

Кто-нибудь сталкивался с белой книгой, которая углубляется в этот тип темы?

Основное правило заключается в том, чтобы поддерживать минимальное количество ядер и максимально высокую скорость процессора. Математика лицензирования, подтверждающая это, составляет ~ 7500 долларов США за ядро ​​для дорогой версии.

Покупка правильного оборудования может окупиться за счет снижения затрат на лицензирование. См. Выбор процессора для SQL Server Гленна Берри. Это отличный ресурс о том, как выбрать процессор для SQL Server.

Принимая во внимание структуру лицензирования SQL Server для каждого ядра, имеет смысл всегда использовать самую быструю доступную скорость процессора, независимо от типа рабочей нагрузки, будь то OLTP или аналитика. Самая быстрая скорость ядра никогда не будет проблемой. Увеличьте число ядер по мере необходимости, но никогда не делайте этого, уменьшая скорость ядра.

Другими словами, не думайте, что процессоры с тактовой частотой 16 x 2,2 ГГц совпадают с процессорами с тактовой частотой 8 x 4,5 ГГц. Экономия затрат при использовании процессоров с частотой 2,2 ГГц по сравнению с процессорами с частотой 4,5 ГГц может составить максимум около 10 000 долларов США (для типичной двухпроцессорной машины на базе Xeon). Переход с 8 ядер на 16 ядер в SQL Server Enterprise Edition, вероятно, будет стоить более 60 000 долларов США в виде лицензионных сборов. Другими словами, вы можете сэкономить 10 000 долларов на аппаратных затратах, но вы потеряете дополнительные 50 000 долларов на лицензировании.

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

Сказав все это, если выбор - один ЦП или несколько ЦП, всегда выбирайте более одного . Запуск SQL Server (или любой СУБД) на одном ЦП может вызвать всевозможные проблемы, поскольку возможности одновременных операций значительно ограничены.

Держись держись держись

Хотя аспекты производительности и лицензирования интересны, они не являются единственным аспектом рабочей нагрузки, который следует учитывать.

Одна вещь, которая может повлиять на выбор процессора, это рабочие потоки.

Рабочие темы?

Да приятель! Это те вещи, которые ваш SQL Server будет использовать для выполнения ваших запросов и выполнения всех фоновых операций, необходимых для поддержания формы.

Когда у вас заканчиваются рабочие потоки, вы нажимаете THREADPOOL ждет

Threadpool?

Threadpool. Это одно из самых неприятных ожиданий на вашем сервере, а также RESOURCE_SEMAPHORE и RESOURCE_SEMAPHORE_QUERY_COMPILE . Но это ожидание памяти, и это вопрос процессора.

Итак, вернемся к тому, почему это вихрь.

Вот как SQL Server вычисляет рабочие потоки :

Обратите внимание, что удвоение числа ядер не удваивает максимальное количество рабочих потоков, и вы получаете то же число с 1 ядром, что и с 4 ядрами? Уравнение:512 + ((logical CPUs - 4) * 16)

Это позор, потому что когда число ядер увеличивается, тактовая частота обычно падает на одно или два поколения назад.

Взглянув на любую недавнюю линейку чипов Intel, вы увидите аналогичную тенденцию.

Как мне узнать, сколько потоков мне нужно?

Это будет во многом зависеть от:

• Количество пользователей
• Количество параллельных запросов
• Количество последовательных запросов
• Количество баз данных и синхронизация данных (зеркалирование, AG, резервные копии для доставки журналов)
• Если вы оставите MAXDOP и CTFP по умолчанию

Если вы не исчерпали их сегодня, вы, вероятно, в порядке.

Но откуда ты знаешь, что ты есть?

Есть хорошие вопросы, и есть отличные вопросы, и позвольте мне сказать вам кое-что, это БОЛЬШОЙ ВОПРОС .

THREADPOOL может проявляться как проблемы с соединением , и вы можете увидеть сообщения в журнале ошибок о невозможности порождения потока .

Вы также можете посмотреть статистику ожидания вашего сервера с помощью бесплатного инструмента, такого как sp_Blitz или sp_BlitzFirst (полное раскрытие, я участвую в этом проекте).

EXEC sp_Blitz

EXEC sp_BlitzFirst @SinceStartup = 1

Разве я не могу просто увеличить максимальное количество рабочих потоков?

Увеличение MWT может привести к увеличению SOS_SCHEDULER_YIELDожидания.

Это не конец света, но подумайте об этом, как о добавлении кричащих детей в класс учителя.

Внезапно каждому ребенку будет сложнее привлечь внимание.

Когда процесс исчерпает свою квоту в 4 мсек , потенциально может быть больше потоков, ожидающих загрузки процессора.

Производительность может показаться примерно такой же.

Как я могу использовать меньше рабочих потоков?

Вы жестокие [существительное] [существительное], это работники с семьями, чтобы поддержать! Ипотеки! Мечты!

Но хорошо, должен уважать практический результат. Ты босс.

Начать проще всего с изменения настроек по умолчанию, таких как MAXDOP и Порог стоимости для параллелизма.

Если у вас есть вопросы о том, как их установить, зайдите сюда:

• Алгоритм установки MAXDOP для SQL Server

• Почему порог стоимости для параллелизма не должен быть установлен на 5

После этого ваша работа становится намного сложнее. Вы должны выяснить, что использует все эти темы. Иногда вы можете сделать это, посмотрев статистику ожидания.

Более конкретно, если у вас высокие ожидания при параллелизме ( CXPACKET) И высокие ожидания при блокировках ( LCK_), то вы можете столкнуться с длинными цепочками блокировки, включающими параллельные запросы.

Вы знаете, что воняет? Хотя все эти параллельные запросы ожидают получения своих блокировок, они не возвращают свои выделенные потоки.

Вы можете почти услышать, что четыре ядра виртуальной машины, которые, как заверил ваш администратор, вам более чем достаточно для любой работы, задыхающейся в воздухе, а?

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

Надеюсь это поможет!

_{Ответ сообщества вики :}

Коротко и коротко: большинство рабочих нагрузок для SQL Server - это OLTP, который выигрывает от более высоких тактовых частот, потому что это последовательная операция.

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

Ответ сводится к следующему: это зависит от вашего варианта использования.

• Вы обрабатываете несколько небольших запросов одновременно или несколько больших запросов?
• Программа, которую вы запускаете, даже оптимизирована для многоядерности?

Например, у меня есть четырехъядерный компьютер, но компилятор ESP8266 использует только 25% моего процессора, потому что он предназначен только для одного ядра. Если бы у меня было 1 быстрое ядро, то это было бы более оптимальным.