Почему зависает 1С при открытии списков документов на PostgreSQL и как это исправить?

← На главную

При работе крупных конфигураций, таких как 1С:Комплексная автоматизация 2 или 1С:ERP, на связке Linux (CentOS) и PostgreSQL системные администраторы и разработчики часто сталкиваются с резким падением производительности. Характерный симптом: у пользователей с полными правами всё работает быстро, а у рядовых сотрудников при попытке открыть списки «Документы закупок», «Продажи» или «Внутренние документы» система «уходит в астрал», а счетчик захвата СУБД в консоли администрирования начинает стремительно расти.

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

Причина проблемы: как Библиотека стандартных подсистем (БСП) проверяет права

Многие ошибочно полагают, что если в настройках программы галочка «Ограничивать доступ на уровне записей» снята, то 1С не выполняет никаких дополнительных проверок. Это не совсем так. Конфигурации на базе БСП (к которым относится и КА 2.4) используют программные методы проверки доступности таблиц. Проанализируем запрос, на котором чаще всего происходит зависание в модуле УправлениеДоступомСлужебный.ЕстьОграничениеТаблицыПоВидуДоступа:


| И (ИСТИНА В
| (ВЫБРАТЬ ПЕРВЫЕ 1
| ИСТИНА
| ИЗ
| РегистрСведений.ТаблицыГруппДоступа КАК ТаблицыГруппДоступа
| ГДЕ
| ТаблицыГруппДоступа.Таблица = СвойстваТекущейТаблицы.Ссылка
| И ТаблицыГруппДоступа.ГруппаДоступа = ГруппыДоступа.Ссылка))

Этот фрагмент кода проверяет наличие прав пользователя на конкретную таблицу метаданных через регистры сведений. Проблема заключается в том, что планировщик PostgreSQL 9.6 (и некоторых более ранних версий 10-й ветки) может некорректно оценить стоимость «полусоединения» (semi-join) внутри условия ИСТИНА В (...). Если статистика по таблицам РегистрСведений.ТаблицыГруппДоступа или Справочник.ИдентификаторыОбъектовМетаданных устарела, база выбирает крайне неэффективный план (например, Nested Loop вместо Hash Join), что приводит к экспоненциальному росту времени выполнения при увеличении количества групп доступа и пользователей.

Решение 1: Обслуживание СУБД (VACUUM и ANALYZE)

Рассмотрим самое оперативное решение, которое в большинстве случаев мгновенно исправляет ситуацию. Проблема «зависания» часто связана с так называемым «раздуванием» (bloat) таблиц и индексов, а также с неактуальной статистикой распределения данных.

Выполним следующие действия в консоли PostgreSQL:

Запуск процедуры VACUUM: Эта операция освобождает место, занятое «мертвыми» кортежами (версиями строк), которые накопились после массовых обновлений данных в регистрах прав.
Запуск ANALYZE: Это критически важный шаг. Статистика сообщает планировщику СУБД, сколько строк в таблице и насколько уникальны значения. На основе этих данных Postgres решает, использовать индекс или сканировать всю таблицу.

Для 1С рекомендуется настроить автоматический запуск этих процедур в postgresql.conf, установив параметр autovacuum_analyze_scale_factor на уровне 0.01–0.02, чтобы статистика обновлялась чаще, не дожидаясь изменения 10% данных в таблице.

Решение 2: Исправление данных метаданных в 1С

Иногда корень проблемы лежит в нарушении логической целостности справочников, хранящих структуру метаданных. Это часто случается после обновления платформы (например, при переходе с 8.3.13 на 8.3.15). Проанализируем ситуацию, когда идентификаторы объектов дублируются или ссылаются на несуществующие элементы.

Выполним в режиме «1С:Предприятие» (через консоль кода или внешнюю обработку) принудительное обновление служебных данных:


// Обновление идентификаторов метаданных
Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника(Истина, Ложь, Ложь);

