Уже несколько лет компания AMD предлагает совершенно атомные, а точнее ядерные, а ещё точнее суперМНОГОЯДЕРНЫЕ процессоры Epyc. В этой статье мы рассмотрим основные «бутылочные горлышки», настройки биос и другие вещи, которые мешают раскрыть потенциал этих процессоров.

Взгляд со стороны на развитие процессоров и к каким процессорам применимы рекомендации

Нужно отметить, что развитие вычислительной техники редко происходит так, что каждый год появляется реально новая архитектура. Как правило, производители понемногу улучшают техпроцесс, добавляют ядра, увеличивают кэши, исправляют ошибки. Производители железа каждое небольшое изменение пытаются продать как значительное, чтобы увеличить продажи.

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

Вы будете удивлены, но для первых трёх поколений Epyc (7001–7003) подходит одна и та же материнская плата (в теории). Так как Эпики — это SoC, система на чипе, которая включает в себя практически весь чипсет, контроллеры памяти и многое другое. Материнские платы для Epyc — это просто текстолит с дорожками для соединений с памятью, микросхемы flash BIOS, iKVM. На практике производители материнских плат специально не обновляют AGESA и вносят другие несовместимости для увеличения продаж. К примеру, материнская плата Supermicro H11-SSL специально заявлена как не поддерживающая 7003 Эпики, чтобы улучшить продажи платы H12-SSL. Аналогично поступили и многие другие производители материнских плат. Хотя сама AMD сделала Epyc 7001–7003 полностью совместимыми.

Убеждён, что 85% архитектуры в современных Эпиках было разработано ещё под началом легендарного инженера Джима Келлера, хотя он покинул AMD уже больше 10 лет назад.

Когда я писал эту статью, я думал о процессорах Epyc 7000–9000 серий, но многие принципы применимы почти к любым процессорам.

Общие принципы оптимизации настроек Epyc

Выбор правильной модели Epyc

Если стоит задача запуска как можно большего количества виртуальных машин, то нужно выбирать как можно более многоядерный и многоканальный процессор. Это, казалось бы, очевидно. Но сомнения у покупателей возникают из-за того, что чем больше ядер, тем ниже базовая частота, на которой одновременно могут работать все ядра. Например, у многих 64-ядерных моделей 7003-й серии базовая частота 2000–2300 Mhz. Кажется это чем-то очень маленьким. И поэтому покупатель может взять, например, 16-ядерную модель с 3.9 Ghz базовой частоты.

Однако потом при запуске большого числа виртуалок, большего чем число ядер, всё начнёт тормозить, так как частое переключение контекста хуже, чем работа без переключений на более низкой частоте, но когда ядер хватает.

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

При задействовании всего нескольких ядер даже сильно многоядерные модели могут выдавать высокие частоты.

А теперь о самих частотах. Как правило, наиболее узкое место сервера — это не частота, а память и система ввода-вывода. Сами Эпики даже на 2200 Mhz работают очень достойно. По сравнению с десктопными процессорами у них огромные кэши всех уровней, которые дают прирост примерно как +300-500 Mhz. А также до 12 каналов памяти, которые тоже дают прирост по сравнению с 2 каналами в десктопных процессорах.

Интересный факт: у меня в качестве десктопа стоит Epyc 7C13 — 64-ядерный монстр (2.2–3.675 Mhz), который я иногда использую для параллельных вычислений. Так вот, во всех играх, что я на нём играл, не было никакого торможения (Cyberpunk 2077, например), несмотря на базовую частоту всего 2.2 Mhz. Все тесты игровой производительности процессора AMD Ryzen 5950X (топовый CPU пятого поколения Ryzen, с базовой частотой 3.4 ГГц и пиковой — 4.9 ГГц) можно перенести на Epyc с некоторым поправочным коэффициентом (0,66–0,85), так как ядра Zen 3 в 5950X и в серии Epyc 7C13 идентичны по архитектуре, но серверные процессоры Epyc имеют больше ядер, кэша и каналов памяти. Это позволяет частично компенсировать проигрыш по частотам. Посмотреть, как идут игры на 64-ядерном процессоре (с 8:35).

Самая основная оптимизация — RAM

