Анализ производительности 1С на Postgres Pro (2023)

Состав тестового стенда

Аппаратная часть

1. Supermicro X11DPL‑i*
2. 2 x Intel Xeon X 5690 3,4 GHz, each 6 Core **
3. ОЗУ 128 ГБ DDR3
4. Хранилище RAID 1, Intel DC S3710 SSDSC2BA400G401 400 ГБ

*Исследование проводим на проверенной временем аппаратной платформе Supermicro от 2011 года.

**При применении платформы Intel Gold в сочетании с высокоскоростными дисками большинство анализируемых параметров укладывалось в пределы погрешности. Не получилось создать такую нагрузку, которая позволила бы обнаружить тенденцию к значительному изменению показателей.

Программная часть

1. Платформа 1С:Предприятие 8.3.22.1750
2. Конфигурации: 1С:ERP Управление предприятием 2. Демо база. Тест “Полный” на 33 пользователя. Редакция 2.5.8.179. Объем базы 4.2 ГБ
3. Сервер приложений 1С: ОС Windows Server 2019 Standard
4. Сервер базы данных: ОС Debian 11.5, Postgres pro Standart 13.9

Примечание: В процессе тестирования мы применяем стандартный шаблон от компании 1С – полный, на 33 пользователя. Очевидно, используемое оборудование способно справиться и с большим числом тестируемых. Наша задача — выявить тенденцию, а не создать высокую нагрузку на оборудование.

Общая методика тестирования

В рамках данной статьи мы применяем методику анализа используя абсолютные значения погрешности.

1. Описание методики определения абсолютной погрешности:
1. Определяем идеальные условия испытаний. В нашем случае это два виртуальных сервера с ролью Application сервера 1С на Windows, и сервера баз данных с подготовленной конфигурацией
2. Выполняем по 3 теста APDEX с числом пользователей 33 на PostgreSQL
3. Производим расчет абсолютной погрешности по формуле:


Рисунок 1 — Формула расчета абсолютной погрешности

2. Основной этап тестирования:
1. Проводим замер целевых значений. Проводится 3 замера теста “Полный” в конфигурации ERP
2. Проводим серию основных испытаний (повторяем со всеми исследуемыми значениями). Проводится уменьшение первого исследуемого значения на 100%. Проводим увеличение первого исследуемого значения на 100%.
3. Значения в положении onoff активируем или деактивируем соответственно (например, компоненты параллелизма)


3. Тест 1С:КИП (Апдекс)

Методика АПДЕКС базируется на комплекте инструментов 1С:КИП. В данном случае был задействован полный функционал данной методологии. Использовалась типовая демонстрационная база 1С:ERP с официального сайта 1С.

Стандартный подход АПДЕКС предполагает использование прогрессивной шкалы от 0 до 1, где 1 символизирует отличный результат, а 0 – неудовлетворительный. Необходимо задать целевое значение параметра производительности для определенной операции, разработать сценарии и провести тестирование.

Подготовка тестового стенда

Проводим установку и базовую настройку носителя виртуальных машин и операционных систем.

Носитель виртуальных машин

Перед началом работы с носителем были выполнены настройки BIOS. В данной ситуации требовалось вручную установить режим “Maximum Performance” в расширенных настройках процессора. Эти настройки были применены для всех участников тестирования.

1. Power Technology. Ставим Custom
2. Power Performance Tuning. Здесь нужно выбрать: или управлять питанием будет BIOS или ОС. Наш опыт с Hyper-v говорит о выборе в сторону OS control
3. Energy_perf_bias_cfg mode. Ставим Maximum Performance
4. Настройки электропитания ОС. Ставим производительность

Результатом наших манипуляций является фиксированная в режиме turbo-boost частота процессора (в нашем случае это 3,46 ГГц).

Операционные системы и приложения

Application сервер 1С:

1. Установлена ОС Windows Server 2019 Standard
2. Установлен 1С сервер
3. Режим электропитания – максимальная производительность

Носитель виртуальных машин:

1. Установлена ОС Windows Server 2019 Standard
2. Режим электропитания – максимальная производительность

SQL Server:

1. Установлена ОС Debian 11.5
2. Установлен Postgres Pro 13.9

Выделяем ресурсы под виртуальные машины:

1. Application сервер 1С – 12 ядер ЦП и 40 ГБ ОЗУ
2. SQL сервер – 10 ядер ЦП и 30 ГБ ОЗУ (параметры конфигурации рассчитываем исходя из 20 ГБ ОЗУ для того, чтобы был запас по росту)

Производим проверку дисковой подсистемы Crystal Disk Mark. Настройки стандартные. Тест файлом 32ГБ

Рисунок 2 — Результат теста Crystal Disk Mark

Настройка 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             

Выполняем их, не забывая:

