Доклад «Как мы провели нагрузочный тест на 30 000 пользователей»

Ключевые выводы

1. Тест действительно повторяет «эталон» 1С на 30 000 пользователей, но полностью на импортозамещённом стеке: Astra Linux, Tantor Postgres, аппаратный комплекс STX Data 2i, отечественный RAID Tantor.​
2. Основной bottleneck оказался не в железе и не в 1С, а в PostgreSQL-совместимой СУБД Tantor Postgres – очередь инвалидационных сообщений и удаление индексов временных таблиц.​
3. Команда добилась апдекса ≈0,859 при 30 000 пользователях и 860 тыс. операций за 11 часов, при этом CPU и диски были далеко не на пределе, что говорит о серьёзном запасе по ресурсам железа и о том, что «потолок» упирался в архитектурные нюансы СУБД.​
4. Практическая ценность для архитектора 1С: показаны конкретные приёмы:
   • как подготовить стенд на 180 ВМ под нагрузочное тестирование (Cloud-Init + Ansible);
   • как автоматизировать «цикл жизни» одной прогона теста (reset настроек, бенчмарки, запуск/остановка агентов, сбор артефактов);
   • как грамотно настроить кластер 1С (развод ролей центрального и рабочих серверов, сервис сеансовых данных, резервирование рабочих процессов, задержка выгрузки конфигурации).​
5. Инженерно интересная часть — доработки самой СУБД под 1С‑нагрузку: отключение инвалидации по временным таблицам, оптимизация удаления индексов и автоматическая перепись «плохих» запросов вида ... OR ... во внутренне более оптимальное представление с использованием индексов (аналог приёмов MS SQL Server).​

Ниже — подробный разбор по блокам.

---

1. Цели и контекст теста

Название доклада «Как мы провели нагрузочный тест на 30 тысяч пользователей«.
Докладчики: Алёна Генералова (компания «Экспертиза») и Александр Симонов (Tantor / STX Data).​

Цель: повторить тест фирмы 1С на 30 000 пользователей ERP (1С:ERP 2.5) с теми же сценариями и той же базой, но на полностью отечественном стеке:​

• ОС: Astra Linux.​
• СУБД: Tantor Postgres 17 (PostgreSQL-совместимая, в реестре Минцифры).​
• Аппаратный комплекс: STX Data 2i, оборудование из реестра Минпромторга.​

Параметры эталонного теста:

• Конфигурация: 1С:ERP 2.5.
• Размер ИБ: около 1,25 ТБ.​
• Продолжительность моделируемого рабочего дня: 11 часов.​
• Количество пользователей: до 30 000 виртуальных рабочих мест (ВРМ).​
• Сценарии: полностью те же, что у 1С (база и сценарии получены от фирмы 1С по запросу).​

Для усиления валидности результатов команда шла поэтапно по нагрузке:

• 20 000 пользователей — успешно.​
• 25 000 — падение через ~40 минут по причине проблем в СУБД (взрыв активных сессий и блокировок).​
• 30 000 — после доработок СУБД и настройки инстанса тест завершился успешно с апдексом ≈0,859.​

Параллельно проводился второй тип теста с наращиванием нагрузки (каждый час +3000 роботов) и другими сценариями, где удалось дойти до 15 000 «роботов» при существенно большей интенсивности операций, упершись уже в CPU сервера СУБД.​

---

2. Подготовка инфраструктуры и стенда

180 виртуальных машин-нагрузчиков

Схема:

• Серверы приложений 1С — физические.​
• Нагрузчики — ВМ на Linux (Astra), по ~10 ВМ на хост.​
• Всего около 180 ВМ, каждая под одного агента нагрузочного тестирования.​

Почему 180 ВМ:

• На одном Linux-сервере можно запустить только одного агента нагрузки (ограничение агента 1С; попытка второго агента в другой X-сессии выдаёт ошибку «агент уже запущен»).​
• Ограничения оконного менеджера / графической оболочки в Astra Linux: оптимально не превышать 250–300 виртуальных рабочих мест на машину, выяснено экспериментально.​

Шаблон ВМ с Cloud-Init

