Как устранить зависание и ускорить работу запросов с RLS в 1С на PostgreSQL?

← На главную

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

Виновником такого поведения является механизм ограничения доступа на уровне записей — RLS (Row-Level Security). В этой статье мы подробно разберем, почему PostgreSQL чувствителен к стандартным запросам RLS, как перевести базу в производительный режим работы ограничений, а также какие параметры СУБД и платформы «1С:Предприятие» необходимо настроить для достижения максимальной скорости работы.

Почему классический RLS работает медленно на PostgreSQL?

Для того чтобы понять суть проблемы, проанализируем, как работает классический механизм RLS, заложенный в старых версиях конфигураций 1С и платформы. Когда пользователь с ограниченными правами (например, менеджер по продажам с доступом только к своей организации) делает запрос к списку документов, платформа динамически модифицирует исходный запрос. К нему «на лету» пристраивается огромная конструкция из вложенных подзапросов, условий ГДЕ, операторов ОБЪЕДИНИТЬ и многочисленных соединений JOIN с таблицами прав доступа.

В отличие от MS SQL Server, оптимизатор запросов PostgreSQL исторически менее эффективно справляется с многократно вложенными запросами и динамическими условиями OR. Планировщик PostgreSQL в таких условиях часто строит неоптимальный план выполнения, отказывается от использования существующих индексов и уходит в полное последовательное сканирование таблиц (операция Seq Scan), что приводит к зависанию запроса на минуты.

Решение 1. Переход на производительный режим работы RLS

Самым эффективным способом решения проблемы на уровне прикладного решения является включение встроенного в «1С:Библиотеку стандартных подсистем» (БСП) производительного режима работы RLS (его также называют «быстрым RLS»). Этот механизм доступен во всех современных типовых конфигурациях (УТ 11, ERP 2, КА 2, БП 3).

Рассмотрим, как меняется логика работы системы при включении этого режима:

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

Для того чтобы включить производительный режим работы RLS в вашей конфигурации, выполните следующие шаги:

Перейдите в раздел НСИ и администрирование — Настройка пользователей и прав.
Разверните группу настроек Группы доступа.
Найдите и установите флажок Производительный режим работы ограничений прав доступа (в некоторых версиях конфигураций опция может называться «Оптимизировать производительность ограничений прав доступа»).
После включения опции система автоматически запустит фоновые задания по расчету ключей доступа. При первом включении этот процесс может занять значительное время (от нескольких десятков минут до нескольких часов в зависимости от объема информационной базы). Следить за ходом процесса можно через стандартную обработку «Панель администрирования» или в журнале регистрации.

Важное примечание: Этот механизм требует регулярного обновления данных. Если регламентные задания по расчету ключей зависнут или будут отключены, пользователи могут временно перестать видеть вновь созданные документы или измененные элементы справочников. Следите за стабильностью выполнения регламентного задания ЗаполнениеКлючейДоступа. Для оперативного исправления прав конкретных учетных записей без полного ожидания регламентных заданий подойдёт обработка для точечного пересчета прав доступа пользователей.

Решение 2. Тонкая настройка параметров конфигурации PostgreSQL

Если перевод конфигурации в производительный режим не решил проблему до конца или вы используете старую версию БСП, необходимо оптимизировать сам PostgreSQL. Настройки по умолчанию ориентированы на универсальные СУБД-сценарии и совершенно не подходят для тяжелых RLS-запросов 1С. Изменим ключевые параметры в файле postgresql.conf.

1. Параметры collapse_limit (схлопывание подзапросов)

По умолчанию параметры планировщика, отвечающие за оптимизацию вложенных конструкций, имеют слишком низкие значения:


join_collapse_limit = 20
from_collapse_limit = 20

По умолчанию эти параметры равны 8. Это означает, что если в запросе объединяется более 8 таблиц (а при RLS их может быть значительно больше), планировщик PostgreSQL перестает искать глобально оптимальный план и начинает соединять их поочередно. Увеличение лимитов до 20 (или даже до 40–50 в особо запущенных случаях) позволяет планировщику «схлопнуть» сложные вложенные RLS-подзапросы в плоскую структуру и построить быстрый план выполнения.

2. Выделение оперативной памяти для запросов (work_mem)

Сложные ограничения прав требуют выполнения ресурсоемких сортировок, группировок и хэш-объединений. Если СУБД не укладывается в выделенный лимит оперативной памяти на один запрос, она начинает сбрасывать промежуточные таблицы на медленный диск:

work_mem = 128MB

Для серверов с большим объемом ОЗУ (от 64 ГБ) этот параметр можно смело увеличивать до 256MB или 512MB. Это позволит выполнять все промежуточные вычисления RLS непосредственно в оперативной памяти.

3. Буферы временных таблиц (temp_buffers)

Платформа 1С активно создает временные таблицы для хранения списков разрешенных объектов и групп пользователей. Увеличим объем буфера под временные таблицы:

temp_buffers = 128MB

4. Стоимость дисковых операций (для баз на SSD/NVMe)

По умолчанию PostgreSQL считает, что случайное чтение с диска стоит в 4 раза дороже, чем последовательное (`random_page_cost = 4.0`). Из-за этого планировщик при RLS-запросах часто избегает использования индексов, предпочитая полное сканирование таблицы. Если ваша база расположена на быстрых твердотельных накопителях, установите следующие значения:


seq_page_cost = 0.1
random_page_cost = 0.4

Это заставит планировщик PostgreSQL доверять индексам и использовать их гораздо активнее.

5. Модуль автоматического сбора статистики online_analyze

Убедитесь, что в списке предварительно загружаемых библиотек shared_preload_libraries прописан модуль online_analyze, и включите его автозапуск:

online_analyze.enable = on

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

Решение 3. Обновление платформы «1С:Предприятие»

Если вы работаете на устаревших версиях платформы (например, 8.3.12–8.3.16), настоятельно рекомендуем выполнить обновление до актуальных релизов ветки 8.3.18, 8.3.21 или новее. Начиная с версии платформы 8.3.18, разработчики 1С кардинально переработали механизм трансляции RLS в SQL-запросы для PostgreSQL:

Платформа теперь умеет предварительно анализировать шаблоны RLS.
Независимые подзапросы (которые вычисляют, к каким группам доступа относится текущий пользователь) теперь выполняются один раз на стороне сервера 1С, а результат кэшируется в оперативной памяти рабочего процесса rphost.
В базу данных PostgreSQL уходит уже «чистый» SQL-запрос, в который вместо монструозных подзапросов передаются готовые массивы идентификаторов в качестве параметров. Это минимизирует различия в производительности между СУБД MS SQL и PostgreSQL при работе с RLS.

Решение 4. Диагностика и ручной анализ планов запросов

Если после выполнения всех настроек точечные запросы или отчёты продолжают выполняться медленно, необходимо локализовать конкретное узкое место. Для этого выполним следующие действия:

Включите в PostgreSQL логирование планов медленных запросов с помощью модуля auto_explain. Настройте минимальное время логирования, например, 5 секунд.
Найдите в технологическом журнале СУБД проблемный запрос и изучите его план выполнения.
Ищите в плане узлы со значением Seq Scan по крупным таблицам документов или регистров. Это свидетельствует об отсутствии подходящего индекса или о сбое в расчете статистики.
Регулярно выполняйте регламентную процедуру обновления статистики СУДБ. Запустите команду ANALYZE вручную для всей базы данных после массовых обновлений или крупных загрузок данных. Неактуальная статистика — самая частая причина, по которой PostgreSQL выбирает неверный план выполнения для сложных запросов с ограничениями доступа.

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