Нам надо было закупить High-CPU, но так, чтобы это было одинаковое корпоративное железо для всех наших дата-центров по миру.
Почему надо было закупить? Потому что есть маркетинг. Те хостинги, которые используют десктопное железо, вешают потрясающие числа на сайты. У многих красуются предложения с частотами по четыре, а то и по пять гигагерц. Понятно, что совесть у всех разная, и часто за этими цифрами скрываются обычные десктопные процессоры, а не серверные. Но клиент, который не вникает в детали, видит большое число и делает выбор.
Так вот, нам надо было тоже завести такое большое число, потому что так порешал рынок.
Мы давно придерживаемся принципа использовать только настоящее серверное железо, то есть корпоративный класс. У нас в основной линейке стоят проверенные серверные Intel, которые в пике выдавали 3,7 ГГц. И мы-то знали, что наши 3,7 ГГц по реальной производительности легко обгоняют многие разогнанные решения конкурентов.
Но как это донести до человека, который просто сравнивает цифры на лендинге?
Поэтому мы стали искать серверный процессор с высокой тактовой частотой, чтобы соответствовать нашей внутренней политике и при этом не проигрывать в слепом сравнении.
Решили затестить AMD Epyc. Нашли модель с отличными ТТХ: много ядер, высокая частота. Купили партию железа.
Думали, что сейчас включим, и он просто разорвёт наш текущий Intel.
Это наш первый опыт с AMD. Нас немного смущал тренд на Реддите «Почему тормозят AMD Epyc», но казалось, что всё должно пойти хорошо.
Конечно же, хорошо не пошло, иначе я этого не писал бы.
Тесты
Развернули тестовый стенд и начали гонять бенчмарки. Методология стандартная, отработанная годами. Берём популярный пакет AIDA64, который умеет измерять производительность всех ключевых компонентов: процессора, памяти, диска. Сначала делаем базовый замер на пустом сервере, чтобы получить эталонные цифры (в таблицах это VM-0, то есть без виртуализации). Это наша точка отсчёта — 100% производительности.
Потом начинаем последовательно увеличивать нагрузку: запускаем 20 виртуальных машин, затем — 30 и 40. На 40 сервер становится полностью неюзабельным, поэтому откатываем до 35. На каждом этапе мы забирались в одну из виртуалок и прогоняли полный набор тестов по шесть раз. Шесть прогонов нужны, чтобы отсеять случайные всплески и провалы. Из этих шести значений мы взяли медиану.
Первые же сводные таблицы озадачили: никакого «всестороннего преимущества», на которое мы рассчитывали, не было. Да, в каких-то задачах Epyc был чуть лучше, в каких-то — чуть хуже. Например, тест на шифрование AES (19293 МБ/с) или хеширование SHA3 (1223,5 МБ/с) показывали отличные цифры, но в целом картина была очень неоднозначной. По сути, он оказался на одном уровне с нашим проверенным решением на Intel. Странно, но не критично.
А вот интересное началось, когда мы стали проверять систему под реальной нагрузкой, имитируя плотное заселение сервера клиентами. Пока на сервере работают 10, 20, даже 25 виртуалок — всё отлично. Интерфейс внутри машин отзывчивый, сеть работает бодро. Но как только мы переваливали за определённый порог, начинался лагодром.
Причём независимо от нагрузки виртуальных машин. Единственный показатель — их количество.
Попробовали поставить на паузу 28 из 35 ВМ — лагодром сохранился!
Дальше — неоднозначная кривая:
30 виртуальных машин — полёт нормальный.
34 — ещё терпимо.
35 — всё, приехали. Система начинала не просто подтормаживать, а жёстко деградировать. Числа не передают, насколько это было критично: интерфейс ВМ лагал, проводник открывался через секунду, отклик на действия становился непредсказуемым. Производительность падала не плавно, а практически отвесно. Связано это с деградацией производительности ввода-вывода или с чем-то иным, нам ещё предстоит выяснить.
Начали ковыряться с SMT в BIOS, меняли настройки префетчеров, пытались реплицировать настройки из AMD Performance tuning гайда. Мы даже пошли на Ютуб смотреть видео от Level1Techs — ничего не помогало. Именно тут мы поставили ВМ на паузу и сильно удивились: лаги шли, даже если лишние виртуальные машины были просто созданы и стояли в холде.
То есть сам факт их существования уже приводил к деградации производительности всего хоста!
Так что позвольте представить вам первый процессор с аппаратной защитой от переподписки: на один поток приходится ровно одна виртуальная машина плюс пара потоков нужна для менеджмента.
Возможно, конечно, это прикол нашего гипервизора (Hyper-V) — с KVM не тестили. Но, как нам кажется, вероятно, проблема — в контроллере памяти и в том, как процессор управляет виртуализацией. Если упрощать, то у процессора есть специальная таблица, которая сопоставляет физические адреса в оперативной памяти с виртуальными адресами, видимыми операционной системой и виртуальными машинами. У Intel исторически с этим всё было отлично: их контроллеры памяти — лучшие. Они в принципе придумали VT-D как таковую. Наши админы предположили, что у Epyc размер этой таблицы маппинга как-то жёстко ограничен — возможно, количеством ядер или потоков. Как только количество запущенных виртуальных машин превышает этот лимит, таблица переполняется. Процессору приходится постоянно заниматься подкачкой данных: выгружать их и загружать новые, делать медленные «лукапы» во внешней памяти. Из-за этого и начинаются дикие задержки. Это также объясняет, почему производительность становилась нестабильной: какая-то виртуалка могла случайно «задержаться» в быстрой таблице и работать идеально, как будто она одна на сервере, а в следующем прогоне теста её «выселяли», и она умирала.
Теперь посмотрите на тесты диска в сводной таблице. На пустом сервере скорость чтения с SSD изнутри ВМ была 28,56 МБ/с. При 30 ВМ она упала до 10,93. А при 40 ВМ — до 5,8 МБ/с! Падение — почти в пять раз! Memory Latency тоже поползла вверх: со 114 нс до 129 нс. А вот чисто процессорные тесты вроде CPU Queen просели не так драматично: с 33301 до 31233. Это значит, что сам по себе процессор молотит нормально, но вся система в целом, вся обвязка, отвечающая за взаимодействие с памятью и устройствами, просто захлёбывается.
В итоге мы столкнулись с дилеммой: напихать много маленьких клиентов в мощные сервера не выйдет — остаётся делать услугу с гарантией ядра. Сейчас мы предоставляем на этих Epyc-серверах выделенные гарантированные ядра. Это означает очень низкую плотность клиентов на одном физическом сервере. А раз клиентов мало, то и остальные ресурсы — дисковая подсистема, пропускная способность сети — делятся между меньшим количеством соседей. В итоге каждый клиент получает очень производительное и стабильное окружение.
А потом случилось страшное. Когда мы ввели услугу в продажу, её очень быстро раскупили. Вероятно, сработал тот самый «маркетинговый буллшит»: люди увидели высокую частоту и проголосовали кошельком.
Поэтому и родилась идея этого поста: с одной стороны, мы хотим показать технически грамотным читателям, что наше базовое решение на Intel ничуть не уступает модному AMD. А те, кто не читает тестов, просто зайдут на сайт, увидят красивые цифры и купят.
Ну и остался вопрос: может, мы чего-то не понимаем? Может, у этих процессоров есть какая-то своя фишка, которую мы упустили? Может, кто-то уже понял, в чём проблема с их лагами?
Комментарии (59)
LinkToOS
30.10.2025 07:14Решили затестить AMD Epyc. Нашли модель с отличными ТТХ: много ядер, высокая частота. Купили партию железа.
Что именно купили?
ntsaplin Автор
30.10.2025 07:14Тут справочник с характеристиками. Первая партия 9174f, а потом мы выбрали 9274f.
riv9231
30.10.2025 07:14А с чем сравнивали со стороны intel?
Конкуренты, скорее всего, ставят ryzen 9950X (или его аналрг маркировпнный как epyc 4xx5) и могут показать 5.5+GHz частоты и рекордную однопоточную производительность. Вам представляется этот вариант не серьёзным?
perfect_drugg
30.10.2025 07:14Да вообще выпал в сторону десктопных выглядит смешно. 1с сервер на 5.4ггц ядрах внезапно окажется лучшим, а с учётом азделения дисков под меньшей нагрузкой, то намного лучше типового варианта на зионе.
ntsaplin Автор
30.10.2025 07:14Сравнивали с Gold 6334, потому что в то время, в которое мы тестировали AMD, сервер на 6334 был (почти) пустой. Т.е. сравнение с Gold 6334 сделано не от обилия опций в конкретный момент времени.
BeLord
30.10.2025 07:14Последние лет n в подобных случаях берем амперметр и вольтметр, а лучше осциллограф и ваттметр и смотрим, что происходит с питанием и потреблением под нагрузкой, то что на блоке питания нарисовано 1 кВт еще ни о чем не говорит.
Дальше, предположим получаем информацию, что с питанием все ок, но потребление процессора наоборот низкое, тогда понятно откуда лаги при возрастающей нагрузке процессор пытается снизить потребление и получаем лаги.
Второй момент, как уже говорили, тестировать на альтернативных ОС, решения Microsoft + AMD традиционно имеют свою специфику, порой весьма не прозрачную.
vmcore
30.10.2025 07:14вот машина: 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.
riv9231
30.10.2025 07:14Ещё большее просветление настанет, если при всей условности синтетических тестов сравнивать суммарную и однопоточную производительность двухпроцессорных сборок с однопроцесcорными вариантами того же и/или разных производителей.
Запросто может оказаться что второй процесcор даёт +10% к многопотоку -30% к однопотоку, при +80% к цене, но при этом нагрузку надо распаралелить на +100500 ядер, а у распаралеливания есть свои издержки.
Вот и получается, что лучше всего, до последнего держаться за ryzen, в крайнем случае переходить на threadripper, затем на его pro-версию, в ещё более крайнем случае если не возможно делить нагрузку на разные контейнеры, то переходить на epyc.... и для самых монструозных монолитов использовать самые многоядерные эпики с 3d-кэшем. И только если всего этого не достаточно, брать двухпроцессорный сервер.
Тем не менее по синтетическим тестам, amd побеждает с большим отрывом и в двухпроцессорных сборках, судя по https://www.cpubenchmark.net/multi_cpu.html
vmcore
30.10.2025 07:14у меня задача - много тестирования в параллель, чтобы случалось побольше race conditions и прочей белиберды. чтобы при этом не слишком медленно - tmpfs вместо дисков. поэтому нужно много памяти. сколько там на ryzen можно поставить? 128GB ?
msolovyev
30.10.2025 07:14Парни, вы что-то сделали не так. Вы же понимаете, если у вас не работает, а у всего мира такой проблемы нет, то... :). Можно какие-то вводные? 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
ntsaplin Автор
30.10.2025 07:14Конечно, читали.
Про GEN2 была первая мысль. Но это не имеет значения. Неважно — включен NUMA Spanning или выключен, неважно gen1 или gen2.
Не получается на хосте запустить больше vCPU, чем logical CPU.
При этом мы знаем, что задать больше 64 vCPU нельзя, но нам это не нужно, мы в конфигураторе предлагаем максимум 16.
duronus
30.10.2025 07:14Имею 3 ноды с epyc 443 никаких проблем нет, за исключением того, что там крутится 1с дико кривая и после 200 баз сам 1с сервер начаниет дико лагать, но эсли этот лимит не превышать однопоток выше на голову любого интел
sonicfx
30.10.2025 07:14Недавно в беседе с GamerNexus Level1Tech сказал что эпики работают нормально только со всеми занятыми слотами оперативной памяти. Выше выложили гайд по настройке эпиков от амд и там также рекомендуется использовать все слоты памяти памятью с эквивалентыным размером друг другу, чтобы избежать деградации при интенсивной работе с памятью. Вы все слоты задействовали? Какая версия ОС
riv9231
30.10.2025 07:14Если у них при тестирования хоть интел, хоть амд, не все слоты заняты были, то это аховая безответственность и гарантированно не правильные выводы. Но не только. Если и эксплуатируются сервера с не вмеми занятыми слотами в расчете на расширение в будущем, то и сервера медленнее работают, причем иногда в разы!
Правильно забивать все слоты сразу, а расширяться либо новыми серверами либо меняя модули на более ёмкие. Два модуля на канал - тоже ошибка, будут работать на пониженных частотах.
Я постеснялся спрашивать про занятость слотов, там же всё таки специалисты.
sonicfx
30.10.2025 07:14Level1Tech утверждает что на интел пустые слоты это не такая большая проблема из-за их контроллера памяти. В рекомендациях от амд написано что нужно хотя бы у каждого двухканала занять хотя бы 1 канал. Думаю из-за таких нюансов нам одна контора не выдала серваки с эпиками посчитав их браком. По поводу специалистов - ну всякое бывает
WASD1
30.10.2025 07:14Если у всего мира работает у вас не работает - значит вы что-то делаете не так.
Из предположений "пальцем в небо" (что у вас не как у всех) - у вас кажется Винда? виртуальные машины на Винде могут переезжать с одного CPU на другой (именно CPU которых 2-4 на материнке, а не процессорное ядро)?
Потому, что в Interconnect между ядрами у AMD EPYC работает через PCI (часть линий PCI каждого из процессоров просто резервируется под интерконнект и "закорачивается" друг на друга) и в десятки раз медленнее чем поточное образение к своей RAM.
Rubiorif
30.10.2025 07:14AMD придумали гениальную защиту от плотной виртуализации, пусть трафик между кристаллами идёт пешком
inetstar
30.10.2025 07:14Не помню, говорил я это или нет. Но если в Hyper-V есть поддержка Huge Pages, то это может здорово помочь. Но Huge Page исключает переподписку по памяти.
Таблицы TLB должны быть нормальными у Эпик.
riv9231
30.10.2025 07:14За скобками критики тестирования остался самый главный аргумент, что при остановки вируальных машин без выгрузки их из ОЗУ, производительность не восстанавливается. Нечего сказать, это вполне может оказаться правдой. Я сталкивался с не интуитивной зависимостью производительности от особеностей размещения данных в памяти. Во всей красе это раскрывается при майнинге 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
edo1h
30.10.2025 07:14Иначе можно было бы взять ryzen 9950X3D, у которого всего 16 ядер и 2 канала, но зато он значительно быстрее в однопотоке (почти в 1,5 раза) и намного дешевле (в 3 раза дешевле) и 256GB udimm ecc ddr5 (у udimm чуть меньше задержки, но ryzen rdimm не поддерживает)
топовые райзены, конечно, выглядят привлекательно, но, увы, далеко не всегда они применимы.
если требуется высокая псп, то райзену с 2 каналами похвастаться нечем. если нужно много ядер на одном хосте — тоже. если много памяти на хосте — тоже.
ещё можно вспомнить про то, что мало линий pci-e, проблематично найти нормальные материнские платы с ipmi, и т.д.
GigaSan
а все таки было бы интересно узнать сколько в вашем процессоре фактически ядер
ntsaplin Автор
24 физ ядра
riv9231
А какие ядра? 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 теперь не торт?
faraway_lee
Вроде процессоры с суффиксом X как раз самые сильные в однопотоке, а варианты с увеличенным кэшем это X3D.
Скрин с www.cpubenchmark.net, в таблице отсортированные по однопотоку процы на сокете am5 (поле Thread Mark — это бенчмарк однопоточной производительности).