Чтобы не поднимать 180 ВМ руками:

• Взяли шаблонный образ Astra Linux с предустановленным Cloud-Init.​
• Cloud-Init позволяет при первом старте ВМ сконфигурировать:
  • сеть;
  • пользователи;
  • базовые параметры ОС;
  • прочие настройки, чтобы после развертывания не было необходимости ручной донастройки.​

Настройки шаблона:

• Тюнинг графического интерфейса Fly в Astra Linux:
  • увеличили лимит открываемых окон, чтобы при старте большого числа ВРМ не упираться в ограничение оконного менеджера.​
• Предустановка ПО:
  • 1С (клиент);
  • XRDP для удалённого доступа;
  • система мониторинга (для контроля жизни ВМ);
  • утилиты atop и iostat для сбора метрик без доп. ПО.​
• Используемые бенчмарки:
  • fio, sysbench (в докладе звучит как Fio / ISIS Bench) для проверки дисковой подсистемы и стенда перед тестами; в прошлом сталкивались с тем, что диски «не дотягивали» до заявленных характеристик.​

При проверке шаблона всплыла ошибка «недостаточно памяти при открытии 1С» – баг известен, описан на багборде; применили известный workaround и двинулись дальше.​

Автозапуск агентов 1С

Идея: при подключении по RDP к ВМ автоматически стартует 1С в режиме агента нагрузки.

Механика:

• В папку автозапуска пользователя кладут специальный .desktop-файл, который запускает 1С с нужными ключами.​
• В строке запуска 1С указываются ключи:
  • режим агента тестирования;
  • отказ от аппаратных лицензий;
  • отключение стартовых сообщений (иначе 180 модальных окон и тест не стартует без ручных кликов).​

Это важно: любые диалоги / модальные окна при старте агентов = смерть автоматического теста.

Массовое развертывание ВМ через Ansible

Выбор инструмента: Ansible (в докладе звучит как «Enible» из-за расшифровки).

Причины:

• Идемпотентность: playbook можно запускать повторно без риска поломать уже развернутое, доразворачиваются только недостающие ВМ.​
• Безагентность: не нужны отдельные агенты, достаточно Python на хосте; можно даже без предустановленного Python с помощью raw-модуля, который сам догрузит Python.​
• Доступность в российских репозиториях Astra и др. систем.​
• Простота: playbook — обычные текстовые файлы, их можно и из интернета взять, и «попросить ИИ написать».​

Технический приём:

• Сначала скопировали шаблон образа Astra Linux на каждый хост, чтобы во время клонирования ВМ не гонять большие образы по сети.​
• Один основной playbook развернул весь стенд менее чем за час.​

---

3. Автоматизация жизненного цикла теста

Чтобы каждый прогон был сопоставим и воспроизводим, автоматизировали подготовку и завершение:

Перед запуском каждой итерации:

• Восстановление настроек СУБД до эталонных.​
• Запуск / восстановление всех необходимых служб.​
• Полная очистка артефактов предыдущих запусков:
  • логи;
  • временные файлы;
  • прочий «мусор».​
• Запуск бенчмарков (fio/sysbench), чтобы убедиться, что стенд и железо в порядке.​
• Копирование нужных настроек технологического журнала (могли варьировать во время расследования проблем).​
• Повторный запуск служб, старт RDP-сессий → поднимаются агенты 1С.​

После прогона:

• Фиксация размера сеансовых данных.​
• Сбор всех логов и артефактов:
  • файлы atop и другие метрики (atop конвертируют в текст для анализа и построения графиков);
  • логи 1С и СУБД;
  • отчёт Apdex.​
• Упаковка артефактов в одну папку, закрытие RDP-сессий.​

Очень хорошая фраза: «Нет артефактов — вы никому не докажете, что тест проводили». Для практики нагрузочного тестирования — абсолютно в точку.​

---

4. Архитектура и настройка кластера 1С

Роли серверов кластера

Исходно центральный и рабочие сервера были одинакового sizing-а, но в ходе экспериментов пришли к такой схеме:​

• Центральный сервер 1С:
  • выполняет только фоновое задание теста;
  • держит все основные сервисы менеджера кластера (служебные процессы).​
