ver. 1.4 from 22.07.24

Установка настроек по умолчанию для 1С.

1. Заходим в платформу Tantor, выбираем наш инстанс, где расположены базы 1С.

2. Слева в меню выбираем пункт «monitoring config»:

3. В списке баз выделяем базу 1С, нажимаем на «Save»:

4. После этого агент идет в БД и пытается найти специфичные таблицы под 1С, и если находит, то шлет в платформу сообщение, что это 1С. Конфигурация настроек под 1с автоматически загрузится в тантор в качестве рекомендуемых.

5. Через несколько минут заходим на вкладку «Configurations» и проверяем, что выбранный профиль равен erp1c:

6. Теперь в колонке «CHANGE CURRENT VALUE TO RECOMMENDED» платформа предоставляет те значения, которые она рекомендует для профиля erp1c. Применять или не применять рекомендуемые значения вы должны определить сами. Ниже мы опишем основные настройки, которые влияют на работу 1С.

Параметры Tantor

Дополнительные модули (расширения)

При создании базы платформа 1С автоматически подключит к базе следующие расширения, необходимые для совместимости с 1С:

1. fasttrun
2. fulleq
3. mchar

Делает это платформа следующими запросами согласно логов технологического журнала 1С:

37:16.686000-1999,DBPOSTGRS,3,Sql="select installed_version from pg_available_extensions where name = 'mchar'"
37:16.686002-1,DBPOSTGRS,3,Sql=alter extension mchar update
37:16.687000-997,DBPOSTGRS,3,Sql="select installed_version from pg_available_extensions where name = 'fasttrun'"
37:16.688000-999,DBPOSTGRS,3,Sql=alter extension fasttrun update
37:16.689000-999,DBPOSTGRS,3,Sql="select installed_version from pg_available_extensions where name = 'fulleq'"
37:16.689002-1,DBPOSTGRS,3,Sql=alter extension fulleq update

Посмотреть установленные расширения можно следующим запросом: 

SELECT * FROM pg_extension

Соединения и аутентификация (Connections and Authentication)

Настройки WAL (Write-Ahead Log)

Для высоконагруженных систем рекомендуем выносить журнал транзакций на отдельный диск. Это может даст прирост производительности особенно для oltp характера нагрузки. 

Использование ресурсов (Resource usage)

Настройка запросов (Query Tuning)

Автовакуум (Autovacuum)

Индивидуальные опции (Customized Options)

auto_explain

Данный модуль вместе с платформой Tantor позволит в удобном виде получать планы проблемных запросов. Подробнее об этой возможности можно узнать по следующим ссылкам:

• Раздел Advanced analytics в платформе Tantor - https://tantorlabs.ru/page39398236.html
• Лекции по работе с планами запросов модуля - https://www.youtube.com/playlist?list=PLt0vzWoDuwcRWoeVHeJuDhnXRnjiMMTOF

Включать данный модуль мы рекомендуем только в том случае, если у вас развита практика оптимизации проблемных запросов и на это выделяются ресурсы разработчиков или экспертов 1С. В ином случае собирать эти статистические данные смысла нет и включать данный модуль не нужно.

Более подробно включение модуля Advanced analytics рассмотрено здесь.

online_analyze

Данный модуль активно применялся в 1С до версии платформы 8.3.13 для моментального обновления статистики при создании временной таблицы. Начиная с 8.3.13 платформа сама выполняет команду ANALYZE для созданной временной таблицы (если она содержит хотя бы одну запись) и смысла включать этот плагин с table_type = temporary нет.

Но если включите, ты после создания временной таблицы команда ANALYZE выполняться будет все равно 1 раз (проверено по логам postgres), поэтому на производительность в худшую сторону это не повлияет.

Прочие

Совместимость с версиями и платформами (Version and Platform Compatibility)

Значения по умолчанию для клиентского подключения (Client Connection Defaults)

Управление блокировками (Lock Management)

Регламентное обслуживание

Настройка регламентных операций

Для оптимизации операций autovacuum на рабочих серверах рекомендуется настроить следующие регламентные операции СУБД:

•  /opt/tantor/db/15/bin/vacuumdb -h 127.0.0.1 -p 5432 -U postgres -a -Z -j 4 - Analyze only - всех баз в 4 потока (количество потоков можно увеличить до 8 в зависимости от количества ядер и скорости дисковой подсистемы) - Ежедневно
•  /opt/tantor/db/15/bin/vacuumdb -h 127.0.0.1 -p 5432 -U postgres -a -z -F -j 2 - Vacuum + Analyze + Freeze всех баз в 2 потока (количество потоков можно увеличить до 4-8 в зависимости от количества ядер и скорости дисковой подсистемы) - Еженедельно

Эти операции можно настроить интерактивно с помощью платформы Tantor следующим образом:

1. Переходим в модуль "Задачи" и добавляем новую Задачу

2. Заполняем задачу по примеру как на изображении:

В разделе "Интервал между запусками" ставим 1 в поле "Дни" - это означает, что задача будет выполняться каждый день.

