Comments 68
а все таки было бы интересно узнать сколько в вашем процессоре фактически ядер
24 физ ядра
А какие ядра? Zen1, zen2, zen3 или zen4? Какой конкретно процессор вы тестировали? с каким конкретно процессором от intel сравнивали.
Без этой информации, статья выглядит как ничем не обоснованные нападки на лидера отрасли.
Мне очень интересно узнать эту информацию, я решал такую же задачу и у меня фаворит amd, но думаю, не дана она была не просто так.
Если нужны гигагерцы, следовало использовать amd epyc серит 4005 - полный аналог amd ryzen 7 или ryzen 9 просто с другой маркировкой, но это двухканальный по сути десктопный процессор на десктопном сокета am5.
Если надо много vm с высокой однопоточной производительностью, выход один - взять много таких серверов. Если VM должны быть большими (100+ГБ озу), то придётся немного пожертвовать однопоточной производительностью и взять threatripper pro или пожертвовать сильнее и переходить на одно и двухпроцесоорные amd epyc.
Но и внути линейки epyc процессоры отличаются не только по поколению ядер, но и по объему кэша (больше кэш -> ниже частоты при прочих равных), по количеству ядер (больше ядер -> ниже частоты при прочих равных), есть процессоры с индекмом F - дорогие и быстрые, но с маленьким кэшом и наоборот многоядерные монстры с низким однопотоком, но рвущие в клочья своих быстрых аналогов на определенных видах нагрузки, а ещё есть дорогущие процессоры с индексом X с огромными кэшами и относительно не высокой однопоточной производительностью.
У intel тоже самое: например есть двухканальный и очень шустрые intel xeon e3 с частотами не сильно хуже amd но по сути это десктопные i7, была линейка xeon e5-16xx - но там и однопоток пониже и ядер побольше, а коналов 4 (как у amd threadripper НЕ pro), далее идут xeon e5-26xx и так далее, для каждой ситуации свой процесор. я описал старые линейки, но если сейчас копнуть там логика 1:1 как у amd и сопоставимые скорости.
Так что и с чем именно вы сравнивали и сделали вывод, что процесморы amd теперь не торт?
Вроде процессоры с суффиксом X как раз самые сильные в однопотоке, а варианты с увеличенным кэшем это X3D.
Скрин с www.cpubenchmark.net, в таблице отсортированные по однопотоку процы на сокете am5 (поле Thread Mark — это бенчмарк однопоточной производительности).
Хотелось бы те же тесты, но с гипервизором на линуксе (kvm), а не на винде
Тесты под KVM не проводили, иначе бы также показали. Как идею — принял.
Очень ждём тестов с KVM. Заведите Proxmox VE, наклепайте вмок :)
Очень жаль, так как в таком сценарии статья из "у AMD есть проблемы в таком-то типе нагрузки" свелись к "мы там что-то сделали и к нас не взлетело". Просто потому, что Linux виртуалки и KVM распространены больше, чем Hyper-V и виртуалки под Windows.
Или вы крутите Linux VM под Hyper-V? Если да, то в чём причина такого подхода? Насколько помню, Hyper-V мега-хорош именно интеграцией с Windows и там его использование очень серьёзно оправдано.
VMware тоже надо проверить, не удивлюсь что это проблемы на гипервизоре очень похоже на это. Особенно когда vm выключены а все тормозит.
Решили затестить AMD Epyc. Нашли модель с отличными ТТХ: много ядер, высокая частота. Купили партию железа.
Что именно купили?
Тут справочник с характеристиками. Первая партия 9174f, а потом мы выбрали 9274f.
Там вроде только модель процессора указана. А сам сервер, его конфигурация, кто производитель?
А с чем сравнивали со стороны intel?
Конкуренты, скорее всего, ставят ryzen 9950X (или его аналрг маркировпнный как epyc 4xx5) и могут показать 5.5+GHz частоты и рекордную однопоточную производительность. Вам представляется этот вариант не серьёзным?
Да вообще выпал в сторону десктопных выглядит смешно. 1с сервер на 5.4ггц ядрах внезапно окажется лучшим, а с учётом азделения дисков под меньшей нагрузкой, то намного лучше типового варианта на зионе.
Сравнивали с Gold 6334, потому что в то время, в которое мы тестировали AMD, сервер на 6334 был (почти) пустой. Т.е. сравнение с Gold 6334 сделано не от обилия опций в конкретный момент времени.
Почему не 9474F, например
Коллеги, укажите модель процессора или хотя бы поколение.
Последние лет n в подобных случаях берем амперметр и вольтметр, а лучше осциллограф и ваттметр и смотрим, что происходит с питанием и потреблением под нагрузкой, то что на блоке питания нарисовано 1 кВт еще ни о чем не говорит.
Дальше, предположим получаем информацию, что с питанием все ок, но потребление процессора наоборот низкое, тогда понятно откуда лаги при возрастающей нагрузке процессор пытается снизить потребление и получаем лаги.
Второй момент, как уже говорили, тестировать на альтернативных ОС, решения Microsoft + AMD традиционно имеют свою специфику, порой весьма не прозрачную.
вот машина: 2 x EPYC 7352, 576GB RAM. крутятся автоматические тесты. 124 виртуалки. у каждой от 4 до 16 виртуальных ядер. загрузка:
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
r b swpd free buff cache si so bi bo in cs us sy id wa st gu
173 0 2037948 60788212 5516 126789148 130 591 133 591 136672 31 1 4 1 0 0 94
171 0 2037948 60703232 5516 126782268 0 0 0 0 126979 153214 1 4 0 0 0 95
208 0 2037948 60588804 5516 126782280 0 0 0 0 126774 144728 1 3 0 0 0 96
197 0 2037948 60538632 5516 126782304 0 0 0 0 126645 146009 1 4 0 0 0 95
171 0 2037948 60354904 5516 126782324 0 0 0 0 125787 144791 1 3 0 0 0 95
200 0 2037948 60285812 5516 126782340 0 0 0 0 128049 143373 1 3 0 0 0 95
182 0 2037948 60171952 5516 126782356 0 0 0 0 125273 150286 1 4 0 0 0 95
182 0 2034160 60643000 5516 126782364 0 48 0 48 131480 141337 1 4 0 0 0 95
178 0 1980408 60478268 5516 126782380 0 0 0 0 130935 143762 1 4 0 0 0 95
захожу по ssh, что-то делаю на машине - никаких лагов. конечно, не так быстро как на "пустой", но без дискомфорта. две такие машины, употребляют по 350-360W, очень доволен.
ps. ради интереса поглядел на ценники на тао. 9274F стоит ~160 тысяч и выдает 74K попугаев согласно passmark.7352 выдает 40K попугаев и обошелся в 6 (шесть) тысяч рублей. чувствую себя абсолютно счастливым ;)
pps. для предотвращения истерики не стал смотреть сколько стоят эпические материнские платы под sp5.
Ещё большее просветление настанет, если при всей условности синтетических тестов сравнивать суммарную и однопоточную производительность двухпроцессорных сборок с однопроцесcорными вариантами того же и/или разных производителей.
Запросто может оказаться что второй процесcор даёт +10% к многопотоку -30% к однопотоку, при +80% к цене, но при этом нагрузку надо распаралелить на +100500 ядер, а у распаралеливания есть свои издержки.
Вот и получается, что лучше всего, до последнего держаться за ryzen, в крайнем случае переходить на threadripper, затем на его pro-версию, в ещё более крайнем случае если не возможно делить нагрузку на разные контейнеры, то переходить на epyc.... и для самых монструозных монолитов использовать самые многоядерные эпики с 3d-кэшем. И только если всего этого не достаточно, брать двухпроцессорный сервер.
Тем не менее по синтетическим тестам, amd побеждает с большим отрывом и в двухпроцессорных сборках, судя по https://www.cpubenchmark.net/multi_cpu.html
Сервер под два сп5 примерно от 800.
Парни, вы что-то сделали не так. Вы же понимаете, если у вас не работает, а у всего мира такой проблемы нет, то... :). Можно какие-то вводные? Windows server у вас какой версии? VM вы создаете gen2? Вот тут читали? https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/tuning-guides/58471_amd-epyc-9005-tg-windows-server.pdf
Конечно, читали.
Про GEN2 была первая мысль. Но это не имеет значения. Неважно — включен NUMA Spanning или выключен, неважно gen1 или gen2.
Не получается на хосте запустить больше vCPU, чем logical CPU.
При этом мы знаем, что задать больше 64 vCPU нельзя, но нам это не нужно, мы в конфигураторе предлагаем максимум 16.
Имею 3 ноды с epyc 443 никаких проблем нет, за исключением того, что там крутится 1с дико кривая и после 200 баз сам 1с сервер начаниет дико лагать, но эсли этот лимит не превышать однопоток выше на голову любого интел
Недавно в беседе с GamerNexus Level1Tech сказал что эпики работают нормально только со всеми занятыми слотами оперативной памяти. Выше выложили гайд по настройке эпиков от амд и там также рекомендуется использовать все слоты памяти памятью с эквивалентыным размером друг другу, чтобы избежать деградации при интенсивной работе с памятью. Вы все слоты задействовали? Какая версия ОС
Если у них при тестирования хоть интел, хоть амд, не все слоты заняты были, то это аховая безответственность и гарантированно не правильные выводы. Но не только. Если и эксплуатируются сервера с не вмеми занятыми слотами в расчете на расширение в будущем, то и сервера медленнее работают, причем иногда в разы!
Правильно забивать все слоты сразу, а расширяться либо новыми серверами либо меняя модули на более ёмкие. Два модуля на канал - тоже ошибка, будут работать на пониженных частотах.
Я постеснялся спрашивать про занятость слотов, там же всё таки специалисты.
Level1Tech утверждает что на интел пустые слоты это не такая большая проблема из-за их контроллера памяти. В рекомендациях от амд написано что нужно хотя бы у каждого двухканала занять хотя бы 1 канал. Думаю из-за таких нюансов нам одна контора не выдала серваки с эпиками посчитав их браком. По поводу специалистов - ну всякое бывает
Я совсем не в теме, а как и почему заполненность слотов памяти влияют на производительность?
Если у всего мира работает у вас не работает - значит вы что-то делаете не так.
Из предположений "пальцем в небо" (что у вас не как у всех) - у вас кажется Винда? виртуальные машины на Винде могут переезжать с одного CPU на другой (именно CPU которых 2-4 на материнке, а не процессорное ядро)?
Потому, что в Interconnect между ядрами у AMD EPYC работает через PCI (часть линий PCI каждого из процессоров просто резервируется под интерконнект и "закорачивается" друг на друга) и в десятки раз медленнее чем поточное образение к своей RAM.
Не помню, говорил я это или нет. Но если в Hyper-V есть поддержка Huge Pages, то это может здорово помочь. Но Huge Page исключает переподписку по памяти.
Таблицы TLB должны быть нормальными у Эпик.
За скобками критики тестирования остался самый главный аргумент, что при остановки вируальных машин без выгрузки их из ОЗУ, производительность не восстанавливается. Нечего сказать, это вполне может оказаться правдой. Я сталкивался с не интуитивной зависимостью производительности от особеностей размещения данных в памяти. Во всей красе это раскрывается при майнинге monero: там для максимальной производительности, должны быть не просто все слоты заняты, но и модули какого-то минимального размера и это как-то завязано на взаимодействие кэшей. Поправьте меня если я что-то перепутал за давностью лет, когда сам столкнулся.
Не удивлюсь, если окажется, что загруженные в озу, но не создающие нагрузку на процессор VM, как-то мешают оставшимся получить пиковую производительность. С таким поведением, если это правда, а не артефакт работы hyper-v, идея стопнуть машину и потом не брать деньги за процессор, но брать за все остальное, не сработает. Но я не вижу большой проблемы. Нужно просто выгружать остановленные VM и всё.
В свой практике эксплуатации не большого кластера под proxmox на процессорах AMD, я ни разу не сталкивался с нехваткой именно суммарной производительности CPU. Обычно, оперативки не хватает. Но это вопрос ещё и оптимизации конфигурации сервера в виде подбора отношения количества озу к количеству каналов и ядер.
С моей точки зрения, для 12-канального процессора на DDR5, 24 ядра маловато. Я эксперементально пришел к формуле: для 1С и других требовательных для однопотока приложений, примерно 4 ядра на канал или не более 32 ядер на 8 каналов, ну и 24 тоже не плохо. Например в это формулу укладывается EPYC 7443 и 512GB RAM, т.е. 8 модулей по 64GB. Для менее требовательных до однопоточной производительности, более подходят процессоры с 48-64 ядер, например 76k2 - намного дешевле и 48 ядер, хотя тут, наверное можно поспорить.
Для DDR5 у которого ширина канала вдвое больше, наверное лучше переходить с 64GB на 128GB модули, а следовательно 1536GB на процессор. Для 16GB на ядро - это даст 96 ядер, а не 24. Если используются 64GB-модули, то все равно, при 12 каналов, нужно минимум 48 ядер. Иначе можно было бы взять ryzen 9950X3D, у которого всего 16 ядер и 2 канала, но зато он значительно быстрее в однопотоке (почти в 1,5 раза) и намного дешевле (в 3 раза дешевле) и 256GB udimm ecc ddr5 (у udimm чуть меньше задержки, но ryzen rdimm не поддерживает)
Вместо 1000 слов иллюстрация
Можете сами поиграться: https://www.cpubenchmark.net/compare/5381vs5513vs6549vs6259vs5742/AMD-EPYC-9174F-vs-AMD-EPYC-9274F-vs-AMD-Ryzen-9-9950X3D-vs-Intel-Xeon-w7-3565X-vs-Intel-Xeon-Gold-6448H
Иначе можно было бы взять ryzen 9950X3D, у которого всего 16 ядер и 2 канала, но зато он значительно быстрее в однопотоке (почти в 1,5 раза) и намного дешевле (в 3 раза дешевле) и 256GB udimm ecc ddr5 (у udimm чуть меньше задержки, но ryzen rdimm не поддерживает)
топовые райзены, конечно, выглядят привлекательно, но, увы, далеко не всегда они применимы.
если требуется высокая псп, то райзену с 2 каналами похвастаться нечем. если нужно много ядер на одном хосте — тоже. если много памяти на хосте — тоже.
ещё можно вспомнить про то, что мало линий pci-e, проблематично найти нормальные материнские платы с ipmi, и т.д.
А на этот счет есть какая-то теория, статьи для какого процессора/ядер какое количество планок памяти и какого объема оптимально?
Парни, вы конечно дали жару😅
Серьезно поставили Windows на процессор для ЦОД для поднятия виртуальных машин? Тестирование AIDA? Гипервизор Hyper-V?
И вас не смутила скорость чтения с диска 28MB/s на пустой системе?))
Вы бы ещё игры на нем запускали и пожаловались что fps низковат
Попробуйте для начала поставить что-то типа Ubuntu 24+lts, выбрать режим производительности и все такое, далее для запуска попробуйте что-нибудь типа lxd/incus/proxmox/qemu
Вообще пора выборсить уже виндоус в окно. Простите за каламбур.
Если и этого окажется мало, в Биос целая гора настроек в разделах cbs/pbs/overclocking, в том числе касательно виртуализации (не забудьте включить там), управления памятью, устройствами и прочим)
Всё верно пишешь. Но если прод уже крутится на Hyper-V, то миграция ради теста не так тривиальна. В реальности многие живут именно с таким стэком, а не на Ubuntu с KVM
Мигрировать для теста необязательно, можно почитать тесты в другом месте. Вот например servethehome.com регулярно публикует такие тесты:
Пример для Rome 7002, для Genoa 9004 и так далее.
Также отличные тестирования проводит phoronix
Ой да ладно, там дел на пять минут, сделать клон и залить.
В реальности люди живут на VMware. Где всё работает именно так, как надо.
Ну либо поделки на Linux для бедных.
Серьезно поставили Windows на процессор для ЦОД для поднятия виртуальных машин? Тестирование AIDA? Гипервизор Hyper-V?
а что что не так с windows и hyper-v? один из крупнейших хостинг-провайдеров в мире — ms со своим azure. отлично себя чувствуют.
Система начинала не просто подтормаживать, а жёстко деградировать. Числа не передают, интерфейс ВМ лагал, проводник открывался через секунду, отклик на действия становился непредсказуемым
Кажется, описана обычная работа windows VM в RuVDs ) у меня таких 6 штук.
Домучиваю проект на windows и скоро их выключу, слава богу.
Мы написали вам в личку. Нет, это не обычная работа, надо разобраться, постараемся помочь!
Вот результат VM за 48 т.р. в год, RU326179
Стопнул на сервере всё, запустил AIDA
Memory read 31335
Memory write 25032
Memory copy 33348
Memory latency 98.5 ns
CPU checkmate 1073
CPU PhotoWorxx 21844
CPU ZLib 199
CPU AES 7585
CPU SHA3 1084
FPU Julia 25773
FPU Mandel 13875
FPU SinJulia 2492
FP32 Ray-Trace 5996
FP64 Ray-Trace 3497
Т.е. результаты в среднем сильно хуже вашего теста VM 39. Ну понятно, оборудование другое.
PassMark disk - 6272. Уровень Kingston 128 GB 2019-го года
https://www.harddrivebenchmark.net/hdd.php?hdd=KINGSTON RBUSNS8154P3128GJ3&id=24285
Но это синтетические тесты. По ощущениям всё еще грустнее.
ESXi прекрасно работает с толпами ВМ на эпиках.
Забиты все слоты оперативкой.
Имхо что то не так конфигацией ОЗУ (объем и т.д.)
Hyper-V и Epyc не лучшая пара. Для AMD стабильнее работает KVM или Proxmox. Майкрософтовский гипервизор просто не умеет грамотно работать с их NUMA-архитектурой
Без проверки на эталонном ESXi наезд на АМД не засчитан. Может быть у вас просто винда глючит. Всегда кучи ВМ крутились на них, доходило до сотни шт на сервер, и падение производительности было предсказуемым, а не такая ерунда.
С 2018 года сижу на эпиках (proxmox) впервые слышу о подобных проблемах. Я подозреваю, что hyper-v не корректно работает с этой архитектурой, выглядит как будто вм назначили больше ядер чем есть у хоста и они начинают драться за ресурсы. Возможно стоит ещё включить numa в настройках вм.
Осталось понять конфиг то какой, стоит ли рэйд. Судя по скорости дисковой, забита pci-e, какие машины с какими ссд работают, на каналах какого из процессора они стоят. В целом, налицо не аппаратная проблема, а нежелание понять, что проблема не в количестве машин, а в непонимании того, как все работает.
Из наших опытов работы с Epyc и большими потоками реалтайм данных (Windows или виртуалки kvm + наши железки на Pcie) вынесли следующее:
Для Windows или если используется gui в linux не в коем случае не включать встроенную в материнке графику aspeed. Отключить в device manager или лучше джампером на материнки. Это кривое поделие и его драйвер приводят к микрофризам на десятки микросекунд всей системы, в том числе шины pcie. Любой дискретный gpu лучше, даже gt210
Для виртуалок - обязательно отключать hpet в биосе
В биосе выключить глобальные cstates (которые для всего процессора, в т.ч. контроллера памяти). Package c-states или как-то так
И, да, все 6/8 каналов должны быть заполнены плашками памяти
После этого в наших юзкейсах лаги пропадали и система спокойно давала гнать потоки с шести плат pcie без затыков.
А вот Intelов с 6 pcie за разумные деньги не бывает. А ещё, начиная с haswell их pcie работает с очень нестабильной latency - иногда запросы к памяти подвисают на 30-60мкс. В последних поколениях вроде полегче стало.
Любой дискретный gpu лучше, даже gt210
эээ… а как к ipmi/kvm цепляться?
к микрофризам на десятки микросекунд всей системы
иногда запросы к памяти подвисают на 30-60мкс.
что за задачи у вас, на которых вы ловите десятки микросекунд?
А вот Intelов с 6 pcie за разумные деньги не бывает.
???
вроде примерный паритет по числу линий pci-e.
вот первая попавшая материнка, 6 pci-e на мамке, плюс возможность ещё 6 подключить:
https://www.supermicro.com/en/products/motherboard/x14sbi-tf
эээ… а как к ipmi/kvm цепляться?
Да, это проблема. Обычно не отключаем aspeed совсем - оставляем для bios, на винде отключаем aspeed, оставляем RDP, на линуксе - оставляем как есть, т.к. там обычно консоль.
что за задачи у вас, на которых вы ловите десятки микросекунд?
Да легко ловится и видно. Девайсы на ПЛИСах гонят поток из внешних интерфейсов в ПК со скоростью до 5-8GB/s (видео) и не имеют большой буферизации (ставить доп. память на 16GB/s к ПЛИС сложно, и, самое главное, горячо). Внутрений буфер - максимум несколько мегабайт и он исчерпывается за ~100-500мкс, поэтому такие провалы уже чувствительны. И самое противное - они не зависят от загрузки CPU, памяти, ширины шины и т.д. Немного помогает только отключение c-states.
X14
Да, да интел, наконец, сообразил что к чему, посмотрите, что было на одноголовых x12/x13, когда в ходу уже были h11/h12/h13 с 6-7 слотами
Теперь посмотрите на тесты диска в сводной таблице. На пустом сервере скорость чтения с SSD изнутри ВМ была 28,56 МБ/с. При 30 ВМ она упала до 10,93. А при 40 ВМ — до 5,8 МБ/с! Падение — почти в пять раз! Memory Latency тоже поползла вверх: со 114 нс до 129 нс
ткну пальцем в небо: у вас двухсокетные системы и вы попали на проблемы с numa
Я думаю, что у вас происходит примерно следующее:
Процессор у вас имеет общий, но изолированный от других ядер, кэш L3 на каждые 3 ядра. Все вместе это называется "комплекс ядер". Всего 8 комплексов ядер. Переброска потока с одного ядра на другое за пределами комплекса приводит к тому, что кэш переползает с одного ядра на другое, по сути, очищая кэш процессора на обоих ядрах (старом и новом) и забивая пропускную способность шины памяти обоих комплексов (т.к. ядра синхронизируют кэш по той же шине что и обращаются к памяти).
Если количество VM превышает количество потоков, гипервизор начинает активно вытеснять и перебрасывать виртуальные ядра с одного физического ядра на другое игнорируя границы комплексов ядер, что приводит к глобальной чистке кэша и забиванию шины памяти паразитным трафиком.
Для решения этой проблемы вам нужно перевести процессор в NUMA режим "L3 Cache as separate NUMA Domain". Должно получиться 8 NUMA-нод по 3 физических ядра процессора.
Во-вторых, надо настроить гипервизор жестко привязав каждое виртуальное ядро VM к конкретному NUMA-домену. То есть, разрешить каждому виртуальному процессору маской исполняться только на ядрах одной конкретной NUMA-ноды.
Как это настроить в Hyper-V, - без понятия. Но, в большинстве гипервизоров работающих на Linux это должно работать из коробки. Оно работает даже на десктопной Ubuntu. Правда, в основном, за счет более умного планировщика в ядре ОС, причем, даже без ручной привязки виртуальных ядер к доменам.
Скорее всего ваша проблема в программном обеспечении, и имеет корни либо в устаревшем планировщике в ядре ОС который не знает особенностей данного процессора (поколения процессоров), любо в аналогичной проблеме с Hyper-V.
На Интеле таких проблем раньше не было просто потому, что у них процессоры были с монолитным дизайном и кэш L3 у них общий на все ядра. Но, с новыми будут, скорее всего, аналогичные проблемы.
Чудесно. На десктопных Zen5 похожая проблема, кстати, там один кеш на 8 ядер. Этой весной в Win11 добавляли костыли, чтобы она почём зря не гоняла процессы через границу кеша.
Я в серверах не смыслю, но может автор попробовать пиннинг процессов к ядрам, чтобы убедиться, что дело в этом?
Ваша версия выглядит самой близкой к истине. И раньше встречалась проблема деградации скорости записи из-за NUMA.
В этом обсуждении объясняют, что попробовать на Windows Server 2025:
- Create a CPU Group for Each NUMA Node (https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-hyper-v-cpugroups)
- Assign Processors to Your CPU Group
- Assign a VM to a CPU Group
7950X, QEMU(kvm), enterprise матери (AsRock Rack, Fujitsu). Имеется десяток сборок, в среднем до 150 виртуальных машин. LA 5-10, выше 150 можно спокойно подниматься но правило отсутствия оверселла по RAM ограничивает это.
В общем если у Вас лагает от количества виртуальных машин, то меняйте гипервизор или ищите подход к этому. Проблема не в процессорах.
Статья имеет рекламный характер. О чем сам автор недальновидно написал:
"Поэтому и родилась идея этого поста: с одной стороны, мы хотим показать технически грамотным читателям, что наше базовое решение на Intel ничуть не уступает модному AMD. А те, кто не читает тестов, просто зайдут на сайт, увидят красивые цифры и купят."
Вообще потрясает, что вместо работы на клиента ("...случилось страшное, ... услугу быстро раскупили") автор хочет продолжать работать в интересах вендора (Интел).
Т.о. все наши советы ему не нужны - ему надо придумать как "продать "ксеоны".
Почему тормозят AMD Epyc