Нам надо было закупить 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. А те, кто не читает тестов, просто зайдут на сайт, увидят красивые цифры и купят.

Ну и остался вопрос: может, мы чего-то не понимаем? Может, у этих процессоров есть какая-то своя фишка, которую мы упустили? Может, кто-то уже понял, в чём проблема с их лагами?