Эпики из-за чиплетного подхода могут похвастаться огромным числом ядер. Но всё это сумасшедшее количество ядер нужно прокормить данными. А данные поступают из RAM. Чтобы как-то расшить это «бутылочное горлышко», AMD ставит большое количество кэша на Эпики. Вплоть до 768МБ на некоторых процессорах 7003-й серии (технология «3D V-Cache») и больше в последующих поколениях.

Но нельзя всё закэшировать. Поэтому на стадии покупки:

1. Смотрим пропускную способность памяти конкретного CPU. Даже в одном поколении у разных моделей она может отличаться в разы. Например, в 7000-й серии есть процессоры с 3 каналами памяти, а есть с 8 каналами.

2. Берём столько DIMM, сколько каналов у памяти (или больше).

3. Берём оперативную память 2-ранковую или выше.

4. Берём максимально скоростную память, которую потянет процессор.

5. Втыкаем DIMM по схеме из мануала материнской платы.

Будет большой ошибкой запускать сервер с Epyc всего на 1–4 модулях памяти. Разница в производительности может достигать десятков процентов по сравнению с использованием всех каналов.

Важный момент — это пункт 5. Втыкать память по схеме из мануала. Иначе может получиться, что все модули памяти посажены на один канал памяти и производительность сильно просядет.

Поговорим о ранках памяти

Контроллеры памяти в Epyc — умные устройства, и они могут использовать преимущества многоранковой памяти. Ранки — это фактически димм в димме. Виртуальные модули памяти внутри реальных. Хотя как виртуальные — они существуют в своих микросхемах, просто имеют общий интерфейс доступа через контакты димм.

Пока один виртуальный модуль памяти ищет запрошенную информацию и считает чётность, контроллеры памяти Epyc могут запросить другую информацию у другого виртуального модуля RAM.

Из-за этого общая производительность может вырасти в среднем до +5,6 процента.

Тесты проводились на Ryzen, но поскольку ядро у них одинаковое с Epyc, то результаты переносимы.

Так что стараемся покупать для Epyc 2-ранковую память. Тесты показывают, что ранки выше уже не дадут существенного выигрыша.

Отключаем AES-шифрование памяти TSME (Transparent Secure Memory Encryption) и Data Scramble

Эта опция заставляет процессор незаметно для операционной системы и виртуальных машин шифровать всю память.

• Шифруется вся DRAM одним общим ключом.

• Этот ключ находится в защищённом процессоре AMD (AMD-SP).

В теории самый шокирующий пример, когда эта опция может помочь — это Cold Boot Attack («Атака холодной перезагрузки»), основанная на том, что информация не моментально сбрасывается с DIMM при отключении питания. Это когда сервер перегружают через отрубание питания, а потом считывают информацию с DIMM специальным лёгким образом операционной системы и записывают в файл. Или даже модуль памяти замораживают специальным спреем, чтобы память не успела сброситься. Вынимают его из сервера, переносят под охлаждением (в дьюаре) на другой компьютер, а там считывают важную информацию из памяти.

Но в реальности организовать такую атаку можно лишь только в цирке.

Data Scramble — это когда процессор записывает данные не в чистом виде, а в перемешанном по специальному алгоритму. Тоже защита против очень редких уязвимостей, на практике почти не встречающихся. Например, Rowhammer, когда злоумышленник вызывает битовые переключения в соседних ячейках памяти.

Или для защиты от атак, использующих физические особенности DRAM (например, TRRespass, SMASH, Half-Double) которые могут манипулировать памятью, зная её физическую организацию.

Учитывая, что в серверах, как правило, стоит ECC память с коррекцией ошибок, то они не восприимчивы к атакам такого типа.

Отключив эту опцию, мы получим до +5% производительности.

Когда TSME не оказывает влияния на производительность системы

Если вы работаете в основном с базами данных, которые хранятся на накопителях информации (не RAM). Тогда вам можно не отключать TSME из-за того, что время доступа к дискам в сотни и тысячи раз больше, чем к RAM. Вы не заметите практической разницы.

Отключаем SEV (Secure Encrypted Virtualization)

SEV (Secure Encrypted Virtualization) — технология AMD, которая:

• Шифрует память каждой виртуальной машины уникальным ключом, генерируемым процессором.

• Эти ключи управляются встроенным в процессор безопасным процессором (AMD-SP).