1. Перед этим сменить локаль на ru_RU.utf8
2. Задать пароль учетке 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. Тест 1,2,3 – определение погрешности стоковых значений
2. Тест 4 – random_page_cost = 4.0
3. Тест 5 – effective_io_concurrency = 400
4. Тест 6 – shared_buffers = 2500MB
5. Тест 7 – shared_buffers = 10000MB
6. Тест 8 (комплексные значения):
1. max_parallel_workers_per_gather = 4
2. max_parallel_maintenance_workers = 3 # Количество CPU/4, минимум 2, максимум 6
3. max_worker_processes = 10
4. max_parallel_workers = 10

Пройдемся кратко по основным значениям:

1. shared_buffers = 5GB # 25% of RAM. Задаёт объём памяти, который будет использовать сервер баз данных для буферов в разделяемой памяти. Согласно рекомендации команды Postgres pro, рекомендуемое значение: 25% от ОЗУ сервера SQL.
2. temp_buffers = 128MB. Задает максимальный объем памяти, выделяемой для временных буферов в каждом сеансе. Эти, существующие только в рамках сеанса буферы, используются исключительно для работы с временными таблицами.
3. work_mem = 256MB. Задает базовый максимальный объём памяти, который будет использоваться во внутренних операциях при обработке запросов (например, для сортировки или хеш-таблиц), прежде чем будут задействованы временные файлы на диске.
4. maintenance_work_mem = 256MB. Задает максимальный объем памяти для операций обслуживания БД, в частности VACUUM, CREATE INDEX и ALTER TABLE ADD FOREIGN KEY.
5. max_parallel_workers_per_gather = 0. Количество воркеров, которые запускаются на узел. Это основополагающая настройка, если вы ее выставите в ноль, параллелизм не будет отрабатывать, будет работать один процесс, один оператор. Когда оптимизатор запросов принимает решение, что для запроса нужно применять параллелизм, он смотрит на этот параметр и определяет, сколько ему нужно воркеров, чтобы выполнить этот оператор запроса.
6. max_parallel_maintenance_workers = 3 # Количество CPU/4, минимум 2, максимум 6. Задаёт максимальное число рабочих процессов, которые могут запускаться одной служебной командой.
7. max_wal_size = 16GB и min_wal_size = 4GB. Минимальный и максимальный размер файлов журнала предзаписи.
8. effective_cache_size = 15000MB # 75% of RAM. Этот параметр влияет на планировщик запросов, а не ограничивает дисковый кэш. Чем выше, тем больше вероятность, что будет применяться сканирование по индексу. Чем ниже, тем более вероятно, что будет выбрано последовательное сканирование.
9. random_page_cost = 1.0. Задает приблизительную стоимость чтения одной произвольной страницы с диска. Значение по умолчанию равно 4.0. С хранилищем, у которого стоимость произвольного чтения ненамного выше последовательного, как, например, у твердотельных накопителей, лучше выбрать меньшее значение random_page_cost. Параметр наиболее эффективен, при условии что база полностью помещается в ОЗУ. Сервер SQL не знает какая у нас дисковая подсистема и какое время Seek Time, потому данный параметр необходимо задать вручную в среде Linux.
10. effective_io_concurrency = 200. Задаёт допустимое число параллельных операций ввода/вывода, которое говорит PostgreSQL о том, сколько операций ввода/вывода могут быть выполнены одновременно. Чем больше это число, тем больше операций ввода/вывода будет пытаться выполнить параллельно PostgreSQL в отдельном сеансе. Диски SSD и другие виды хранилища в памяти часто могут обрабатывать множество параллельных запросов, так что оптимальным числом может быть несколько сотен.

Результаты тестирования

Таблица 1. Таблица определения погрешностей

Ниже сводная таблица с результатами:

Таблица 2. Результаты тестирования

Оценка результатов

1. random_page_cost = 4.0. Ожидаемо ухудшение показателей. Значение 4 – для HDD дисков.
2. effective_io_concurrency = 400. Согласно общей рекомендации 1С, а также документации с сайта разработчика, увеличение данного параметра должно было позитивно отразиться на производительности дисковой системы, на деле это не так. Изменение данного параметра проводить с осторожностью.
3. shared_buffers = 2500 shared_buffers = 10000. Не стоит выставлять слишком высокие, а так же слишком низкие значения данного показателя. Согласно общей рекомендации 1С, значения 25% от общего объема ОЗУ – достаточно для работы.
4. max_parallel_workers_per_gather = 4. При использовании типовых конфигурации, активация данной настройки пользы не несет. Используется другой механизм, данное замечание разберем в наших следующих материалах. Рекомендуемое значение – 0.
5. work_mem = 128MB work_mem = 512MB. Изменение данных показателей практической ценности не несет.

При изменении параметров наблюдается общая тенденция к ухудшению показателей. Это указывает на то, что изначально были выбраны правильные настройки конфигурации для данной базы. Такой результат также подчеркивает важность применения изменений в файле конфигурации только с пониманием физики процесса. Если опыта недостаточно, мы советуем изменять только параметр random page cost, оставив все остальные настройки по умолчанию.