Прошлый 2022 год заставил много компаний пересмотреть свои предпочтения в выборе программного обеспечения. Все чаще встречаются кейсы, когда для работы 1С используется СУБД PostgreSQL, а вместо Windows Server используется Linux ОС.
Целью данной статьи является изучение в 2023 году производительности системы 1С в среде Hyper-V (ОС Windows Server 2019) во взаимодействии с сервером СУБД PostgreSQL Standart 13.9 (ОС Debian 11.5) от команды PostgresPro. В материале мы описываем исследование зависимости параметров конфигурационного файла, результаты замеров производительности при изменении данных параметров.
Состав тестового стенда
Аппаратная часть
Supermicro X11DPL‑i*
2 x Intel Xeon X 5690 3,4 GHz, each 6 Core **
ОЗУ 128 ГБ DDR3
Хранилище RAID 1, Intel DC S3710 SSDSC2BA400G401 400 ГБ
*Исследование проводим на проверенной временем аппаратной платформе Supermicro от 2011 года.
**При использовании платформы Intel Gold в связке с скоростными дисками, большинство исследуемых параметров осталось в рамках погрешности. Не удалось сгенерировать нагрузку, чтобы заметить тенденцию к существенному изменению показателей.
Программная часть
Платформа 1С:Предприятие 8.3.22.1750.
Конфигурации: 1С:ERP Управление предприятием 2. Демо база. Тест "Полный" на 33 пользователя. Редакция 2.5.8.179. Объем базы 4.2 ГБ.
Сервер приложений 1С: ОС Windows Server 2019 Standard.
Сервер базы данных: ОС Debian 11.5, Postgres pro Standart 13.9.
Примечание: В рамках тестирования мы используем стандартный шаблон от фирмы 1С – полный, 33 пользователя. Безусловно, используемое железо сможет вытянуть и больше испытуемых. Наша цель отследить тенденцию, а не нагрузить железо.
Общая методика тестирования
В рамках данной статьи мы применяем методику анализа используя абсолютные значения погрешности:
Описание методики определения абсолютной погрешности:
Определяем идеальные условия испытаний. В нашем случае это два виртуальных сервера с ролью Application сервера 1С на Windows, и сервера баз данных с подготовленной конфигурацией.
Выполняем по 3 теста APDEX с числом пользователей 33 на PostgreSQL.
Производим расчет абсолютной погрешности по формуле:
Формула расчета абсолютной погрешности
Основной этап тестирования:
Проводим замер целевых значений. Проводится 3 замера теста “Полный” в конфигурации ERP.
Проводим серию основных испытаний (повторяем со всеми исследуемыми значениями). Проводится уменьшение первого исследуемого значения на 100%.
Проводим увеличение первого исследуемого значения на 100%.Значения в положении on\off активируем или деактивируем соответственно (например, компоненты параллелизма).
Тест 1С:КИП (Апдекс)
В основе методики АПДЕКС лежит набор инструментов 1С:КИП. В данном случае, использовался весь функционал методологии. Использовалась стандартная демонстрационная база 1С:ERP с сайта 1С.
Стандартная методология АПДЕКС использует прогрессивную шкалу от 0 до 1, где 1 – это замечательный результат, а 0 – неудовлетворительный. Требуется указать целевое значение параметра производительности той или иной операции, создать сценарии и запустить тест.
Подготовка тестового стенда
Проводим установку и базовую настройку носителя виртуальных машин и операционных систем.
Носитель виртуальных машин
Перед работой с носителем были произведены твики биоса. В данном случае необходимо было вручную выставить режим “Maximum Perfomance” в расширенных настройках CPU. Данные настройки применены для всех участников тестирования
Power Technology. Ставим Custom.
Power Performance Tuning. Здесь нужно выбрать: или управлять питанием будет BIOS или ОС. Наш опыт с Hyper-v говорит о выборе в сторону OS control.
Energy_perf_bias_cfg mode. Ставим Maximum Performance.
Настройки электропитания ОС. Ставим производительность.
Результатом наших манипуляций является фиксированная в режиме turbo-boost частота процессора (в нашем случае это 3,46 ГГц ).
Операционные системы и приложения
Application сервер 1С:
Установлена ОС Windows Server 2019 Standard.
Установлен 1С сервер.
Режим электропитания - максимальная производительность.
Носитель виртуальных машин:
Установлена ОС Windows Server 2019 Standard.
Режим электропитания - максимальная производительность.
SQL Server:
Установлена ОС Debian 11.5.
Установлен Postgres Pro 13.9.
Выделяем ресурсы под виртуальные машины:
Application сервер 1С – 12 ядер ЦП и 40 ГБ ОЗУ.
SQL сервер – 10 ядер ЦП и 30 ГБ ОЗУ (параметры конфигурации рассчитываем исходя из 20 ГБ ОЗУ для того, чтобы был запас по росту).
Производим проверку дисковой подсистемы Crystal Disk Mark. Настройки стандартные. Тест файлом 32ГБ:
Настройка Postgres
Подготовка исходного конфига
После оформления заявки на сайте https://1c.postgres.ru/ на нашу почту приходит письмо с командами:
wget https://repo.postgrespro.ru/1c-13/keys/pgpro-repo-add.sh
sh pgpro-repo-add.shЕсли продукт единственный Postgres на вашей машине и вы хотите сразу получить готовую к употреблению базу:
apt-get install postgrespro-1c-13Выполняем их, не забывая:
Перед этим сменить локаль на ru_RU.utf8
Задать пароль учетке Postgres.
Проводим анализ файла postgresql.conf, находящегося по адресу: /var/lib/pgpro/1c-13/data
Большинство строк в нем закомментированы. Часть настроек изменяется при установке и зависит от числа ядер и ОЗУ выделенных на ВМ, это одно из преимуществ продукта.
shared_buffers = 5000MB # 25% of RAM
temp_buffers = 128MB
work_mem = 256MB
maintenance_work_mem = 256MB
max_files_per_process = 10000
max_parallel_workers_per_gather = 0
max_parallel_maintenance_workers = 3 # Количество CPU/4, минимум 2, максимум 6
commit_delay = 1000
max_wal_size = 4GB
min_wal_size = 2GB
checkpoint_timeout = 15min
effective_cache_size = 15000MB # 75% of RAM
from_collapse_limit = 8
join_collapse_limit = 8
autovacuum_max_workers = 6 # Количество CPU/2, минимум 2
vacuum_cost_limit = 600 # 100* autovacuum_max_workers
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.005
max_locks_per_transaction = 256
escape_string_warning = off
standard_conforming_strings = off
shared_preload_libraries = 'online_analyze, plantuner'
online_analyze.threshold = 50
online_analyze.scale_factor = 0.1
online_analyze.enable = on
online_analyze.verbose = off
online_analyze.min_interval = 10000
online_analyze.table_type = 'temporary'
plantuner.fix_empty_table = on
random_page_cost = 1.0
effective_io_concurrency = 1Это и будет наш основной эталонный конфиг для старта тестов.
Исследуемые элементы и этапы тестирования:
Тест 1,2,3 – определение погрешности стоковых значений
Тест 4 – random_page_cost = 4.0
Тест 5 – effective_io_concurrency = 400
Тест 6 – shared_buffers = 2500MB
Тест 7 – shared_buffers = 10000MB
Тест 8 (комплексные значения):
max_parallel_workers_per_gather = 4
max_parallel_maintenance_workers = 3 # Количество CPU/4, минимум 2, максимум 6
max_worker_processes = 10
max_parallel_workers = 10
Пройдемся кратко по основным значениям:
shared_buffers = 5GB # 25% of RAM
Задаёт объём памяти, который будет использовать сервер баз данных для буферов в разделяемой памяти. Согласно рекомендации команды Postgres pro, рекомендуемое значение: 25% от ОЗУ сервера SQL.
temp_buffers = 128MB
Задает максимальный объем памяти, выделяемой для временных буферов в каждом сеансе. Эти, существующие только в рамках сеанса буферы, используются исключительно для работы с временными таблицами.
work_mem = 256MB
Задает базовый максимальный объём памяти, который будет использоваться во внутренних операциях при обработке запросов (например, для сортировки или хеш-таблиц), прежде чем будут задействованы временные файлы на диске.
maintenance_work_mem = 256MB
Задает максимальный объем памяти для операций обслуживания БД, в частности VACUUM, CREATE INDEX и ALTER TABLE ADD FOREIGN KEY.
max_parallel_workers_per_gather = 0
Количество воркеров, которые запускаются на узел. Это основополагающая настройка, если вы ее выставите в ноль, параллелизм не будет отрабатывать, будет работать один процесс, один оператор. Когда оптимизатор запросов принимает решение, что для запроса нужно применять параллелизм, он смотрит на этот параметр и определяет, сколько ему нужно воркеров, чтобы выполнить этот оператор запроса.
max_parallel_maintenance_workers = 3 # Количество CPU/4, минимум 2, максимум 6
Задаёт максимальное число рабочих процессов, которые могут запускаться одной служебной командой.
max_wal_size = 16GB и min_wal_size = 4GB
Минимальный и максимальный размер файлов журнала предзаписи.
effective_cache_size = 15000MB # 75% of RAM
Этот параметр влияет на планировщик запросов, а не ограничивает дисковый кэш. Чем выше, тем больше вероятность, что будет применяться сканирование по индексу. Чем ниже, тем более вероятно, что будет выбрано последовательное сканирование.
random_page_cost = 1.0
Задает приблизительную стоимость чтения одной произвольной страницы с диска. Значение по умолчанию равно 4.0. С хранилищем, у которого стоимость произвольного чтения ненамного выше последовательного, как, например, у твердотельных накопителей, лучше выбрать меньшее значение random_page_cost. Параметр наиболее эффективен, при условии что база полностью помещается в ОЗУ. Сервер SQL не знает какая у нас дисковая подсистема и какое время Seek Time, потому данный параметр необходимо задать вручную в среде Linux. В Windows параметр проставляется автоматически:
4.0 – для HDD;
1.5-2.0 – для RAID из HDD;
1.1 – 1.5 – для SSD;
0.1 – 1.0 – для NVMe.
effective_io_concurrency = 200
Задаёт допустимое число параллельных операций ввода/вывода, которое говорит PostgreSQL о том, сколько операций ввода/вывода могут быть выполнены одновременно. Чем больше это число, тем больше операций ввода/вывода будет пытаться выполнить параллельно PostgreSQL в отдельном сеансе. Диски SSD и другие виды хранилища в памяти часто могут обрабатывать множество параллельных запросов, так что оптимальным числом может быть несколько сотен.
Результаты тестирования
Таблица определения погрешностей:
Название параметров | Значение Апдекс | Среднее значение Апдекс | Относительная погрешность Апдекс | Абсолютная погрешность Апдекс |
Тест определения погрешности 1 | 0,816 | 0,81 | 0,01 | 0,65% |
Тест определения погрешности 2 | 0,805 | |||
Тест определения погрешности 3 | 0,808 |
Таблица результатов тестирования:
Название параметров | Стандартное значение параметров | Измененное значение параметров | Апдекс | Абсолютная разница со средним значением |
random_page_cost | 1.0 | 4.0 | 0,791 | 3,35% |
effective_io_concurrency | 1 | 400 | 0,783 | 3,20% |
shared_buffers | 5000MB | 2500 | 0,797 | 1,50% |
10000 | 0,807 | в пределах погрешности | ||
max_parallel_workers_per_gather | 0 | 4 | 0,808 | в пределах погрешности |
work_mem | 256MB | 128MB | 0,806 | в пределах погрешности |
512MB | 0,798 | 1,50% |
Оценка результатов
random_page_cost = 4.0
Ожидаемо ухудшение показателей. Значение 4 – для HDD дисков.
effective_io_concurrency = 400
Согласно общей рекомендации 1С, а также документации с сайта разработчика, увеличение данного параметра должно было позитивно отразиться на производительности дисковой системы, на деле это не так. Изменение данного параметра проводить с осторожностью.
shared_buffers = 2500 shared_buffers = 10000
Не стоит выставлять слишком высокие, а так же слишком низкие значения данного показателя. Согласно общей рекомендации 1С, значения 25% от общего объема ОЗУ – достаточно для работы.
max_parallel_workers_per_gather = 4
При использовании типовых конфигурации, активация данной настройки пользы не несет. Используется другой механизм, данное замечание разберем в наших следующих материалах. Рекомендуемое значение – 0.
work_mem = 128MB work_mem = 512MB
Изменение данных показателей практической ценности не несет.
При изменении показателей общая тенденция на ухудшение. Это означает, что изначально были выбраны корректные настройки конфигурации для конкретной базы. Также это говорит о том, что все изменения файла конфигурации необходимо применять исключительно со знанием физики процесса. В случае, если опыта не хватает, мы рекомендуем изменять только один параметр random page cost, а все остальные оставлять по умолчанию.
Выводы
2023 год продолжит тенденцию к импортозамещению. Уже сейчас можно сказать, что Postgres Pro можно использовать в продакшн среде. Данный продукт есть в реестре продуктов импортозамещения.
К основным плюсам продукта можно отнести:
единственное на текущий момент коммерческое решение с полноценной поддержкой.
практически полностью автоматическая настройка конфигурации под ваше железо/ВМ.
Минусы:
высокий порог входа в Linux, и, как следствие, увеличение требований к персоналу и затратам.
В ближайшей перспективе мы ожидаем роста конкурентоспособности отечественных решений на рынке и постепенный отказ от продуктов Microsoft.