• Три рабочих сервера:
  • обслуживают клиентские соединения;
  • хранят сеансовые данные.​

Ключевой акцент: центральный сервер не должен таскать на себе пользовательскую нагрузку, его задача — координация и фоны.

Сервис сеансовых данных

Особая роль сервиса сеансовых данных (THIN/THICK sessions):

• Если явно не указать, на каких серверах он должен подниматься, он поднимется на центральном сервере, а на рабочих не будет.​
• Тогда все клиентские сеансы с рабочих серверов будут ходить на центральный за сеансовыми данными, создавая лишний сетевой и ресурсный трафик.​

Решение:

• На центральном сервере: ТНФ для сервиса сеансовых данных – не назначать.​
• На рабочих серверах: назначить auto (сервис поднимается на них).​

Результат — минимизация межсерверного трафика по сеансовым данным.

Свойства ИБ: резервирование рабочих процессов

Проблема: нужно одновременно открыть 30 000 ВРМ.

• Рабочий процесс 1С имеет лимит соединений. Когда лимит исчерпан, требуется запуск нового рабочего процесса 1С.
• Для ERP-базы с большим контекстом запуск нового процесса и загрузка контекста — долгая операция, из-за чего пользователи будут ждать.​

Использовано свойство резервирования рабочих процессов для базы:

• Всегда держится резервный рабочий процесс.
• Как только в активном рабочем процессе исчерпаны соединения, резервный становится активным, а параллельно поднимается новый резервный.​

Эффект: ускорение открытия ВРМ, итоговое время подъёма 30 000 сессий — порядка 50 минут.​

Задержка выгрузки конфигурации

Второе важное свойство базы:

• «Задержка выгрузки конфигурации рабочим процессом».​

Семантика:

• Это таймаут, по истечении которого данные ИБ будут выгружены из рабочего процесса, когда число соединений в этом процессе станет 0.
• При ненулевой задержке рабочий процесс сохраняет загруженный контекст ещё некоторое время после ухода последнего сеанса.​

Эффект:

• Снижение накладных расходов на постоянную загрузку контекста ИБ.
• Особенно полезно при волнообразной нагрузке и массовых открытиях/закрытиях сессий.

---

5. Подготовка базы ERP к тесту

Фазы теста:

• подготовка;
• инициализация;
• выполнение;
• запись результатов;
• удаление результатов и т. д.​

Особенности:

• Выполнение теста — 11 часов, максимум 1 прогон в сутки.​
• Фаза подготовки очень долгая:
  • создаются 30 000 пользователей (элементы в справочнике «Пользователи»);
  • каждому пользователю соответствуют расчёты прав доступа из-за включённого ограничения доступа к записям.​

Оптимизация (лайфхак):

• Запустить тест без агентов:
  • база создаёт пользователей и считает права;
  • после этого зафиксировать состояние (бэкап).​
• Далее перед каждым тестом разворачиваться из этого бэкапа, не тратя часы на пересоздание пользователей и пересчёт прав.​

Тонкости, без которых тест может «не поехать»:

• Перед запуском каждый раз убеждаться, что:
  • справочник «Виртуальные пользователи» пуст;
  • справочник «Агенты» пуст;
  • нет «агентов-призраков».​
• В настройке клиентов тест-центра:
  • корректный путь к бинарникам 1С;
  • флаг «не использовать аппаратные лицензии»;
  • отключение стартовых сообщений.​
• Обязательно делать бэкап подготовленной базы, потому что итераций будет несколько.​

---

6. Поведение теста и поиск узких мест

Первые прогоны и симптомы проблем

• 20 000 пользователей — всё ок, тест 11 часов, Apdex получен.​
• 25 000 пользователей — через ≈40 мин тест падал:
  • CPU сервера СУБД не загружен (огромный запас по процессору);
  • на инстансе СУБД Tantor Postgres количество активных сессий резко росло до нескольких тысяч, пока не упиралось в max_connections.​

Инструменты диагностики:

