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

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