Байкал-М под нагрузкой: гоняем СУБД и веб на отечественном сервере - без прикрас

К нам попал тестовый сервер на процессоре Байкал-М. Не для обзора в духе «смотрите, какое отечественное железо», а по конкретному запросу: один из клиентов на managed-сопровождении изучает, что именно ставить взамен x86-серверов для значимых объектов КИИ. YADRO Vegman и системы на Байкале сейчас активно проходят сертификацию именно в этом направлении, и вопрос «а как оно работает под реальной нагрузкой» становится практическим.

Гоняли примерно неделю. Рассказываем как есть.

Железо и стенд

Сервер - платформа на Байкал-М (BE-M1000), восемь ядер ARM Cortex-A57, частота 1,5 ГГц, 32 ГБ DDR4. Это не флагман и не серверная линейка Байкал-S - у нас именно М, который позиционируется для рабочих станций и лёгких серверных сценариев. Важно держать это в голове при чтении цифр.

ОС - РЕД ОС 7.3 для ARM, которую мы разворачивали на оборудовании YADRO раньше. Ядро определило всё железо без лишних телодвижений - это уже прогресс относительно того, что было год назад.

Сравнивали с тем, что есть под рукой в качестве ориентира: дешёвый двухсокетный Xeon E5 2019 года рождения с аналогичным объёмом памяти. Не топовое x86, но типичное «что стоит у клиентов».

PostgreSQL: синтетика и типовой OLTP

Начали с pgbench - стандартный TPC-B-подобный тест, масштаб базы 100, 8 и 16 клиентов поочерёдно.

На 8 клиентах Байкал-М держал порядка 1100-1200 TPS. Xeon на том же тесте - около 4500-5000 TPS. Разница примерно в четыре раза - и это без тюнинга под конкретное железо, на дефолтных postgresql.conf с поправкой только на shared_buffers и work_mem.

На 16 клиентах картина сходная по соотношению: Байкал-М немного проседает относительно линейного масштабирования, что типично для ARM-платформ с таким количеством ядер при высококонкурентной нагрузке.

Что важно: при типовой нагрузке КИИ-объекта (документооборот, реестры, небольшие транзакционные базы) эти цифры вполне рабочие. Если у вас не биржевой процессинг и не высоконагруженный интернет-магазин - Байкал-М тянет. Если у вас 500 одновременных пользователей в 1С - разговор другой.

Nginx + PHP-FPM: веб-нагрузка

Подняли типовую конфигурацию: Nginx 1.24, PHP-FPM 8.1, простое PHP-приложение с обращением к PostgreSQL. Нагружали через wrk с нарастающим числом соединений.

При 50 одновременных соединениях и простых запросах (список из 20 записей из БД) Байкал-М выдавал около 800-900 RPS с медианой ответа около 55 мс. На той же нагрузке Xeon давал 3000+ RPS и медиану около 15 мс.

При увеличении до 200 соединений Байкал-М начал явно упираться в CPU - латентность росла нелинейно. Xeon держал нагрузку значительно ровнее.

Компиляция PHP-кода - отдельная тема. JIT в PHP 8.1 на ARM работает, но прирост от него скромнее, чем на x86. Это известная особенность архитектуры, ничего нового.

ARM-специфика, которая вылезла

Несколько моментов, которые стоит знать заранее.

Бинарные пакеты. Не всё есть в репозиториях для ARM в том виде, к которому привыкли на x86. Пара утилит для мониторинга потребовала сборки из исходников - не катастрофа, но время и внимание. В продуктивной инфраструктуре это нужно учитывать при планировании.

Тепловой пакет. Байкал-М заметно холоднее x86 при той же нагрузке. Для плотных стоечных конфигураций это может быть аргументом - меньше затраты на охлаждение. Для одного тестового сервера - просто наблюдение.

Производительность на ядро. ARM Cortex-A57 - это не Graviton и не Apple Silicon. Это архитектура, которая создавалась без прицела на серверный throughput. Байкал-М честен в своих характеристиках, и ожидать от него x86-уровня на операцию было бы наивно.

Что из этого следует практически

Если заказчик стоит перед задачей импортозамещения иностранного оборудования для КИИ (подробнее о нашем взгляде на дедлайны) и ему нужно пройти сертификацию - Байкал-М и серверы YADRO на его основе являются реальным вариантом. Не потому что «отечественное», а потому что работает, документировано и сертификационный путь у него есть.

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

Требует разговора о нагрузочном профиле, если речь идёт о высококонкурентных OLTP-базах, процессинге или системах с сотнями одновременных активных пользователей.

Не подходит как прямая замена «один к одному» для мощных x86-серверов без пересчёта конфигурации под реальные требования производительности.

Тест продолжается - дальше смотрим на поведение при длительной нагрузке и специфику работы с Astra Linux вместо РЕД ОС на том же железе. Если будет что рассказать сверх стандартного - расскажем.