• pg_stat_activity — показал распределение сессий по состояниям и видам блокировок.​
  • Виден рост активных сессий, у которых появляются блокировки вида LWLock, LWLock: ... — внутренние lightweight-блокировки PostgreSQL.​
• Понимания «что болит» этого мало — нужно профилирование кода СУБД.

Использовали perf — профилировали исходный код Tantor Postgres, чтобы увидеть, где тратится время.​

Проблема №1: очередь инвалидации метаданных

Механизм:

• Каждый backend при старте загружает в кэш метаданные (системный каталог: таблицы, колонки и т. д.).​
• При изменении метаданных (добавить колонку, создать/удалить временную таблицу, индекс и т. п.) процесс кладёт сообщение в очередь инвалидации.​
• Другие сеансы при выполнении запросов проверяют эту очередь: нет ли сообщений по таблицам, с которыми они работают; при нахождении — обновляют у себя локальные метаданные.​

На практике:

• Несмотря на то, что «никто не меняет схему во время работы», создание временных таблиц и индексов — это тоже изменение метаданных.
• При очень большом числе сеансов:
  • очередь быстро забивается;
  • её размер ограничен (до 16 000 сообщений).​
• Когда место заканчивается, запускается процесс массового чтения и очистки очереди всеми сеансами:
  • это приводит к лавинообразным блокировкам на внутренних LWLock и росту числа активных сессий в ожидании.​

Решение:

• Не слать инвалидационные сообщения по временным таблицам.​

Результат:

• После доработки и нового прогона:
  • тест завершился успешно;
  • Apdex около 0,6 — это уже «на границе проблемы», видны неравномерность по CPU и активным сессиям, проблема блокировок ещё не до конца решена.​

Проблема №2: долгое удаление индексов временных таблиц

Дальнейшее профилирование выявило вторую точку:

• Очень долго выполняется удаление индексов временных таблиц.​

В PostgreSQL метаданные индексов и таблиц хранятся в системных каталогах:

• pg_class — сами объекты;
• pg_type — типы полей;
• pg_attribute и т. д.​

При удалении индекса:

• Сначала чистятся все связанные записи в системном каталоге (аналог удаления ведущей ссылки в 1С с каскадным удалением зависимых записей регистра).​
• Только после этого удаляется сам индекс.

При массе временных таблиц и индексов (типичная нагрузка ERP+сложные отчёты) эта операция становится заметным bottleneck.

Решение:

• Оптимизация кода механизма удаления индексов в Tantor Postgres (ускорение работы с системным каталогом).​

Результат:

• Запуск теста уже сразу на 30 000 пользователей.
• Тест завершился успешно, количество активных сессий ≤50.
• Apdex — на границе «плохо/хорошо»; команда хотела лучше.​

Проблема №3: «плохой» запрос в отчётах (OR + подзапрос)

Следующий bottleneck — ключевой отчётный запрос, который выполнялся до 15 секунд и встречался 8000 раз.​

Характеристики запроса:

• В секции WHERE есть условия через OR по одному и тому же полю.
• Присутствует вложенный подзапрос.
• По полю есть индекс, но оптимизатор не использует индекс, потому что:
  • комбинация OR + подзапрос не даёт возможности безопасно переписать запрос в форму, где индекс по этому полю будет эффективно использован;
  • последовательное сканирование таблицы (seq scan), с точки зрения планировщика, кажется более «дешёвым».​

По условиям теста:

• Нельзя было:
  • менять код 1С;
  • добавлять новые индексы в ИБ;
  • переписывать сам запрос в конфигурации.​

Решение — доработка самой СУБД:

• Логика оптимизации:
  • исходный запрос (в терминах 1С) можно математически эквивалентно переписать на два запроса:
    • первый — с первым условием;
    • второй — со вторым условием;
  • OR заменить на ОБЪЕДИНИТЬ ВСЁ (UNION ALL / UNION) с отрицанием соответствующей части условия во втором запросе;
  • итоговый результат выборки сохраняет семантику, но даёт возможность применить индекс (каждый из двух запросов имеет более простой предикат).​
• Tantor Postgres научили автоматически определять такие шаблоны текстов запросов и переписывать их в более оптимальный вид (аналог того, что делает MS SQL Server).​