• Изолирует ВМ даже от привилегированного гипервизора.

Гипервизор (например, KVM, ESXi, Hyper-V) не имеет доступа к расшифрованной памяти ВМ, даже если он скомпрометирован.

Другие ВМ также не могут просматривать или вмешиваться в память вашей ВМ.

Поддерживает несколько уровней:

1. SEV (базовая версия, только шифрование памяти).

2. SEV-ES (SEV Encrypted State, добавляет шифрование регистров CPU).

3. SEV-SNP (SEV Secure Nested Paging, защита от атак целостности памяти).

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

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

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

Отключив эту опцию мы получим до +27% производительности внутри виртуальной машины (источник).

Скорость и опции энергопотребления процессора C-States

Процессор умеет переходить в состояния с пониженной частотой или даже полностью отключать некоторые ядра, если нет нагрузки. Однако, если нам нужна высокоотзывчивая система, то нет смысла использовать C-States, так как для того, чтобы включить ядро, потребуется некоторое время.

Поэтому отключаем Global C-State. А также выставляем Power Supply Idle Control в «Typical Current Idle».

Cpu common option выставляем в «Performance», так как для серверов обычно важнее производительность, чем энергопотребление.

Производительность дисковой системы ввода-вывода

Какой бы ни была производительность самого процессора, результаты вычислений, как правило, нужно записывать на диск.

И тут важно не повестись на утверждения маркетологов об огромных цифрах последовательного чтения и записи NVME-накопителей с интерфейсами PCI-E 4.0 и PCI-E 5.0. На практике важны только IOPS случайной записи и чтения.

Поэтому более экономически выгодно поставить несколько накопителей NVME (в рейд или на разные виртуалки), пусть даже версии PCI-E 3.0, которые в сумме дадут больше IOPS, чем накопитель с более высокой версией NVME.

И вообще нужно учитывать, что современные NVME очень часто делаются на чипах QLC, но с быстрым интерфейсом PCI-E. И при случайной нагрузке (типичная нагрузка от виртуалок) такие диски проиграют MLС и TLC-накопителям с интерфейсом PCI-E 3.0.

Обращайте внимание на спецификации NVME. Вас должна настораживать в спецификациях «speed — up to X Gb/sec». «Up to» — это пиковая производительность. Реальная может быть в разы ниже.

Производительность последовательного чтения и записи на практике почти не имеет значения (кроме клонирования дисков).

Ищите именно долговременную (устоявшуюся) производительность в IOPS. Не берите диски для баз данных с менее чем 1 миллионом IOPS чтения, и менее 200 000 IOPS случайной записи.

Также имеет значение максимальная задержка при операциях записи (write latency), ориентируемся на 20 мкс и менее. Дело в том, что даже пользовательские NVME иногда анонсируют достаточное количество IOPS, но когда кончается SLC-кэш или включается TRIM, начинаются фризы и микрофризы, которые могут подорвать отзывчивость высоконагруженной системы.

Заключение

В этой статье мы рассмотрели настройки, которые больше всего влияют на производительность серверных процессоров Epyc. Но с практической стороны этого вполне достаточно, чтобы поднять производительность вашего сервера на десятки процентов. Есть ещё масса тонкостей, которые влияют на специфичные условия эксплуатации процессоров.

Вы можете арендовать мощные серверы на процессорах Epyc в компании RUVDS в дата-центре Rucloud. Они подойдут для хостинга высоконагруженных приложений и сайтов, работы с базами данных, обработки больших данных, виртуализации и контейнеризации.

Литература

1. High Performance Computing Tuning Guide for AMD EPYC™ 9005 Series Processors

2. High Performance Computing Tuning Guide for AMD EPYC™ 9004 Series Processors

3. HPC Tuning Guide for AMD EPYC 7003 Series Processors

4. Workload Tuning Guide for AMD EPYC 7003 Series Processors

5. High Performance Computing (HPC) Tuning Guide for AMD EPYC™ 7002 ROME Series Processors

6. Workload Tuning Guide for AMD EPYC™ 7002 Series Processor Based Servers

7. HPC Tuning Guide for AMD EPYC™ 7001 Processors

8. Memory Population Guidelines for AMD EPYC Procesors

© 2025 ООО «МТ ФИНАНС»