(бесполезно писать в тему железа - там не в курсе по SQL Server специфике)

Выделили бюджет на год и одной из многих (взаимоисключающих) альтернатив
является обновление основного сервера (VM Host) под SQL / DWH задачи
(SQL Server 2019 Enterprise к его релизу, т.к. все нынче покупаемые лицензии на 2017
автоматом {upgradable} распространяются на 2019).
У компании свой ящик с железом в DC, туда вешаем VM с разными независимыми SQL Instance
лицензируются (perCore/Ent) все ядра хоста (около 50ти),
соответственно на VM всё автоматом без ограничений.

Основная тема там по поводу процессора/ов (в приобретаемом сервере),
т.е. обоснование выгодности смены железа.

В связи с этим вопрос(ы):

Во первых - у кого какой опыт с AVX 512 и приростом производительности по отношению
к AVX2 для DWH расчётных нагрузок (columnstore индексы и компрессия естественно)
нашел информацию что теоретически 512 битные регистры увеличивают производительность
на части тестов в 2 раза, но это к сожалению не практические тесты в SQL Srv экосистеме.

Во вторых - возникли разногласия если выбирать между Xeon Platinum и Xeon Phi
стоит-ли большая частота первого половине threads второго (т.е. 2x vs 4x на ядро)
в первом чуть выше частота, поддержка больше памяти, по каналам одинаково
при том что они архитектурно предназначены для немного разного рода нагрузок
(у нас стоит в том числе и активно используется ML компонент SQL Server)

Bronze не рассматриваем из-за отсутствия Multithreading и Per-Core системы лицензирования SQL Server, т.е. деньги за
лицензию те-же, а производительность больше чем в 2 раза меньше (Gold/Silver тоже по схожим причинам в чёрном списке)

Ещё: удавалось-ли кому перекидывать нагрузку SQL Server (или Machine Learning Services)
на GPU/CUDA или CoProcessors (на рынке куча дешевых слотовых Xeon Phi на PCIe под Linux),
И если (вдруг чудом) получалось то как в таком случае быть с лицензированием SQL Server
(все ядра CoProcessor, GPU/CUDA тоже надо лицензировать? тогда смысла нет, т.к. ядра
уж очень слабые/медленные получаются), можно даже SQL Server Linux версию если по другому никак.

У нас сейчас пиковая нагрузка в конце периодов (естественно когда всем вдруг нужна отчётность) - без проблем взлетает на весь
хост под 100% рывками до 20-ти минут (утро, перед обедом, закрытие дня), стоят Xeon Е7 v4 больше 20ти ядер на сокет,
на материнской с 2мя процессорами, есть небольшие опоздания по SLA на ночном ETL/ELT (тоже расчётные мощности)

Узкое место нагрузки именно процессор
(диски и так основные {система, база, темп} все SSD в параллельных RAID, там ок, сеть Teamed парами по 10Gb)
обучать пользователей немного бесполезно, да и затычная нагрузка явно не от одного пользователя,
и из разных ими сконструированных отчётов {постоянно меняющихся} на переделку {и слежение} которых
уйдёт больше ресурсов чем если просто бросить больше железа, плюс (ERP) приложения тоже проблема
(Legacy, и там тоже с разработчиками очень сложный разговор)

То что можно было вынести в облако (там гибкий Scale-Out / Scale-Up на пиках делаем, на ночь обратно - экономим)
уже вынесено, остальное безопасники (вполне обоснованно, там целый список рисков) не разрешают,
т.е. на данный момент разумных возможностей оптимизации процессов не осталось
так что решаем железом (хотя реально пока просто оценка рациональности).

в общем продолжу сам с собой (сам спросил, сам ответил) вести тихую беседу:

покопавшисть в и-нете, на основании вот этого документа тестирования для DWH нагрузок в феврале этого года:
(конфигурация: 2 х Xeon E5-2699 v3 vs 2 х Xeon 8280 )

и сравнении результатов показателей ( 33681 vs 903302 ), т.е. в общем система для DWH в 26.8 раз быстрее