После включения этой оптимизации и корректировки настроек инстанса (см. ниже) удалось выйти на «хороший» результат.

---

7. Настройки инстанса Tantor Postgres и итоговый результат

Основные настройки инстанса

Подход:

• Многократные запуски, по чуть-чуть:
  • увеличивали work_mem и temp_buffers, чтобы сократить объём дисковой активности по временным файлам.​
• Автовакуум:
  • настроен агрессивно, чтобы статистика была как можно более актуальной;
  • неактуальная статистика приводит к выбору неоптимального плана запросов и дополнительным задержкам.​
• Настройки планировщика:
  • все разработанные оптимизации Tantor 17.5 включены:
    • оптимизация удаления индексов временных таблиц;
    • отключение инвалидации по временным таблицам;
    • переписывание запросов с OR.​
• Разнесение по дискам:
  • ничего не разносили: и WAL, и временные таблицы, и обычные таблицы, и индексы — на одном логическом диске.​
  • Это стало возможным благодаря мощности RAID Tantor и общей дисковой подсистемы — время отклика по дискам в тесте было в пределах ≈10 мс, утилизация далека от предельной.​

Результаты «успешного» прогона на 30 000 пользователей

Основной тест:

• Пользователей (ВРМ): 30 000.​
• Длительность: 11 часов.​
• Операций (по отчёту Apdex): 860 000.​
  • Один из участников в зале подсчитал, что это ~30 операций на пользователя за 11 часов.
  • Докладчики пояснили:
    • статистика сценария теста 1С построена по реальным данным самой крупной компании: выгрузили журнал за год, поделили на число пользователей и рабочие часы;
    • получилось, что обычный пользователь делает ~1 операцию раз в 20 минут, т. е. те самые ~30 операций за рабочий день — это реалистично для бухгалтерии и ERP.​
• Итоговый Apdex ≈0,859 (по словам докладчиков — «на границе хорошо»).​

Поведение оборудования:

• Серверы приложений 1С:
  • CPU: 30–40% загрузки (совокупно по всем серверам приложений).​
  • Диски и ОЗУ — с большим запасом.​
• Сервер СУБД Tantor Postgres:
  • CPU — также с огромным запасом.
  • Среднее количество транзакций: порядка 8000 транзакций в секунду.​
  • Активные сессии ~постоянны, около фиксированного уровня; спящие (idle) — около 1000.​
  • Автовакуум отрабатывает «шустро», без завалов.​

Вывод: после оптимизаций узкое место СУБД было существенно поднято, а железо (STX Data 2i + RAID Tantor) не стало ограничивающим фактором.

---

8. Железо: STX Data 2i и RAID Tantor

Состав комплекса:

• Три вычислительных сервера в составе STX Data 2i (подробные конфигурации на слайде, в докладе отдельные цифры не проговариваются вслух).​
• Внутри одного из этих серверов:
  • поднят контейнер с инстансом Tantor Postgres;
  • выделено 112 ядер CPU и 1 ТБ ОЗУ под СУБД.​
• ОС сервера СУБД: Astra Linux 1.7.6.​
• Дисковая подсистема:
  • собственный программно-аппаратный RAID Tantor;
  • паспортная способность — до 2 млн операций ввода-вывода в секунду;
  • в тестах время отклика ≤10 мс; утилизация далека от лимита.​

Отсюда объяснение, почему:

• не разносили временные таблицы и WAL на разные физические устройства — «лечить бутылочное горлышко, которого нет» смысла нет.​

---

9. Точки развития, выявленные по итогам теста

Команда выделила несколько направлений дальнейшей оптимизации Tantor/Postgres под 1С‑нагрузку.

Ускорение планирования сложных запросов

Наблюдение:

• Были запросы (например, по логам технологического журнала), которые выполнялись ≈1 секунду, при этом 99% времени уходило на фазу планирования, а не исполнения.​
• Эти запросы:
  • содержат 20–30 таблиц;
  • сложные схемы джойнов.​

Вывод: есть простор для оптимизации алгоритмов планировщика (перебора вариантов соединений таблиц) для таких многотабличных запросов.

