Техническое закулисье НТ на 30 000 АРМ: тюнинг СУБД, настройки и вот это всё

В последней статье по докладу Алены Генераловой и Александра Симонова на INFOSTART TECH EVENT 2025 поговорим про тюнинг СУБД Tantor Postgres и других технических настройках и доработках, которые мы сделали в рамках нагрузочного тестирования на 30 000 АРМ. Напоминаем, что в первой части мы рассказывали, как ускорить подготовку теста и настроить шаблон для 180 виртуальных машин (ВМ) с помощью Ansible. Во втором материале обсуждали запуск теста и сбор артефактов, поговорили про архитектуру кластера 1С и настройку свойств СУБД. А в третьей статье поделились проблемами профилирования, с которыми мы столкнулись, и способами их решения.

1. Итоговый результат APDEX
2. Сервер СУБД
3. Точки развития
4. Дополнительные НТ
5. Технические детали теста

Итак, переходим к настройкам Tantor Postgres – на изображении ниже можно увидеть, как был настроен инстанс СУБД.

Общие настройки: 

• Work_mem, temp_buffers, hash_mem_multiplier – мы постепенно увеличивали данные параметры, анализируя данные прошлых прогонов, чтобы уменьшить количество создаваемых временных файлов
• Автовакуум был настроен агрессивно, т.к. нам было важно, чтобы была актуальная статистика для качественного планирования запросов
• Huge_pages включены, так как с ними некоторые отчеты формировались быстрее 
• Enable_temp_memory_catalog – ключевая настройка для победы над раздутием системного каталога Tantor Postgres 

Настройки планировщика, которые были выставлены в соответствии с рекомендациями команды «Тантор Лабс» и включали все фичи, выглядели так:

• enable_convert_exists_as_lateral_join – оптимизация запросов с 1С-ными РЛС
• enable_filter_predicates_reordering – оптимизация фильтрации в узлах плана запроса index scan, sec scan, join filter
• enable_index_path_selectivity – оптимизация, позволяющая преимущественно использовать покрывающие индексы при наличии нескольких подходящих под условия запроса
• enable_join_pushdown – оптимизация запросов к виртуальным таблицам 1С 

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

Итоговый результат APDEX 

Самый успешный прогон показал результат APDEX 0.859

Мы были довольны результатом, т.к. проделали колоссальную работу в ходе проведения нагрузочного теста. А теперь давайте посмотрим на графики оборудования. Платформа 1С хорошо справлялась с 30 тысячами пользователей, а нагрузка по CPU была в среднем 30% на всех серверах приложений:


На сервере СУБД нагрузка на CPU была примерно такой же; дисковая подсистема также имела огромный запас прочности


А вот несколько внутренних графиков Tantor Postgres (среднее количество idle-сессий во время теста держалось в диапазоне 600-700) 

Сервер СУБД 

Важно понимать, что не только тюнинг настроек и доработка Tantor Postgres силами команды «Тантор Лабс» помогли достигнуть такого результата. Огромную роль сыграло и само оборудование, на котором работал сервер СУБД – ПАК Tantor XData 2Y в минимальной комплектации, куда входили 3 вычислительных сервера – характеристики представлены ниже
Сервер СУБД Tantor XData 2Y – характеристики 

Минимальная комплектация, 3 вычислительных сервера:

• 2x Intel Xeon Platinum 8362, 3600 MHz 128 vCPU
• RAM 2 Тб DDR4-3200
• Программно-аппаратный рейд XData
• Сеть 25 Гбит/с 

• 112 vCPU
• 1.5 Тб RAM 

ОС Astra Linux 1.7.6, ядро 6.1.50-1-generic.

Особое внимание заслуживает программно-аппаратный рейд Tantor XData, который при работе с ОС Astra Linux позволил держать любую нагрузку по дискам с большим запасом прочности. Внутри одного из вычислительных серверов был развернут контейнер (по сути, виртуальная машина) с 112 виртуальными CPU и 1.5 Тб RAM, внутри которого и работал инстанс СУБД Tantor Postgres. 

Точки развития 

Нагрузочный тест показал точки роста, которые позволят еще больше повысить производительность:

1. Долгое планирование запросов с большим количеством таблиц JOIN/FROM
По итогам анализа технологического журнала (ТЖ) в топе было много запросов, которые выполнялись 300-500 мс. При этом план запроса показывал, что сам запрос выполнялся за миллисекунды, а 99% времени занимало его планирование, т.е. перебор различных вариантов его исполнения. Понижение *_collapse_limit'ов ускоряло планирование этих запросов, но все равно оно занимало 50 мс, и таких запросов были тысячи. Механизм перебора вариантов соединения таблиц имеет потенциал оптимизации, поэтому команда «Тантор Лабс» решила в следующих релизах ускорить время планирования таких запросов. 

2. Тип bytea
В базе ERP 160 тысяч полей и примерно половина из них имеют тип bytea. Он используется для ссылочных полей и хранилищ значения. При этом сам этот тип переменной длины, хотя большинство полей, которые его используют фиксированной длины (тип поля, тип ссылки и сама ссылка). В MSSQL Server для этих полей используется тип binary размерностью 1, 4 и 16. Использование bytea вместо фиксированных типов данных создает дополнительные издержки, потому что база данных вынуждена хранить служебную информацию о длине каждого значения и выполнять дополнительные операции десериализации при чтении. 