3. После создания задачи кликаем на нее и провалимся в раздел "Действия", в котором добавляем новое действие - выбираем "Системная команда"

4. Заполняем команду по примеру как на изображении:

5. Нажимаем "Сохранить" - на этом ежедневное регламентное обслуживание настроено.

6. По аналогии создаем задачу и команду для еженедельного регламентного обслуживания

Самостоятельное обслуживание таблиц

В случае удаления значимого объёма данных из базы (более 20%) имеет смысл выполнить vacuum full таблицы, из которой были удалены данные. Vacuum full требует монопольного доступа и блокировки базы 1С.

Выполнить данное обслуживание можно из платформы Tantor из раздела Maintenance:

Для того, чтобы выполнять обслуживание без монопольного доступа к таблицам можно использовать следующие утилиты, которые идут в сборке СУБД Tantor SE 1C:

pg_repack

pgcompacttable

Настройки ОС

Сетевой адаптер

Для максимальной производительности рекомендуется сетевой трафик между СП и СУБД вывести на отдельный адаптер, чтобы он не ходил по общей сети.

То, что есть задержки по сети, можно определить следующим способом: выполнить простейший запрос время выполнения которого, например, 0.01 сек. При выполнении собирать технологический журнал (событие DBPOSTGRS) и трассировку СУБД, затем сравнить время выполнения запросов по данным этих логов. Если время выполнения одного запроса по данным технологического журнала 1С будет на порядок больше чем по данным логов СУБД, то проблема есть. При правильно настроенном сетевом взаимодействии между СП и СУБД разница выполнения будет несколько миллисекунд.

Временные таблицы

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

Поэтому рекомендуем выносить каталог с временными таблицами либо на отдельный диск либо в RAM. Вынос в RAM имеет свои нюансы.

Вынос в RAM для Astralinux:

Создаем директорию, в котором будут хранится файлы временных таблиц и даем права пользователю postgres:

mkdir /mnt/dbtemp
chmod 700 /mnt/dbtemp
chown postgres:postgres /mnt/dbtemp

Создаем табличное пространство:

CREATE TABLESPACE temp LOCATION '/mnt/dbtemp';

В результате внутри директории /mnt/dbtemp будет создан каталог вида PG_15_202209061. Внутри него для каждой базы будет создаваться свой каталог с именем равным oid'у базы. Чтобы каталог базы появился необходимо в базе создать временную таблицу.

Узнать oid базы можно следующим скриптом:

SELECT oid from pg_database

В RAM можно вынести как целиком каталог PG_15_202209061, так и каталог конкретной базы.

Рассмотрим вынос каталога временных таблиц конкретной базы, в нашем примере для нее был создан каталог 16439. Добавим в файл /etc/fstab следующую строку:

tmpfs /mnt/dbtemp/PG_15_202209061/16439 tmpfs rw,nodev,nosuid,noatime,nodiratime,size=1G 0 0

Выделили под него 1 Гб. Монтируем RAM-диск:

mount /mnt/dbtemp/PG_15_202209061/16439 

Меняем параметр temp_tablespaces в postgresql.conf:

temp_tablespaces = 'temp'

И перечитываем настройки постгреса:

SELECT pg_reload_conf();

Каталог pg_stat_tmp

Данная рекомендация актуальна для PostgreSQL ниже 15й версии. В 15 версии PostgreSQL архитектура сбора статистики была основательно переработана. Теперь нет процесса для сбора статистики, ее генерируют серверные процессы PostgreSQL самостоятельно и обмениваются ей в оперативной памяти.

В обязательном порядке необходимо вынести каталог pg_stat_tmp в RAM-диск. Этот каталог очень агрессивно используется PostgreSQL и при этом при выключении его содержимое копируется в каталог pg_tmp. Размер каталога рассчитывается примерно как work_mem*2 на 1 БД. 

Для CentOS и Astralinux: 

Для начала создадим директорию:

mkdir /home/data/pg_stat_tmp
chown postgres:postgres /home/data/pg_stat_tmp

в файле /etc/fstab добавить строку:

tmpfs /home/data/pg_stat_tmp tmpfs noatime,nodiratime,defaults,size=512M

сохранить файл и далее выполнить:

mount -a
reboot

Меняем параметр в postgresql.conf:

stats_temp_directory = '/home/data/pg_stat_tmp'

Перезапускаем СУБД:

systemctl restart tantor-se-1c-server-14

Transparent Huge Pages

Согласно бенчмаркам THP на 10% ускоряют абстрактное приложение, но на деле всё по другому. В некоторых случаях THP вызывает ничем не мотивированное увеличение потребления CPU в системе, поэтому рекомендуем выключать их.

Для CentOS: 
в файле /etc/default/grub в строку GRUB_CMDLINE_LINUX добавить 
transparent_hugepage=never
On BIOS-based machines: grub2-mkconfig -o /boot/grub2/grub.cfg
On UEFI-based machines: grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
reboot

Для Astralinux:

Начиная с версии 1.8 THP будут отключены по умолчанию

