Мы уже рассказывали о нагрузочном тестировании машины баз данных (МБД) Tantor XData 2Y на базе процессоров Intel, а точнее, об успешно пройденном тесте на 30 тысяч пользователей 1С. Результаты этого теста раскрыли возможности МБД для высоконагруженных систем 1С:Предприятие и продемонстрировали впечатляющие показатели производительности. Однако реальность российского рынка enterprise-решений такова, что технические характеристики — не единственный критерий для выбора оборудования. Требования 398-ФЗ, стратегии импортозамещения, санкционные риски и бюджетные ограничения заставляют компании искать баланс между производительностью и другими факторами.
В линейке МБД Tantor XData есть модель 2B на базе процессоров Baikal-S, позиционируемая как ответ на подобные вызовы. В новой статье мы делимся результатами аналогичного нагрузочного тестирования уже модели 2B и рассказываем об особенностях работы ARM-архитектуры с PostgreSQL и практическом опыте оптимизации данной системы — со всеми техническими деталями, метриками производительности и найденными узкими местами.
Нагрузочный тест
Тест был разработан фирмой 1С с учетом требований крупнейших компаний России, представленных Национальным центром компетенций по информационным системам управления холдингом (АНО «НЦК ИСУ»). Детали теста были следующими:
Дата проведения | 6 октября 2025 г. |
Версия конфигурации | 1С:ERP Управление предприятием (версия 2.5.17.117) |
Версия платформы | Спец. сборка 8.3.27 |
Версия СУБД | Tantor Special Edition 1C 17.6 |
Сценарий | ERP. 30 000 одновременно активных пользователей |
Объем базы | ~ 1,25 Тб |
Структура базы | Организация, имеющая в своей структуре 54 филиала, выделенных на отдельные балансы (55 позиций в справочнике организаций), 1800 подразделений, 3500 складов, 80 тыс. номенклатурных позиций, 700 тыс. сотрудников, 90 тыс. партнеров, 2.5 млн контрагентов, 25 млн договоров, 1 млн основных средств |
До этого теста на Baikal-S мы нагрузочных тестов 1С не запускали, поэтому решили идти постепенно, начав с пяти тысяч пользователей. За запуск нагрузочного теста и фиксацию его результатов отвечали наши коллеги из компании «ИТ‑Экспертиза».
Описание стенда
Назначение | Кол-во серверов | Ядер CPU | ОЗУ (Гб) | Диски (Тб) | Примечание |
Центральный сервер | 1 | 96 | 768 | 2,4 | Платформа 1С:Предприятие 8.3.27 |
Рабочий сервер | 3 | 96 | 768 | 2,4 | Платформа 1С:Предприятие 8.3.27 |
Сервер лицензирования | 1 | 8 | 32 | 2,4 | Платформа 1С:Предприятие 8.3.27 |
Сервер БД | 1 | 48 | 768 | 33,0 | Программный комплекс XData Gen 2 ver. 3.0, Tantor Special Edition 1C 17.6 |
Нагрузчики | 18 | 112 | 755 | 3 | Каждый сервер разбит на 10 виртуальных машин, в которых запускаются около 167 сеансов, моделирующих нагрузку. |
На сервере СУБД был один процессор Baikal-S: 48 ядер Arm Cortex-A75 2.5 ГГц, материнская плата Элпитех, сетевое оборудование B4COM. В ходе теста менялась материнская плата Элпитех: начинали тесты на плате с поддержкой только 384 Гб ОЗУ DDR4-3200, но в ходе теста заменили ее на другую плату с поддержкой 768 Гб ОЗУ DDR4-3200.
Процессоры на серверах приложений 1С и нагрузчиках — Intel Xeon Scalable v2 Silver 4215/ Gold 6230R.
ОС на всех серверах и виртуальных машинах — Astra Linux Server.
Результаты тестов
Первый запуск мы провели на 5 тыс. пользователей. Он завершился с APDEX 0.834, и поскольку во время проведения возникла проблема с диском на одном из рабочих серверов 1С, мы его (тест) забраковали. Проблема приводила к тому, что дважды за время теста пользователи как бы переставали работать и падала нагрузка на сервер СУБД:
Перед новым запуском мы решили проблему с диском на рабочем сервере 1С, увеличили размер ОЗУ на сервере СУБД с 384 до 768 Гб ОЗУ и для снижения нагрузки на диски изменили следующие параметры Tantor Postgres:
temp_buffers: 64 MB → 128 MB
shared_buffers: 84 GB → 168 GB
enable_delayed_temp_file: off → on
Параметр enable_delayed_temp_file предназначен для решения следующей проблемы: 1С очень активно использует временные таблицы, а создание каждой временной таблицы, даже если ее размер менее чем temp_buffers, приводит к созданию на диске файлов, которые резервируют место на случай, если временную таблицу придется сбрасывать на диск. В высоконагруженных системах это может оказывать на диски значительную нагрузку и приводить к ожиданиям IO:DataFileExtend. Включение параметра enable_delayed_temp_file позволяет создавать файлы в оперативной памяти сеанса Tantor Postgres до тех пор, пока не будет использовано все пространство, отводимое параметром temp_buffers. Подробнее об этой оптимизации можно почитать здесь.
Следующий запуск на 5 тыс. пользователей завершился с APDEX 0.861, никаких проблем во время теста не было. График CPU сервера СУБД:
При следующем запуске увеличили количество пользователей до 10 тыс. получили APDEX 0.868. Результат улучшился, потому что ключевые операции, которые показали хороший APDEX на 5 тыс., выполнились еще бОльшее количество раз. График CPU сервера СУБД:
Как видим, запас по CPU еще довольно велик. Поэтому следующий запуск мы решили делать сразу на 20 тыс. пользователей — и получили APDEX 0.842.
Нагрузка на CPU значительно возросла:
Среднее время ожидания диска:
Отклик дисков был выше, чем на тестах с Intel. Решением тут могло стать подключение XDP — проприетарного программно-аппаратного рейда Tantor XData, который мы с Baikal-S на тот момент не использовали ввиду прохождения обкатки на тестовом стенде. Когда XDP стал доступен, мы вновь запустили тест на 20 тыс. пользователей и получили APDEX 0.846. Среднее время ожидания диска стало более равномерным, без явных пиков:
Этот результат нас устроил, и на 25 тысяч пользователей запускать тест мы не стали, поскольку запаса по CPU уже не осталось (а нам нужна была предсказуемая производительность). Также уже подходил к концу срок аренды серверов нагрузочного стенда.
Профилирование
Чтобы получить информацию о работе Tantor Postgres на ARM-процессоре, во время теста на 20 тыс. пользователей мы выполняли профилирование нагрузки через perf.
Максимальное потребление процессорного времени связано с функцией определения смещений атрибутов в кортежах таблиц. Особенность базы данных 1С — использование типа bytea (переменной длины) примерно в половине полей — исключает возможность кэширования смещений, требуя их пересчета для каждого кортежа. Процессоры Intel выполняют эти вычисления быстрее.
На втором месте по нагрузке находится обработка инвалидационных сообщений. В настоящее время остался один тип таких сообщений для временных таблиц — инвалидационные сообщения снимка системного каталога. Их игнорирование может нарушить работоспособность системы. Мы проводили альтернативный нагрузочный тест на процессорах Intel с нагрузкой 15 000 пользователей, и данный участок кода был в нем главной причиной замедления.
На третьем месте по нагрузке находится функция PinBuffer. Эта функция отвечает за закрепление (pinning) страниц в буферном кэше PostgreSQL на время их использования путем атомарного инкремента счетчика пина (refcount). Высокая нагрузка на PinBuffer связана с интенсивной конкуренцией за блокировки (spinlock) при частом обращении к одним и тем же буферным страницам множеством параллельных процессов. Кроме того, когда большое количество буферов находится в закрепленном состоянии, это замедляет работу алгоритма clock sweep при поиске буфера-жертвы для вытеснения, что увеличивает общее процессорное время, затрачиваемое на управление буферным кэшем (к сожалению, Flame Graph по этой проблеме не сохранился).
Сравнение с Intel
Для наглядности приведены графики нагрузки на CPU при 20 тыс. пользователей на Tantor XData 2B (Baikal-S) и Tantor XData 2Y (Intel):
Утилизация процессора. На Intel при нагрузке 20 тыс. пользователей средняя загрузка CPU составляла около 20–30%, что оставляло значительный запас для масштабирования. На Baikal-S при той же нагрузке утилизация достигала в пиках 70–80%, что приближается к границе комфортной эксплуатации. Это подтверждает наше решение не запускать тест на 25К пользователей: для обеспечения предсказуемой производительности необходим запас ресурсов.
Архитектурные различия. Как показало профилирование, основные различия в производительности связаны не с общей вычислительной мощностью процессоров, а со спецификой архитектуры:
Процессоры Intel более эффективно выполняют вычисление смещений атрибутов переменной длины;
Обе архитектуры показывают схожие проблемы с обработкой инвалидационных сообщений системного каталога.
Перспективы масштабирования. В ближайшем будущем ожидается поставка двухсокетной платы от компании «Элпитех» с поддержкой двух процессоров Baikal-S. Это даст 96 физических ядер вместо текущих 48, до 1.5 ТБ оперативной памяти и возможность пройти тест на 30 тыс. пользователей с запасом производительности.
Заключение
Производительность для enterprise-сегмента. Нагрузочное тестирование МБД Tantor XData 2B показало, что отечественная платформа на базе процессоров Baikal-S готова к промышленной эксплуатации в enterprise-сегменте. Успешное прохождение теста на 20 тыс. пользователей с APDEX 0.846 демонстрирует достаточную производительность для абсолютного большинства внедрений 1С:Предприятие.
Производительность для массового рынка. Tantor XData 2B обеспечивает необходимую производительность для этого сегмента, открывая возможность импортозамещения без компромиссов в пользовательском опыте.
Соответствие регуляторным требованиям. Решение полностью соответствует требованиям 398-ФЗ «О безопасности критической информационной инфраструктуры» и другим нормативным актам, регулирующим использование отечественного ПО и оборудования в государственных организациях и компаниях с госучастием. Это критически важно для участия в государственных контрактах и соблюдения корпоративных политик импортозамещения.
Единая экосистема Tantor. Ключевое преимущество нашего подхода — обе модели Tantor XData (2Y и 2B) используют идентичную сборку PostgreSQL, инструменты управления и мониторинга. Это означает:
Возможность миграции между платформами без изменения архитектуры решения;
Единые процедуры резервного копирования и восстановления;
Общие компетенции администраторов БД;
Гибкость в построении гибридных инфраструктур (часть систем на Intel, часть на Baikal-S).
Предсказуемость поставок. В условиях санкционного давления использование процессоров Baikal-S гарантирует отсутствие рисков, связанных с ограничениями на поставку зарубежного оборудования. Это обеспечивает предсказуемость как при первоначальном развертывании, так и при масштабировании инфраструктуры.
Благодарности
Вообще, создание конкурентоспособных отечественных решений делают возможным именно совместные усилия участников российской экосистемы импортозамещения. Результаты этих тестов — прекрасный результат для нашего рынка enterprise-решений, и мы хотели бы особо поблагодарить:
Компанию YADRO — за предоставленные для проведения тестов сервера;
Команду разработки СУБД Tantor Postgres за постоянную работу по ее улучшению;
Инженеров XData — за работу по созданию отечественных МБД и готовность решать проблемы 24/7;
Компанию «ИТ-Экспертиза» — за профессиональное проведение нагрузочных тестов и готовность запускать их даже в 4 утра в субботу;
Компанию «Элпитех» — за разработку отечественных материнских плат.