Кроме того, переменная длина препятствует эффективному использованию прямой адресации в памяти и на диске, что замедляет как доступ к данным, так и их кэширование, а также увеличивает фрагментацию хранилища и требует больше операций при распаковке кортежей из дисковых блоков. Если написать типы bytea фиксированной длины и научить платформу 1С создавать поля с этими типами вместо bytea, то предположительно это может ускорить работу связки 1С + Tantor Postgres на 10% и более. 

3. Параллелизм и временные таблицы
Сейчас наличие временной таблицы в запросе является блокирующим фактором для использования параллелизма, при этом в данном нагрузочном тесте было много ключевых операций по отчетам, которые выполнялись более 20 секунд. Анализ показал, что параллелизм мог бы ускорить выполнение таких ключевых операций в несколько раз. В рамках релиза Tantor Postgres 17.6 уже снята часть ограничений на использование параллелизма в таких запросах, оставшиеся ограничения команда «Тантор Лабс» планирует убрать в 18 версии. 

Еще несколько дополнительных НТ 

1. В рамках решения задач по импортозамещению компании «ИТ-Экспертиза» и «Тантор Лабс» решили пойти дальше и запустили данный нагрузочный тест на машине баз данных (МБД) Tantor XData 2B, работающей на базе российских процессоров Baikal-S и использующей СУБД Tantor Postgres. В рамках эксперимента была смоделирована работа 20 000 одновременных пользователей, выполняющих типовые операции, включая процессы продаж, закупок, производства, бухгалтерского учета и управления персоналом. 

2. Со стороны АНО «НЦК ИСУ» было инициировано проведение тестирования по собственной разработанной методологии со сценариями работы крупного предприятия в различных часовых поясах. Нагрузочное тестирование выполнялось с помощью инструмента «1С:Тест-Центр» и имитировало процессы полноценного рабочего дня для основных ролей ERP-системы – диспетчеров производства, менеджеров по продажам и закупкам, сотрудников склада и бухгалтерии с общей численностью 15 000 одновременно работающих пользователей. APDEX составил 0.950, что соответствует уровню «Отлично». 

Технические детали теста 

Кластер тестирования «1С:Предприятие» был развернут на машине баз данных Tantor XData 2Y, построенной с использованием серверов VEGMAN R220 G2. Нагрузку моделировали восемнадцать серверов VEGMAN S220 в связке с сетевыми коммутаторами KORNFELD. 

В ходе выполнения теста средняя загрузка процессора на сервере СУБД не превышала 30-40%, на серверах приложений оставалась ниже 40%. Дисковая подсистема показала время отклика при чтении порядка одной-двух миллисекунд, при записи – около пяти миллисекунд. Длительность теста составила 11 часов непрерывной работы, и за это время не было зафиксировано падений процессов, критических ошибок или блокировок. 

Условия тестирования

Технические характеристики оборудования для проведения тестирования

Сервер лицензирования:

• Intel Xeon Scalable v2 Silver 4215
• Память 32 Гб DDR4-3200 ECC RDIMM
• 2 x Накопитель SSD NVMe Gen3 1.6 ТБ 7300MAX 

Сервер СУБД – машина баз данных Tantor XData 2Y: 

• Минимальная комплектация (3 вычислительных сервера)
• 2x Intel Xeon Platinum 8362, 3600 MHz 128 vCPU
• RAM 2 Тб DDR4-3200
• Программно-аппаратный рейд XData
• Сеть 25 Гбит/с
• Внутри вычислительного сервера поднят контейнер для инстанса СУБД Tantor Postgres: 112 vCPU, 1.5 Тб RAM
• ОС AstraLinux 1.7.6, ядро 6.1.50-1-generic 

Нагрузчик:

• Intel Xeon Scalable v2 Gold 6230R
• DDR4-3200 RDIMM ECC 2Rx4
• 2 x Накопитель SSD 3.84 Tb SATA 2.5" PM893
• Сеть: 10 Гбит/с. 

База наполнена данными за 2 месяца работы крупного предприятия – около 10 млн документов. СУБД, кластер серверов и нагрузчики с тонкими клиентами платформы «1С:Предприятие» были развернуты на ОС Astra Linux 1.8. Выбранный сценарий моделировал реальную нагрузку на систему и воспроизводил повседневную работу основных пользователей ERP:

• главный диспетчер производства
• локальный диспетчер производства
• менеджер по закупкам
• менеджер по продажам
• кладовщик
• внутреннее потребление товаров
• планирование производства
• бюджетирование
• бухгалтер по внеоборотным активам
• бухгалтер по взаиморасчетам
• бухгалтер 

Все действия пользователей выполнялись с учетом ограничений прав на уровне записей (RLS) 

Будет интересно

– САКУРА 3 выдержала нагрузку 105 000 удаленных рабочих мест: 0% отказов, подтверждена катастрофоустойчивость
– Нагрузочное тестирование на российских процессорах Baikal-S 20 000 одновременно работающих пользователей 1С:ERP
– Независимое нагрузочное тестирование решения «1С:ERP» на 30 тысяч одновременно работающих пользователей