В файле /etc/default/grub в строку GRUB_CMDLINE_LINUX добавить значение transparent_hugepage=never

GRUB_CMDLINE_LINUX="transparent_hugepage=never"

Если в строке указывается несколько параметров, то они разделяются пробелом

После этого выполнить

# update-grub2
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.15.0-70-generic
Found initrd image: /boot/initrd.img-5.15.0-70-generic
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
done
#

После перезагрузки убедиться что изменения применены, можно командой :

# cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

Параметр AnonHugePages должен быть равен 0

root@ep2-mongolog00:~# cat /proc/meminfo 
MemTotal:        4017664 kB
MemFree:         2734024 kB
...
AnonHugePages:         0 kB
...

I/O scheduler

Для SSD и NVMe-устройств лучше ставить планировщик none / noop, который уменьшает нагрузку на CPU, а вот для HDD-дисков лучше использовать mq-deadline, который показывает лучшие результаты по итогам синтетических тестов:
Для CentOS: 
grubby --update-kernel=ALL –args="elevator=noop"
reboot

Для Astralinux:

в файле /etc/default/grub в строку GRUB_CMDLINE_LINUX добавить значение elevator=noop

GRUB_CMDLINE_LINUX="elevator=noop"

после чего выполнить

# update-grub2
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.15.0-70-generic
Found initrd image: /boot/initrd.img-5.15.0-70-generic
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
done
#

После перезагрузки убедиться что изменения применены, можно командой :

# cat /sys/block/sda/queue/scheduler
[noop] mq-deadline cfq

Настройка sysctl.conf

Рекомендации для получения максимальной производительности PostgreSQL, значения параметров необходимо пересчитать исходя из параметров вашего сервера СУБД:

#!/bin/bash
pid=`head -1 $PGDATA/postmaster.pid`
echo "Pid:            $pid"
peak=`grep ^VmPeak /proc/$pid/status | awk '{ print $2 }'`
echo "VmPeak:            $peak kB"
hps=`grep ^Hugepagesize /proc/meminfo | awk '{ print $2 }'`
echo "Hugepagesize:   $hps kB"
hp=$((peak/hps))
echo Set Huge Pages:     $hp

Загрузка из DT

Процесс загрузки DT состоит из следующих этапов:

1. Создаём таблицы согласно метаданным
2. Наполняем таблицы данными
3. Создаём индексы согласно метаданным

Для ускорения пунктов 2 и 3 можно сделать следующие настройки:

1. Отключить автовакуум - autovacuum=off
2. Сделать режим комиттов более пакетным - commit_delay=100000
3. Если используете многопоточную загрузку из DT, то параметр commit_siblings поставьте равным количеству этих потоков, чтобы commit_delay работал.
4. Увеличить работу сессии в RAM - work_mem=2GB
5. Увеличить объем памяти для создания индексов - maintenance_work_mem=4GB
6. При использовании PostgreSQL 11 и выше для ускорения создания индексов выставить параметр max_parallel_maintenance_workers = 50% ядер сервера. Но если используете многопоточную загрузку из DT, то ставьте не более 20% ядер, чтобы создание нескольких больших индексов на разных таблицах не заняло все ресурсы процессора.

После окончания загрузки необходимо обязательно провести Analyze only базы 1С и вернуть настройки к «боевому» режиму.

Возможности платформы 1С для ускорения процесса миграции между СУБД:

Начиная с платформы 8.3.19 загрузка из DT может выполняться многопоточно, количество потоков ограничивается количеством ядер на сервере приложений. В документации это описано здесь. Следует учитывать, что одна таблица может грузиться только в одном потоке.

Начиная с платформы 8.3.23 миграция между различными СУБД может выполняться без выгрузки информационной базы в DT. В документации это описано здесь и здесь. 

Выполнение запросов из 1С

При выполнении каждого запроса платформа 1С явно устанавливает следующие параметры:

SET client_min_messages=error;
SET lc_messages to 'en_US.UTF-8';
SET enable_mergejoin=off;
SET escape_string_warning=off;
SET standard_conforming_strings=off;
SET cpu_operator_cost=0.001;
SET client_encoding='UTF8';
SET lock_timeout=20000;

Параметры enable_mergejoin и cpu_operator_cost могут сильно влиять на выбор плана запроса, поэтому если выполнить EXPLAIN ANALYZE без этих параметров, то можно получить совсем другой план, не тот который выбирается планировщиком при выполнении из 1С.

Параметр lock_timeout берется из параметра информационной базы 1С "Время ожидания блокировки данных (в секундах)".

История версий

ver. 1.0 from 13.12.23

Создана инструкция

ver 1.1 from 03.02.24

default_statistics_target: 500 → 100

ver 1.2 from 11.05.24

jit: on → off

ver 1.3 from 21.06.24

Дополнен раздел "Регламентное обслуживание": настройка регламентного обслуживания с помощью модуля "Задачи" платформы Tantor.

ver 1.4 from 22.07.24

from_collapse_limit: 10 → 20

join_collapse_limit: 10 → 20

default_toast_compression: pglz → lz4