Проблема медленного открытия форм выбора в крупных прикладных решениях, таких как 1С:ERP 2.4, при использовании СУБД PostgreSQL — явление довольно распространенное. Особенно остро это ощущается в справочнике ОбъектыЭксплуатации, который является ключевым звеном подсистемы управления активами и ремонтами. Примечательно, что на файловых версиях базы данных та же форма может работать мгновенно, что вводит разработчиков в заблуждение. В этой статье мы детально разберем причины такого поведения и пошагово пройдем путь оптимизации системы.
Прежде чем переходить к сложным манипуляциям с сервером, необходимо исключить влияние пользовательских факторов. Часто бывает так, что конкретный пользователь случайно сохранил настройки формы, которые мешают эффективной работе индексов базы данных. Рассмотрим этот процесс подробнее.
Проанализируем ситуацию: если в динамическом списке установлен отбор по колонке, которая не индексирована, или используется сложный поиск по подстроке, PostgreSQL может переключиться на полное сканирование таблицы (Seq Scan) вместо использования индекса. Разберем по шагам, как исключить этот фактор:
ОбъектыЭксплуатации связан со множеством других сущностей, и вывод дополнительных реквизитов через точку может порождать тяжелые LEFT JOIN в SQL-запросе.Если сброс настроек не помог, перейдем к анализу метаданных в конфигураторе. Форма выбора справочника ОбъектыЭксплуатации обычно строится на базе объекта ДинамическийСписок. Посмотрим на критические свойства этого объекта:
Свойство «Динамическое считывание данных». Включите это свойство, если оно выключено. Это позволит системе запрашивать данные порциями, а не пытаться вычислить общее количество записей в таблице при каждом открытии. В случае с PostgreSQL расчет общего количества записей (COUNT) в большой таблице с наложенными фильтрами прав доступа может занимать секунды.
Основная таблица. Убедимся, что в свойстве ОсновнаяТаблица динамического списка жестко указан справочник ОбъектыЭксплуатации. Если это поле пустое, платформа не сможет эффективно использовать механизмы автоматического построения запросов и оптимизации индексов для сортировки и отбора.
В 1С:ERP 2.4 подсистема прав доступа является одной из самых тяжелых. Справочник объектов эксплуатации активно использует RLS. Разберем, как это влияет на производительность в связке с PostgreSQL. На этой СУБД старый механизм ограничений генерирует крайне громоздкие SQL-запросы с вложенными подзапросами, которые планировщик PostgreSQL часто не может оптимально обработать.
Для решения этой проблемы выполним следующие действия:
SELECT при открытии списка.Зачастую PostgreSQL «из коробки» настроен на универсальное использование, что не подходит для специфики запросов 1С. Выясним, какие параметры конфигурационного файла postgresql.conf напрямую влияют на скорость открытия форм выбора:
random_page_cost. Для современных SSD и NVMe накопителей значение по умолчанию (4.0) слишком высоко. Оно заставляет планировщик «думать», что чтение случайной страницы данных обходится в 4 раза дороже последовательного. Установим значение в диапазоне 1.1 – 1.5. Это стимулирует PostgreSQL чаще использовать индексный поиск.
work_mem. Этот параметр определяет объем памяти для операций сортировки внутри одного запроса. Если памяти недостаточно, PostgreSQL создает временные файлы на диске. Для тяжелых форм ERP рекомендуется установить значение не менее 32MB или 64MB (в зависимости от общего объема ОЗУ).
effective_cache_size. Установим его равным примерно 50-75% от общей оперативной памяти сервера. Это даст планировщику понять, какой объем данных может быть кеширован, и позволит выбирать более эффективные планы выполнения.
PostgreSQL строит план запроса на основе статистических данных о распределении значений в таблицах. Если в справочник ОбъектыЭксплуатации недавно загружалось много данных (например, при первоначальном вводе остатков или миграции), статистика может быть неактуальной.
Разберем, как принудительно обновить данные для планировщика. Необходимо выполнить команду ANALYZE для таблиц справочника и всех связанных с ним регистров сведений (например, тех, где хранится состояние или местоположение объектов). В консоли PostgreSQL это выглядит так:
ANALYZE _Reference150; -- Где _Reference150 - имя таблицы справочника в БД
ANALYZE _InfoReg200; -- Имя таблицы связанного регистра
Рекомендуется настроить регламентное задание на стороне СУБД или в 1С, которое будет выполнять VACCUM ANALYZE регулярно в часы минимальной нагрузки.
Если вышеперечисленные методы не принесли желаемого результата, проанализируем ситуацию с помощью Технологического журнала (ТЖ). Нам необходимо поймать конкретный SQL-запрос, который выполняется долго. Настроим файл logcfg.xml для сбора событий DBPOSTGRS и SDBL.
Пример настройки для сбора длительных запросов (более 5 секунд):
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="/var/log/1c/logs" history="24">
<event>
<eq property="Name" value="DBPOSTGRS"/>
<gt property="Duration" value="5000000"/>
</event>
<property name="all"/>
</log>
</config>
Получив текст запроса из лога ТЖ, перейдем в консоль PostgreSQL (например, через pgAdmin) и выполним команду EXPLAIN ANALYZE, вставив текст запроса. Это покажет нам реальный план выполнения: в каком месте происходит затык, где планировщик ошибается и где не хватает индекса. Часто выясняется, что виной всему скрытое соединение с регистром сведений, в котором нет подходящего индекса по периоду или измерению.
В заключение отметим, что оптимизация формы выбора в ERP — это комплексная задача, требующая внимания как к коду 1С, так и к настройкам серверной части. Последовательное выполнение описанных шагов позволит сократить время открытия формы с десятков секунд до комфортных значений.