Тип данных для ссылочных полей

Ситуация:

• В ERP-базе примерно 160 000 полей, половина из них — ссылочные.​
• PostgreSQL (и Tantor Postgres) для ссылок использует тип с неограниченной длиной (bytea / varlena-подобный), что требует дополнительных проверок при чтении/записи, т. к. длина не фиксирована.​

Проблема:

• Тип без фиксированного размера подразумевает лишний код и накладные расходы при работе с данными.​

Сравнение с MS SQL Server:

• Там используются типы вида binary(16) — фиксированной длины.​

Идея:

• Добавить в PostgreSQL-экосистему аналогичные фиксированной длины типы (например, uuid уже есть, но для 1С-идентификаторов можно завести свои), и:
  • научить платформу 1С создавать поля сразу с правильным типом ограниченной длины;
  • это потенциально даёт +10–15% производительности любых баз 1С на связке PostgreSQL/Tantor, за счёт снижения накладных расходов.​

Параллельное выполнение запросов с временными таблицами

Ограничение:

• В текущих версиях PostgreSQL не используется параллелизм, если в запросе участвуют временные таблицы.​
• В тесте ERP много отчётов, которые выполнялись по 20–40 секунд, и почти везде использовались временные таблицы → параллелизм был выключен.​

Планы Tantor:

• В версии 17.6 — частично снять ограничения по параллелизму с временными таблицами.​
• В версии 18.x — снять все ограничения, что позволит значительно ускорить сложные отчётные запросы.​

---

10. Дополнительные моменты из Q&A

Несколько существенных уточнений из вопросов зала:

• Версия платформы 1С:
  • использовали 8.3.27.1529 (ветка 8.3.27, обозначаемая 8.5.1 в маркетинге 1С).​
  • Это та же версия, что в тесте 1С; более новая 8.5.2 (8.3.??) также тестировалась фирмой 1С, но в докладе – только 8.3.27.​
• Фоновые задания:
  • в эталонном 30k-тесте все регламентные задания отключаются (так же, как у 1С).​
  • Во втором тесте с наращиванием нагрузки запускалось закрытие месяца на фоне (5 часов на фоне 15 000 активных «роботов») — заведомо «садистский» сценарий.​
• Соответствие теста «честной» эмуляции действий пользователя:
  • используется тонкий клиент, сценарий кликает по формам, заполняет поля, вызывает печатные формы — это «по‑честному» эмуляция UI-активности, а не чистые вызовы API.​
• Сценарий нагрузки и «мало операций»:
  • 30 операций за 11 часов на пользователя — это статистически выведенная цифра для крупнейшей компании по их реальным журналам.​
  • Другой тест с «роботами, которые не отдыхают» показывает, что 15 000 роботов примерно соответствует 30 000 живых бухгалтеров по нагрузке.​
• Сравнение с «чистым Tantor без STX Data 2i»:
  • таких данных нет: цель теста — демонстрация комплекта (СКЗИ, железо, СУБД), а не сравнение «голой СУБД».​

---

11. Практическая ценность доклада для архитектора/эксперта 1С

С инженерной точки зрения доклад очень полезен, потому что:

• Показывает конкретный, воспроизводимый pipeline для больших нагрузочных тестов:
  • шаблон ВМ + Cloud-Init;
  • Ansible для массового развёртывания и управления;
  • чёткая автоматика «до» и «после» теста;
  • системный сбор артефактов.
• Даёт живые, проверенные на больших числах подходы к настройке кластера 1С:
  • разведение ролей центрального и рабочих серверов;
  • правильная конфигурация сервиса сеансовых данных;
  • использование резервных рабочих процессов и задержки выгрузки конфигурации.
• Подчёркивает важность анализа именно поведения СУБД на уровне исходного кода при высоких нагрузках, а не только «крутить параметрами postgresql.conf».
• Показывает, что импортозамещённый стек (Astra Linux + Tantor Postgres + STX Data 2i) способен выдержать «эталонный» тест 1С на 30 000 пользователей с хорошим запасом по ресурсам, при условии доработки СУБД под специфику 1С‑нагрузки.