// Обновление параметров ограничения доступа
УправлениеДоступомСлужебный.ОбновитьПараметрыОграниченияДоступа();

// Обновление вспомогательных данных профилей
Справочники.ПрофилиГруппДоступа.ОбновитьВспомогательныеДанныеПрофилей(, Истина);

// Очистка и перезаполнение регистра таблиц групп доступа
РегистрыСведений.ТаблицыГруппДоступа.ОбновитьДанныеРегистра(,, Истина);

После выполнения этих процедур важно убедиться, что в справочнике ИдентификаторыОбъектовМетаданных нет дублей. Выясним это с помощью простого запроса:


ВЫБРАТЬ ПолноеИмя, КОЛИЧЕСТВО(*) 
ИЗ Справочник.ИдентификаторыОбъектовМетаданных 
СГРУППИРОВАТЬ ПО ПолноеИмя 
ИМЕЮЩИЕ КОЛИЧЕСТВО(*) > 1

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

Решение 3: Оптимизация параметров PostgreSQL для 1С

Если выполнение VACUUM помогает лишь на время, значит, настройки планировщика СУБД не позволяют ему эффективно справляться со сложными вложенными запросами 1С. Рассмотрим параметры в postgresql.conf, которые напрямую влияют на работу модулей управления доступом:

join_collapse_limit и from_collapse_limit: Установим значения 20 или выше (по умолчанию обычно 8). Это позволит планировщику перебирать больше вариантов порядка соединения таблиц в сложных запросах БСП.
random_page_cost: Для современных SSD-дисков это значение должно быть максимально близко к seq_page_cost (например, оба параметра равны 1.1). Если random_page_cost оставить равным 4.0 (по умолчанию), Postgres будет неоправданно избегать использования индексов, предпочитая полное сканирование таблицы (Seq Scan).
standard_conforming_strings: Для платформы 1С этот параметр обязательно должен быть off (хотя в современных версиях платформа сама управляет этим, лучше проверить).

Решение 4: Переключение режима проверки прав в БСП

В современных версиях БСП (начиная с 3.0 и выше, которые интегрированы в свежие релизы КА 2.4 и 2.5) появился новый механизм работы — производительный режим проверки прав. В отличие от стандартного, он не вычисляет права «на лету» сложными запросами, а использует заранее рассчитанные «плоские» таблицы.

Проанализируем наличие этой настройки: НСИ и администрирование — Настройка пользователей и прав — Группы доступа. Если в вашей версии программы доступен выбор между «Стандартным» и «Производительным» режимом, переключение в производительный режим может полностью снять нагрузку с СУБД при открытии списков. Если настройки в интерфейсе нет, попробуйте запустить обработку «Заполнение данных системы разделения прав» из состава Инструментов разработчика БСП.

Дополнительные рекомендации по платформе

Посмотрим на используемую платформу. Версия 8.3.15.1830 имела ряд известных проблем с кэшированием планов запросов именно для PostgreSQL. Если есть возможность, рекомендуется обновиться на более стабильные сборки 8.3.16 или последние релизы 8.3.22/8.3.23, где взаимодействие с PostgreSQL было значительно оптимизировано.

Также не стоит забывать про расширения конфигурации. Если в системе установлены расширения, запрос начинает обращаться к таблице ИдентификаторыОбъектовРасширений. В случае некорректного удаления расширения, ссылки в этой таблице могут стать битыми. Обязательно выполним Тестирование и исправление с установленной галочкой «Проверка логической целостности» для очистки подобных ссылок.

Подводя итог, можно сказать, что проблема «зависания» списков в КА 2 на PostgreSQL — это комплексная беда, требующая внимания как к актуальности статистики в базе данных, так и к чистоте служебных справочников 1С. Регулярное выполнение регламентных операций в СУБД и поддержание структуры метаданных в актуальном состоянии позволят вашим пользователям работать без задержек.