сделал гипотетически-синтетический вывод что AVX-512 (и др. инструкции/оптимизации) даёт как минимум > +40%
(оптимистично: +200%, хотя разрядность регистров к AVX2 всего-лишь в 2 раза больше) к производительности на DWH нагрузках.

т.к. остальной прирост на 2х процессорной системе тестовой может быть из-за:
(чисто математически, предположения, т.к. других более точных данных нет, т.е. по узким местам и загрузке по пределам к 100%)
1) больше ядер/потоков (threads): 72 vs 112 (+55%)
2) более высокой частоты ядер: 2.3 vs 2.7 (+17.4%)
3) по кэшу примерная (усреднённая оценка) разница на +230% (без нюансов на L1/L2/L3)
4) более высокая пропускная способность CPU Bus на оба сокета: 38.4 vs 62.4 GT/s (+62%) , { 3 x 10.4 x 2 }
5) выше проп. способность по памяти (и её частота) с учётом каналов (4 vs 6): 136 vs 262 GiB/s (т.е. 22х6 каналов x2 сокета) +93%

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

т.е. вложив больше в производительный/современный процессор
можно потенциально в разы сэкономить на SQL лицензиях
(не придётся покупать больше процессоров и лицензировать их чтобы получить такую-же скорость выполнения запросов).

как раз тот случай когда финансово выгоднее поставить получше железо вместо покупки больше софта (и старого железа)

если по каким-то причинам облака не рассматриваются - там оплачиваемые расчётные мощности под нагрузку регулируются админами,
тоже получается намного дешевле, т.к. вариант покупки/аренды железа в Data Center не даёт ежедневной гибкости (по часам)

пошел копать по поводу параллельной производительности на MKL и AVX-512 +TSX (vs AVX2)
но это уже больше для ML (RevoScaleR) компонента SQL Server.

хотя если у кого есть мысли именно по Xeon Phi vs Xeon Platinum - то вопрос всё ещё открыт

(не смотря на то что по идее уже определились с Platinum
и навряд-ли будем рисковать на такую пока ещё неопробованную экзотику)

alexeyvgА сиквел работать будет на Xeon Phi?
Xeon Phi вообще похож на какой то нишевый эксперимент, даже на сайте интеля информации негусто.

выгоду от Phi была идея получить из-за 4х поточности (вместо стандартного HT, т.е. 2x)
на одну лицензию, т.е. max_dop при однослотовом сервере можно было ставить 288

(если о нём говорить - то смотря в каком контексте - тема больше железная может получится)
раньше были в слотовых CoProcessor вариантах на PCIe (с Linux операционкой)
последние вышли с полноценной отдельной материнской (даже поначалу думал что на 2 и больше
слотов, хотя по спецификации процессора вроде были только на S1, но потом оказалось
что Scalable/Platinum и Phi оба на похожие слоты: 3647)

вот тестирование не PCIe - Phi (7210) с играми на Windows Server

alexeyvgЛучше сказать - в современный процессор с максимальной производительностью одного ядра.
Т.е., если вас интересует минимизация цены лицензии в расчёте на единицу производительности, то нужно брать процессоры из группы "Optimized for highest per-core SCALABLE performance", притом те, у которых меньше ядер
Например, 8256 (самый быстрый, но самый дорогой), или попрощке - 6246, 6234
в остальном спасибо, пока похоже что да: что-нибудь с двумя сокетами 12ти ядерных Gold 6246
вполне подойдёт для первой тестовой волны (как раз и лицензии на одном сервере консолидируются,
без необходимости добора дополнительных), вполне вероятно что хватит и забудут эту тему года на 3-4

по идее можно даже сервер на 4 сокета - a процессора под них потом добрать если действительно приспичит,
но из тех что в наличии есть все и DualSocket и QuadSocket (SuperMicro) - пока пишут что максимум ядер = 28
т.е. реально пока можно только двухслотовые брать, и по бюджету вполне приемлеммо

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

Andrey Sribnyak,

нам MS при покупке представитель подтвердил (причём не спрашивали) и в Invoice написано в наименовании продукта.
причём в дургой компании похожая ерундень была при покупке 2012го (распостранялась на 2014й)

но это были Core лицензии

только это было уже в первый месяц после релиза..