Топология памяти
Очень часто вижу подход к серверам и вычислительной инфраструктуре на кухонном уровне даже от вроде бы профессиональных людей с высочайшими ЗП в полмиллиона и выше.
Сервер - это просто большой макбук, а СХД просто большой диск.
Итак, давайте разбираться. И начнем со страшной темы - топология памяти.
Объяснять буду реально на желудях и шишках, поэтому сразу просьба к крутым суперпрофи - не надо пытаться меня уличить, это не для вас написано.
Есть процессор, который исполняет команды, и канал доступа к памяти, которая требуется для этих команд. Канал характеризуется двумя показателями: задержка доступа (через сколько наносекунд придет ответ), ширина канала (сколько гигабайт в секунду).
Задержка. UMA / NUMA
UMA - Uniform Memory Access, архитектура с равномерным доступом к памяти. В многопроцессорной (многоядерной) системе расстояние (задержка) от любого процессора (ядра) до любого блока памяти постоянна и одинакова.
NUMA - NonUniform Memory Access, архитектура с НЕравномерным доступом к памяти. В многопроцессорной (многоядерной) системе расстояние (задержка) от процессора (ядра) блока памяти различна.
В чем разница для программиста / архитектора-проектировщика? В случае с NUMA системой нужно продумывать особенности развертывания системы (модулей) и конфигурации, чтобы работать на полной скорости, избегая (минимизируя) дальние обращения. Если вы не понимаете как с этим работать, то легко получите до минус 30% производительности.
Напомню любителям AMD, что недавние поколения серверных AMD имели NUMA архитектуру даже внутри сокета. Т.е. по сути это был хак - два кристалла упаковали в один корпус.
Топология процессоров (при >2)
В случае с 2 процессорами все понятно, есть CPU1 <-> CPU2. А вот уже при 4 процессорах становится интереснее. Есть варианты с полносвязной системой и с промежуточными узлами.
Полносвязная система - когда есть прямой канал от каждого процессора к каждому, и соответственно задержка при обращении к чужой памяти одинаковая.
Система с промежуточными узлами имеет меньшее количество линков. Т.е. всего по два линка на каждый процессор.
CPU1 <-> CPU2 <-> CPU4
CPU1 <-> CPU3 <-> CPU4 И в этом случае CPU3 при обращении к памяти CPU2 получает двойную задержку, что еще сильнее роняет производительность.
Ширина памяти
Ширина (ПСП - пропускная способность памяти) обеспечивается целой кучей параметров, из которых остановимся на двух: количество каналов памяти на контроллере памяти, скорость модуля.
И начнем со скорости. Все, кто выбирал (собирал) компьютер, видел такую вещь как DDR4-2933 (цифры могут меняться). Совсем на пальцах - DDR3, DDR4, DDR5 - это условно формат гнезда памяти, т.е. модуль DDR5 не вставишь в сервер с DDR3 слотами. А 2933 (иногда PC2933) - это собственно скорость этого модуля. Причем измеряется она не в MHz, как иногда ошибочно пишут, а в MT/s.
DDR - Double Data Rate - способ передачи информации с удвоенной скоростью, когда информация передается не самим 0/1, а на фронте / спаде сигнала. Поэтому настоящая частота в два раза ниже. Т.е. PC3200 - это 3200 MT/s (mega transfers / sec), которая работает на частоте 1600 MHz.
И вот в какой то момент мы начинаем выедать полную ширину и ограничиваемся в производительности скоростью памяти.
Поэтому придумали многоканальные контроллеры памяти - можно одновременно и независимо друг от друга обращаться сразу к нескольким модулям памяти. Что в конечном итоге увеличивает теоретическую ПСП в N раз (N - количество каналов). А для двухпроцессорной системы в 2 N раз соответственно. Теоретическую - потому что в реальности еще все зависит от того, как данные размазались по физическим модулям памяти, конечно же.
И вот тут следует вопрос: так продаются же крутые модули памяти, 6000, давай ими и набьем сервер.
Здесь есть два момента:
крутые модули типа 6000 - это НЕрегистровая память для энтузиастов игроманов-оверклокеров. Если вдруг чо, то ну перегрузишься, ничего страшного.
серверная память - регистровая, т.е. там стоит дополнительная микросхема для возможности установки большого количества памяти (больше модулей на канал).
Короче, в зависимости от класса сервера такую память либо нельзя / либо не надо ставить (как рекомендация).
Почему такая принципиальная разница в десктопном / северном мире?
Десктопные процессоры - это процессоры для однопроцессорных машин, причем максимум с двумя каналами памяти (массовый сегмент). Когда ты исчерпал два канала, остается только повышать частоту.
Серверные процессоры решают проблему ширины памяти путем многопроцессорных конфигурация с много (более 2) канальной памятью. Например Xeon Scalable v2 имеет 6-канальную память (и этим обуславливается объем памяти кратный 6 модулям - 192, 384, 768).
Десктоп 1 * 2 * DD5 5600 = 11 200 (Core i9)
Сервер 2 * 6 * DDR4 3200 = 38 400 (Xeon Scalable v2)
Сервер 2 * 8 * DDR5 4000 = 64 000 (Xeon Scalable v4)
Вы можете возразить, а как же AMD Ryzen ThreadRipper? Там 8 каналов памяти. (У Intel существовала серия Core X с 4 каналами).
Да, вы совершенно правы. Только посмотрите на его стоимость, он подороже иных Xeon будет, и именно это обуславливает его крайне нишевое применение, где он борется за место уже с рабочими станциями на серверных процессорах.
* по маркировке. Может применяться DDR4 3200 = PC4 25600 (MB/s)
Выбор процессора.
Встал тут в чатике вопрос – какой процессор взять, Xeon 5317 или 6330? Давайте разберем на этом примере на что смотреть и что имеет значение.
Для простоты задачи сразу примем как данность, что сервер у нас большой, минимум 2U и нет проблем ни с питанием, ни с охлаждением. Не вдаваясь в размышления почему именно эта пара, давайте ее рассмотрим.
Оба процессора относятся к одному поколению, Xeon Scalable v3
5317 – 12 ядер по 3 GHz, 3.6 турбо, 18 MB L3
6330 – 28 ядер по 2 GHz, 3.1 турбо, 42 MB L3
Самый простой способ сравнить в лоб – база * ядра. Итого 36 против 56 (все коэффициенты гипертрединга считаем одинаковыми и просто выбрасываем из рассмотрения). Казалось бы, что тут еще сравнивать?
А вот здесь кроется проблема в наличии понимания как работает процессор, ядро ОС, планировщик гипервизора и прикладное ПО.
Чисто теоретически 6330 превосходит 5317 в 56 / 36 в 1.56 раза, но для реализации этого превосходства необходимо подать на него соответствующую нагрузку. А именно – множество слабосвязанных потоков, способных загрузить то самое превосходящее количество ядер. Причем именно слабосвязанных, посколько по мере роста связности и зависимости потоков начнется фрагментация времени продуктивной работы и накладные расходы на синхронизацию. Т.е. это процессор для массы VDI машин с 2-4 vCPU или кучи каких то контейнеров, причем реально кучи, с коэффициентом vCPU / pCore от 5 и выше.
Если же двинуться от множества маленьких машин к некоторому количеству машин большего размера при общем снижении vCPU / pCore, то рано или поздно начинает играть фактор низкой частоты на ядро.
Максимальная производительность ВМ с 6 vCPU на 5317 = 18 GHz. Для 6330 чисто гипотетически можно дать 9 vCPU, но как мы понимаем, ситуация с равномерной загрузкой ядер практически невозможна, если это не расчетная ферма. И в реальной ситуации часто есть нагрузка на 1-2 ядра. Т.е. фактически это не 18 GHz, а 6 против 4. Или при учете турбо – 7.2 против 6.2. И что интересно, словить турбо на 28 ядерном процессоре значительно сложнее, т.е. 7.2 против 4-5.
6330 имеет почти в 3 раза больший L3 кэш, спору нет, крайне полезное приобретение при прочих равных.
А теперь давайте попробуем узнать – есть ли какая то текущая статистика по нагрузке, чтобы прогнозировать потребности.
Автор вопроса дал такую статистику: сервер с 2 * Xeon 4210 (10 * 2.0, 3.2 Turbo) и 768 памяти загружен на 22% и 45% по процессору и памяти соответственно. Или грубо мы получаем 1 GHz / 32 GB.
Имея такую загрузку можно спрогнозировать сбалансированные конфигурации на 5317 / 6330. И это соответственно 2.3 и 3.5 TB RAM.
Т.е. фактически даже при установке 2 TB RAM в сервер 6330 никак не может показать свою потенциальную мощь и превосходство над 5317. А вот 5317 не просто превосходит текущие 1 / 32, но и дает бОльшую производительность тем же машинам в силу большей частоты на ядро.
Комментарии (55)
NotSlow
10.08.2023 09:31"Десктопные процессоры - это процессоры для однопроцессорных машин, причем максимум с двумя каналами памяти"
А эти серверные?
cat_chi
10.08.2023 09:31А есть опыт установки двух и более этих процессоров в одну машинку?
NotSlow
10.08.2023 09:31Но по вашему сервер - это только 2 и более cpu? Однопроцессорных не бывает?
И я лишь к тому, что открываем любой по ссылке выше и: "Segment - Desktop" т.е. Интел считает их десктопными, у них нет поддержки ECC. Однако количество каналов памяти 4. И потому утверждение "максимум с двумя" не верно.
cat_chi
10.08.2023 09:31Но по вашему сервер - это только 2 и более cpu?
А я-то здесь причём :)
Вы комментируете конкретный тезис автора – "десктопные процессоры это для однопроцессорных машин".
Я говорю про то, что ваш аргумент этот тезис вообще не опровергает.
Но если вы имели в виду не многопроцессорные конфигурации, а именно количество каналов – тогда извиняюсь, не понял.
Однопроцессорных не бывает?
В соседнем треде я как раз пишу про то, что бывают не только однопроцессорные, но и "сервера" с десктопными процессорами :)
NotSlow
10.08.2023 09:31Понял :) надо было жирным выделить на что именно отвечаю - "Десктопные - максимум с двумя каналами памяти". А не про двухпроцессорность.
AntonVirtual Автор
10.08.2023 09:31Нишевые процессоры с очень малой аудиторией, и очень высокой стоимостью. Которые в массе ни на что не повлияли и были дропнуты.
NotSlow
10.08.2023 09:31+3Однако они существовали аж с 3 по 10е поколения. И у них было 4 канала памяти. Я лишь обратил внимание, что не у всех десктопных 2 канала максимум.
AntonVirtual Автор
10.08.2023 09:31Вы правы, что существовали. Но существуют и ThreadRipper, которые технически десктопными считаются.
Раз настаиваете, то добавлю про Core X
NotSlow
10.08.2023 09:31+7Как я понял, если процессор один, то это за сервер не считается? Но кто сказал что сервер - это только про много ядер и не про скорость, про высокую частоту, про отсутствие вот этих всех NUMA проблем и других падений производительности?
Под каждую задачу нужен свой подходящий инструмент. А не так что только перфоратор - это профессиональный инструмент, а шуруповерт - это что-то "домашнее".
Задачи могут быть разные. Кому-то нужен грузовик перевезти максимум груза за раз (максимальное число ядер внутри 1-2U корпуса и плевать на частоту ядер и задержки памяти). А кому-то нужно максимально быстрый и не сильно дорогой подвоз каких-то легких грузов. И если таких грузов будет больше - будет добавляться большее количество шустрых "мопедов", а не переход на один общий неповоротливый грузовик. Исключительно от применения и целей зависит выбор сервера.
AntonVirtual Автор
10.08.2023 09:31Смысл статьи - обзор того, что является массовым и специфичным для серверов, и где обычно неопытные проектировщики делают ошибки.
В случае с однопроцессорными серверами NUMA точно так же может быть актуальна (не все процессоры 1 socket = 1 NUMA node). Но даже в случае отсутствия проблем с NUMA остается вопрос правильного наполнения памятью по каналам и возможности упереться в общую ПСП.
Если у вас однопроцессорный ненагруженный сервер и проблем нет - ну значит все прекрасно.
Kill_Voice
10.08.2023 09:31Думаю все всё понимают, даже скажу более в промышленном оборудовании, не только серверами едины. Замена промышленного оборудования на бытовое это классический quick win "эффективного" менеджмента, менеджеры показывают экономию в 100500 миллионов, выполняется KPI, какое-то время схема даже работает, а после проблему разгребают годами уже другие люди. Отсюда и эти восхитительные идеи в стиле, а давайте всё заменим на raspberry pi или сделаем резервный канал через GSM модем
akakoychenko
10.08.2023 09:31+8Ох уж эти выводы из частного в общее...
длинный бородатый анекдот
Жил в деревне мужик и было у него три
сына.
Раз утром отец возвращается со двора и
говорит:
- У нас корову украли.
Старший сын: - Раз кто-то украл, значит ***.
Средний сын:
- Раз ***, значит из Марьинки.
Младший:
- Раз из Марьинки, значит Ванька Косой.
Пошли в Марьинку, поймали Ваньку, дали в
ухо: - Верни корову!
- Нет у меня коровы!
Дали еще раз:
- Верни корову!
- Нет у меня коровы! - Тогда пошли к мировому судье.
Приводят Ваньку к судье и говорят:
- Вот он у нас корову спиздил.
- А почему вы решили, что именно он у
вас
корову украл? - Ну как!
- Раз кто-то украл, значит ***. - Раз
***, значит из Марьинки.
- Раз из Марьинки, значит Ванька Косой.
- Да... Интересная логика.
Судья подзывает секретаря, что-то говорит
ему на ухо, секретарь уходит и через
некоторое время возвращается с
закрытой коробкой. Судья:
- А скажите-ка мне, что в коробке.
Отец: - Коробка квадратная.
Старший сын:
- Раз квадратная, значит в ней что-то
круглое. Средний сын:
- Раз круглое, значит оранжевое.
Младший: - Раз оранжевое, значит апельсин.
Судья открывает коробку, достает из нее
апельсин и говорит:
- Ванька, ***, верни коровуА именно – множество слабосвязанных потоков, способных загрузить то самое превосходящее количество ядер. Причем именно слабосвязанных, посколько по мере роста связности и зависимости потоков начнется фрагментация времени продуктивной работы и накладные расходы на синхронизацию. Т.е. это процессор для массы VDI машин с 2-4 vCPU или кучи каких то контейнеров, причем реально кучи, с коэффициентом vCPU / pCore от 5 и выше
А ничего, что, наоборот, иметь кучу ядер в рамках одной системы - едино возможный вариант делать задачи с большим количеством сильно связанных потоков? Потому, что даже через самую теоретически неэффективную схему общения ядер и памяти работать все будет с куда меньшими задержками и более высокими пропускными способностями, чем если синхронизироваться через сеть с другой машиной? Тот же MS SQL Server, к примеру, отлично параллелит аналитические запросы в рамках одной машины (лично я до 160 потоков параллелил с загрузкой проца на 100%) с линеным ростом скорости, а многомашинного режима там нет вовсе (PDW не в счет).
Да зачем аналитические - любые мелкие однопоточные транзакционные запросы к оперативной БД отлично параллелятся между собой в рамках одной системы, и 4х, а то и 8 сокетные монстры с нешардированным Oracle/MSSQL/MySql/pgSql часто являются именно той единой точкой, через которую проходит все оперирование глобальной корпорации.
Можно это все и расшардировать, конечно, только это потребует кратного увеличения кода в сервисах, чтобы элиминировать всю радость распределенных транзакций и корректно обработать рейс кондишн, случающийся раз в год, но при этом имеющий возможность уничтожить репутацию корпорации за раз.
Возвращаясь к посылу автора, он примерно такой: "у меня есть система, где есть способ передачи данных между потоками со шириной в десятки гигабайт/сек, и задержкой на порядки ниже 1 мс, и это для меня настолько оскорбительно мало, что я отказываюсь использовать его из принципа и рекомендую покупать это оборудование только для задач, где этот протокол использоваться не будет". Не это липодход к серверам и вычислительной инфраструктуре на кухонном уровне
?
AntonVirtual Автор
10.08.2023 09:31-8В эпоху облаков, микросервисов и кубернетесов вы вспомнили про монолиты и Bare Metal с нагруженными СУБД. Смею вас уверить, автор в курсе что это такое и давным-давно этим занимается.
Вы пропустили пойнт про сравнение производительности ВМ в 6 vCPU, например.
И тот пойнт, что 10 ядер по 4 ГГц лучше, чем 20 по 2.
Равно как и пойнт, что статья предназначена для тех, кто вообще не в курсе что такое NUMA, ПСП и многоканальная память.
Поэтому да, коллега, вы правы при разговоре о "сильносвязанных потоках" в пределах широкого (в размер сервера) монолита, но это не тема статьи.
VVitaly
10.08.2023 09:31+4А кто-то знает не монолитные OLTP ACID DB, которые можно эффективно "размазать по микросервисам" на нескольких физических серверах? :-)
akakoychenko
10.08.2023 09:31Я знаю одну
AWS Aurora;)
Но там ноу-хау в том, что, фактически, взят движок постгреса, и в нем установлены проприетарные модули, подменяющие часть самых критичных дисковых операций хранением в оперативной памяти на 6 разных машинах в разных гео. За счёт этого есть взрывной рост перфоманса на задачах, которые слоник очень не любит.
Но, снова таки, основная сила там именно в этом хаке, подменяющем диск ну очень надежным RAMом.
AntonVirtual Автор
10.08.2023 09:31+1Забавно, что современные SSD быстрее, чем размазывать IO по сети по гео.
akakoychenko
10.08.2023 09:31Сомневаюсь, что для всех алгоритмов, которые в принципе можно выполнить как на ssd, так и на памяти геораспределенно. Даже, если говорим о PMEM, называя его ssd.
VVitaly
10.08.2023 09:31:-) Можно использовать все что угодно... Хоть Oracle RAC, но блокировки блоков данных в памяти (для синхронизации их в отдельных нодах) через сетевые (или проприетарные) интерфейсы всегда будут тормозить транзакции БД...
AWS же не даром упоминает в рекламе Aurora ускорение только чтения... :-)akakoychenko
10.08.2023 09:31Лично у меня выходило до 10 раз именно на апдейтах ускорение aurora vs pg на железе. При том, что бенчмарком выступал сервер с 4мя nvme что-то типа intel p4600, терабайтом рам, и парочкой уже не помню каких xeon gold. Все кроме апдейтов плюс-минус на равных шли.
Чтение то и без Авроры отлично слейвами разгоняется до нужных скоростей.
VVitaly
10.08.2023 09:31+1в PG (и его клонах) UPDATE = INSERT (с нюансами индексов и AUTOVACUUM)... Маркетинговые заявления и показатели на "подточенных" тестах (не важно каких компаний) "по факту" плохо согласуются с результатами тестов на реальных бизнес приложениях...
RH215
10.08.2023 09:31И тот пойнт, что 10 ядер по 4 ГГц лучше, чем 20 по 2.
Да, но чаще встаёт выбор между 10 по 4 и 30 по 2.
AntonVirtual Автор
10.08.2023 09:31В абсолютном большинстве случаев это искусственно навязанный выбор.
Количество ядер и частота - это функция от бизнес требований, специфических технических требований или требований регулятора. И не в последнюю очередь еще и вопрос лицензирования ПО может сыграть свою роль.
Еще в 2017 я собрал заметки и оформил в виде большой статьи как проектируется и как делается выбор CPU / RAM. https://habr.com/ru/articles/321178/
В конечном итоге можно упереться в выбор "что есть на складе у поставщика" конечно, но это объективные обстоятельства.
BugM
10.08.2023 09:31Все еще хуже. В компаниях побольше могут сказать: Есть вот такая конфигурация серверов, закупать под ваш проект другую никто не будет. Работайте на этих. При следующей закупке через 5 лет можно подумать и о другой конфигурации. И приходится работать. Софт тоже нормально подгоняется под доступные сервера.
atshaman
10.08.2023 09:31А у microsoft'а как это ни забавно с этим прям хорошо. А вот postgres с бизнес-логикой - прям боль была.
Nipheris
10.08.2023 09:31+9серверная память - регистровая, т.е. там стоит дополнительная микросхема для повышения стабильности работы.
Ну раз это статья-ликбез, давайте не допускать фактических ошибок. Регистровая память - это всё-таки про снижение электрической нагрузки и про повышенный объём на планку памяти (который будет недоступен на обычной материнке без поддержки регистровой памяти) за счёт большого количества чипов на планке. А "стабильность работы" - это скорее про ECC, что бывает и на unbuffered-памяти. Вот только на днях подыскивал нерегистровую ECC DDR5.
vanxant
10.08.2023 09:31+1Зашёл написать этот коммент:) У автора смешались в кучу конелюди.
Исправлением ошибок занимается ЕСС. А регистровая память это про объём, причём ценой задержки. Процессоры по своим электрическим ТТХ тянут только два модуля памяти на канал (ну вот так решили, что двух хватит в 99% случаев, а если закладывать больше, то надо больше мощности, токов, ширше дорожки на плате и т.д). И этот самый регистр работает "усилителем" и позволяет подключить к нему до 8 модулей, притворяющихся для процессора одним. Внутри это часто выглядит как слоёный пирог из 8 наклеенных друг на друга чиплетов внутри одной микросхемы.
Seawind
10.08.2023 09:31Знакомый как-то в давние времена пересел с двухпроцессорного сервера на вторых пнях на десктопный процессор который и по частоте и тестам обгонял тот сервер в разы. И действительно все летало пока админ был один в терминале. Как только на новый комп в свои терминалы зашли пользователи (около десятка офис + 1с) начались случайные секундные подвисания. Раньше все было медленно но равномерно, а тут то быстро то подвисли. Так мы на собственном опыте увидели разницу между серверным и десктопным процем. Ах да, там еще и в дисках разница была, SCSI vs IDE.
1dNDN
10.08.2023 09:31+2Так если новый диск был гораздо медленнее старого и тормозил все, то может всё-таки не процессор виноват был?
Seawind
10.08.2023 09:31Ну как сказать, не думаю что древние SCSI были быстрее относительно нового IDE. Вот при большом количестве одновременных запросов они их обрабатывали равномернее, в отличии от десктопного IDE. Смысл моего комментария в том, что хоть и старое но серверное железо работало комфортнее для пользователей чем новое но десктопное.
I_AM_I
10.08.2023 09:31+1Мир к подобной абстрацкции console.log от электронов шел 70 лет. Сервак нынче реально для программеров просто большой мак а админы и системные инженеры - странные люди в датацентре
ivanstor
10.08.2023 09:31когда информация передается не самим 0/1, а крутизной фронта сигнала (а фронтов два)
Фронт один, второй "фронт" — это спад. "Крутизна фронта" тут совсем неуместна. Крутизна — это характеристика фронта/спада, скорость нарастания (спада) сигнала.
Да, вы обещали "на желудях и шишках", но упрощенное изложение — не значит неправильное и именно потому, что предназначено не для "суперпрофи".
В целом статья понравилась, поставил плюсики. Ждем ещё, может быть слегка поглубже.
hello_my_name_is_dany
10.08.2023 09:31Ещё хотелось бы разбор ARM-процессоров, SoC и прочего. Насколько они дают реальный перформанс на серверных задачах? (Если, конечно, вообще дают)
AntonVirtual Автор
10.08.2023 09:31Тесты, только тесты. Теория там не очень сильна.
Например, на одном из тестов мы обнаружили, что один из топ армов на задачах одной из СУБД сравним с крепким топ-середнячком Xeon Scalable v2. Практически 1-в-1 по транзакциям плюс-минус погрешность измерения.
cat_chi
Есть ощущение, что статья оборвалась где-то посередине.
А тема-то богатая. На цикл статей потянет, при желании. Но тогда нужно как-то структурировать информацию – хотя бы начиная с того, под какие цели нам нужен сервер и какие требования из этого следуют.
Например, в некоторых случаях люди просто используют сервера с десктопными процессорами и прекрасно себя чувствуют, сильно выигрывая в соотношении цена/качество :) А в других случаях такой подход будет полнейшей дичью.
Короче. Тема интересная, но раскрыта слабо. Хочется больше!
AntonVirtual Автор
Да, будет и продолжение.
cat_chi
Ну вот пока то, что есть, на начало как-то и не тянет. Выглядит скорее как случайный крик души "эй, а вы там не забыли про NUMA?!"
AntonVirtual Автор
Велкам в соавторы и сделаем статью как надо!
cat_chi
Э, нет, я не подписывался на написание цикла статей "расскажу вам как разбираться в серверах не на кухонном уровне" :)
Сомневаюсь, что у меня хватит компетенций (критиковать-то проще, сами понимаете), к тому же я адски ленив.
Но за предложение спасибо
MaximRV
И кстати теперь подход АМД и Интел стали противоположными. Например чтобы набрать 96 ядер, у АМД будет один сокет и 12 каналов, а у интел больше сокетов и соответственно NUMA
atshaman
А какая богатая тема - приложение вот этого вот всего железячного к возможностям конкретных гипервизора\ОС\приложения... в свое время был сильно фраппирован результатом попыток запустить LAMP стэк "bare metal", предполагаю что изменилось с того времени немногое )))
cat_chi
Хм, а в чём сложность?
atshaman
Так оно про те самые NUMA ничего не знает примерно на всех уровнях. Нарезать гипервизором и приколотить кусками со всеми накладными расходами IRL эффективней вышло.
cat_chi
А, ну то есть запустить-то проблем не было, но выжать максимум производительности не получалось?
Тогда понятно
atshaman
Угу. !Внезапно! выяснилось, что это все же не "большой макбук" и куча реального софта в общем очень не очень приспособлена для работы на "голом железе" - вот нарежете на "макбуки" - тогда и приходите )))
cat_chi
Справедливости ради – может быть и "большой макбук", т.к. большинство проблем, описанных автором, касаются именно многопроцессорных систем. Однако сервер с одним процессором – не такая уж редкая конфигурация. А для некоторых случаев не будет даже критичной разницы, десктопный это процессор или серверный.
И задача может стоять, например, как выбор между: "взять один дорогой и жирный двухпроцессорный сервак" и "взять несколько дешёвых и заложиться на горизонтальное масштабирование".
Короче, как я сказал в первом комменте, всё зависит от цели и требований...
atshaman
Так пойнт статьи, как я его понял как раз в том и есть - для выбора железа в соответствии с вашими целями-и-требованиями НЕОБХОДИМО иметь представление о железе в объеме несколько большим, чем может показаться привыкшим к облакам коллегам ).
AntonVirtual Автор
Именно так.
Dr_Faksov
Сильно плюсую. Одним 3D-моделирование гонять, другим файловый архив хранить\собирать да почтой заниматься, третьим - несколько сотен логфайлов писать одновременно, с гарантией да транзакционную базу на мильён записей в реалтайм обновлять . Сильно разные требования. И как понять где граница возможностей железа, а где- здравого смысла проектировщика сервера.
MaximRV
Как же вы правы. Вот мы используем для 1С сервера на базе 12900K и 7950X и второй показывает себя с наилучшей стороны. Нагрузить Сервер 1С и баз данных на нём 40-ка пользователями УНФ нереально. Он справляется с кучей фоновых заданий и выполнением запросов для проведения документов и отчетов.