Мы продолжаем серию статей по анализу производительности 1C. В наших прошлых материалах мы изучали производительность гипервизоров, а также сравнивали различные виды облака для большого числа пользователей.
При построении высоконагруженной структуры для 1C:Предприятие помимо вопроса производительности, важную роль играет стоимость решения. Сможет ли бесплатная система выдавать схожие с платным продуктом результаты? Какова разница?
Целью данной статьи является изучение в 2022 году производительности 1С в среде Hyper-V, используя Microsoft SQL 2019 (далее MSSQL 2019) и PostgreSQL 12.
Состав тестового стенда
Аппаратная часть
- Supermicro X11DPi-N
- 2 x Intel Xeon Gold, 6244 (3,6 – 4,4 GHz, each 8 Core)
- ОЗУ 384 ГБ DDR4
- Хранилище RAID 10, Intel DC S3710 SSDSC2BA400G401 400 ГБ, 2х Intel NVME 750 ГБ SSDPED1K750GA01
Программная часть (1C)
- Платформа 1С:Предприятие 8.3.18.1698
- Конфигурация 1С:ERP Управление предприятием 2, редакция 2.4.13.282, объем базы 44 ГБ.
Программная часть (Windows, аппаратный сервер и ВМ)
- Windows Server 2019 Standard
- SQL Server 2019 Enterprise
- PostgreSQL 12.7-5.1C
Программная часть виртуальной машины LINUX
- Debian 11
- PostgreSQL 12.7-5.1C
Общая методика тестирования
- В рамках данной статьи мы применяем методику анализа, используя абсолютные значения погрешности.
Описание методики определения абсолютной погрешности:
- Определяются идеальные условия испытаний. В нашем случае это аппаратный сервер с Windows 2019 и установленными ролями 1С и SQL.
- Выполняется по 3 теста APDEX с числом пользователей 50 и 100 на MSSQL и PostgreSQL.
- Производим расчет абсолютной погрешности.
- Стенд определения значений погрешности.
В состав стенда входит аппаратный сервер Windows с установленными ролями SQL и 1С:
- Сервер СУБД и 1С располагается на одном аппаратном сервере, Shared memory активирован.
- Проводится замер 3х тестов APDEX с числом пользователей 50 и 100 на MSSQL.
- Проводится замер 3х тестов APDEX с числом пользователей 50 и 100 на Postgres SQL.
- Основной тестовый стенд Windows.
В состав стенда входит виртуальный сервер с установленными ролями SQL(Windows) и виртуальный сервер с ролью 1С (Windows).
- Проводится замер 1 теста APDEX с числом пользователей 50 и 100 на MSSQL.
- Проводится замер 1 теста APDEX с числом пользователей 50 и 100 на Postgres SQL.
- Основной тестовый стенд Windows + Linux.
В состав стенда входит виртуальный сервер с установленными ролями SQL (Linux) и виртуальный сервер с ролью 1С на базе Windows.
- Используются две виртуальных машины. Одна содержит роль Application сервера 1С на Windows, другая роль сервера баз данных LINUX.
- Проводится замер 1 теста APDEX с числом пользователей 50 и 100 на MSSQL.
- Проводится замер 1 теста APDEX с числом пользователей 50 и 100 на Postgres SQL.
- Тест 1C: КИП (АПДЕКС).
В основе методики АПДЕКС лежит набор инструментов 1С КИП. В данном случае использовался не весь функционал методологии. В процессе конфигурации теста была выполнена доработка базы клиентов под тестирование, выделены ключевые операции пользователей, такие как проведение поступления, реализации и т.д.
Число пользователей закрепили на уровне 50 и 100.
Стандартная методология АПДЕКС использует прогрессивную шкалу от 0 до 1, где 1 — это замечательный результат, а 0 – неудовлетворительный. Требуется указать целевое значение параметра производительности той или иной операции, создать сценарии и запустить тест.
Мы же в своем исследовании не используем целевые показатели среднего времени выполнения операции.
- В режиме виртуализации выделяемые ресурсы распределены:
- Application серверы 1С — 14 ядер и 100 ГБ ОЗУ,
- SQL сервер — 16 ядер и 100 ГБ ОЗУ,
- при этом аппаратный сервер использовал все 32 ядра и 384 ГБ ОЗУ. Данная особенность никак не влияет на результаты тестирования.
Аппаратный сервер Windows. Настройки BIOS и ОС.
Перед работой с носителем были произведены настройки биоса. В данном случае необходимо было вручную выставить режим “Maximum Perfomance” в расширенных настройках CPU. Данные настройки применены для всех участников тестирования.
- Power Technology — Custom
- Power Perfomance Tuning — здесь нужно выбрать: или управлять питанием будет BIOS или ОС. Наш опыт с Hyper-V говорит о выборе в сторону OS control.
- Energy_perf_bias_cfg mode — Maximum Performance.
- Настройки электропитания ОС — Производительность.
Результатом наших манипуляций является фиксированная в режиме турбо-буст частота процессора.
Примечания:
- На платформе Supermicro X11DPi-N BIOS V3.5 удалось зафиксировать стабильную частоту на уровне 4.2 ГГц, не используя T P и C State прерывания. Достаточно было выставить пункт Power Technology — Performance.
Конфигурация баз данных
Microsoft SQL 2019
- Базовая настройка и установка описана в нашей инструкции.
- Степень параллелизма — 1.
- В случае, если производительности SSD-массива не хватает для корректной работы БД, выносим Temp DB на отдельный физический массив. Оценить загрузку массива можно счетчиком «очередь диска» в системе мониторинга Windows.
- Новая база данных создается из копии базы model. Все настройки, указанные в model, будут в новой базе данных. Параметры Model меняем на следующие:
- Начальный размер файла данных — от 1 ГБ до 10 ГБ.
- Начальный размер журнала транзакций — от 1 ГБ до 2 ГБ.
- Прирост файлов — 512 МБ.
- Активируем Shared memory при условии, что SQL и 1С находятся на одном сервере.
PostgreSQL 12.7
Данная БД требует более тонкой настройки, нежели продукт Microsoft. В случае, если эту настройку не провести, а использовать продукт из «коробки», падение производительности существенное.
Все параметры находятся в файле postgesql.conf. Основные параметры нашего postgesql.conf:
max_connections = 200 shared_buffers = 25GB effective_cache_size = 75GB maintenance_work_mem = 2047MB effective_io_concurrency = 1000 (только в LINUX,использовать осторожно, максимальное значение 1000 может дать чрезмерную нагрузку на дисковую подсистему) checkpoint_completion_target = 0.9 wal_buffers = 16MB default_statistics_target = 500 max_files_per_process = 1000 random_page_cost = 1.1 work_mem = 1512MB min_wal_size = 4GB max_wal_size = 16GB max_worker_processes = 16 max_parallel_workers_per_gather = 8 max_parallel_workers = 16 max_parallel_maintenance_workers = 4 max_locks_per_transaction = 128 online_analyze.table_type = 'temporary' online_analyze.verbose = 'off' plantuner.fix_empty_table = 'on' seq_page_cost = 0.5 (использовать осторожно, может снизить производительность) random_page_cost = 0.5 (использовать осторожно, может снизить производительность)
Примечание:
Данные настройки подходят исключительно для нашего сценария работы. Все параметры подбираются индивидуально к каждой базе.
Сводные таблицы. Тест Гилева (больше – быстрее)
Таблица 1. Результаты теста Гилева. Отклонения от эталонного показателя.
Сводные таблицы. Среднее время выполнения операций в секундах
Для теста использовались следующие параметры исследования:
- Внеоборотные активы. формирование заданий к закрытию месяца
- Внеоборотные активы. формирование заданий к закрытию месяца. удельный
- Общее время запуска приложения
- ТЦ_Проведение возврат товаров от покупателя
- ТЦ_Проведение платежных поручений
- ТЦ_Проведение ПТИУ
- ТЦ_Проведение реализации товаров и услуг
- ТЦ_Проведение счет на оплату
Общее число замеров APDEX для 50 пользователей — 3 380.
Общее число замеров APDEX для 100 пользователей — 6 700.
Таблица 2. Общая таблица значений среднего времени выполнения операций в секундах
Выводы
- Продукция Microsoft ожидаемо показало лучшую производительность как на аппаратной платформе, так и в среде виртуализации.
- В режиме 100 пользователей производительность аппаратной базы данных Postgres сравнялось по производительности с виртуальной MSSQL.
Наше исследование показало, что PostgreSQL является работоспособной альтернативой Microsoft SQL.
В режиме виртуализации при сравнении с ОС Windows, PostgreSQL выполнял операции медленнее до 11 процентов, что является достойным результатом при условии, что продукт бесплатен.
Что же выбрать: MSSQL или PostgreSQL?
- Для компаний с большим числом пользователей экономически обоснованно использовать PostgreSQL ввиду отсутствия трат на лицензии. Для решения задач по поддержке и оптимизации кода под данную БД требуется квалифицированный персонал, как со стороны 1С, так и со стороны администрирования базы данных. Как следствие, такой персонал будет стоить дороже, а найти его сложнее.
- В случае использования системы 1С с относительно малом числом пользователей, рекомендуется использовать MSSQL. Необходимо выполнить закупку лицензий под систему, требования к специалистам по поддержке ниже, отдельной оптимизации производительности по БД не потребуется.
