> э... и ты можешь обосновать это решение?Это пример экстремального случая.
Например, если мы возьмем PostgreSQL и поставим его на многопроцессорный сервер, который собрали как бык поSSaл, то есть есть один печальный сетевой адаптер Intel на первом сокете и HBA, которая торчит на другом сокете, то мы получим то самое чудовищное снижение производительности в десятки процентов по сравнению с односокетником, когда растёт нагрузка.
Вся идея использовать shared memory, fork-join и прочий OpenMP-образный код в том, что память общая. А она больше не общая. На Intel Xeon Scalable и AMD Epyc у тебя якобы физическое ядро может быть, а доступа к DRAM-контроллеру с него нет. То есть у тебя даже на односокетнике безудержное веселье.
Как выходят из положения постгресы и прочие nginx? А вы пойдите в UEFI вашей матери и всё NUMA API отключите. Пусть ОС думает, что у нее все ядра имеют одну и ту же дистанцию. И это вполне официальное решение от автором этого ПО. Иначе гадкая ОС не даёт божественному софту утилизировать эти ядра ввиду нежелания рвать процессы по NUMA. Вот только производительность этого решения (выполнения конкретного запроса) становится лотереей. Ну ок, утилизировали, криво косо работает. Да? Нифига. Если у тебя ни ОС ни постгрес не понимают, что сеть и сторадж на разных узлах NUMA, то у тебя весь сторадж и сетевой трафик польётся через интерконнект-шину. А при этом требования к когерентности кэшей никто не отменял. И что у тебя будет с L3-кэшем при этом. Он будет загажен постоянной передачей данных от HBA и сетевки.
Теперь возьмем эту же базу и поместим её на виртуалку к хостинг-провайдеру, который сервер умеет собирать. Чудо-чудное диво-дивное. И потом ты услышишь "Наша база в облаке работает быстрее" и другие офигительные истории от штатных разработчиков предприятия.
При этом в базах типа MSSQL и Oracle ты должен:
- включить суб-кластеризацию NUMA, то есть сделать так, чтобы каждый процессор в твоем сервере разделился на 2 или 4 узла NUMA, чтобы явно дать привязку DRAM-контроллера к нужной группе ядер
- Выключить своё SMT/Hyper Threading и прочий булщит для десктопов
- Отключить Hardware Prefetcher и Adjacent Cache, потому что SQL-сервера будут только давать cache miss, они не работают с данными они работают со ссылками на данные, которые потом вновь приходят и обрабатываются в следующем цикле.
- симметрично расположить плашки памяти с соблюдением ранговости, чтобы все ядра получили свою память
- вырубить фиктивные ядра, если процессор позволяет. У Intel есть серия с "Y" на конце, которая и нужна для SQL.
И вот вполне нормально при этом иметь 4-8 независимых узлов NUMA и несмотря на то что у тебя оно никогда не симметрично, всё работает шикарно. Ведь нормальный SQL-сервер:
- имеет свой собственный страничный кэш
- имеет встроенный сетевой полинг и оптимизатор запросов
- сам напрямую производит элевацию мимо стандартных драйверов или имеет единственно верную ФС
- имеет кластерную ФС, которая оптимизирована для этой работы, если за ней SAN
Обрати внимание, что вся оптимизация делается наоборот. В PostgreSQL ты должен максимально эмулировать поведение сервера 2007-года выпуска.
> он его точно-точно не потому выбросил что хочет такое же но чтоб без этих ваших игорь в шва6одку
Он его выкинул потому что тащить саппорт: RHEV, OpenStack и OpenShift слишком потно. Особенно потно в случае с OpenStack. Они сели переводить провайдеров на OpenShift, сам по себе RHEV не даёт тебе ничего особенного, а пилить его надо в том же направлении, что и OpenShift вот они и сократили расходы.
Они приходили к нам несколько лет назад с туманным предложением "покупайте наших слонов" причем слоны дешевые, дешевле Windows даже. На резонный вопрос "а зачем", ответили что у нас есть новая CSP-программа, которая не понятно зачем нам нужна и мы ничего там не делаем. Просто продаём наш RHEV и поверх него даём OpenStack и спрашиваем, как вы этим пользуемся. Видимо беклог заполняют, облака-то своего нет, а IBM-облако вообще к ним не имеет никакого отношения. Просто если у тебя есть один и тот же криво интегрированный в юзерспейс KVM, который титанически сложно менеджить в крупном развертывании, то зачем тебе развивать 2 конкурирующих между собой продукта, которые его фигово готовят. OpenStack при этом всегда сверху и он не помогает, а скорее мешает с его требованиями к плейсментам схожих шаблонов/флейворов на отдельных кластерах. Он выгоден от 10000 физических хостов и выше.
Опять же Red Hat OpenStack залочен на RHEV, а средних размеров хостинг провайдер всегда хочет иметь хотя бы 2 гипервизора. И он дорогой был. Его будут херить тем же способом, что херят остальные опенстеки. Содержат, пока есть провайдер. Не рекомендуют покупать (нам уже не рекомендовали) и вот потом отменяются мажорные апгрейды внутренних модулей. Оно фиксируется в определенном релизе, пока не подохнет.
> на минуточку - до третьей включительно версии был вполне себе работоспособен.
Ну OKD и сейчас живо, просто это несколько другой продукт сейчас. 3 и 4 разные.
