В процессе эксплуатации высоконагруженных систем на платформе 1С:Предприятие 8.3 в связке с PostgreSQL системные администраторы и разработчики часто сталкиваются с парадоксальной ситуацией: один и тот же отчет (например, «Задолженность клиентов» в УТ 11) у пользователя с полными правами формируется за 3–5 секунд, в то время как у обычного менеджера этот процесс занимает 30 секунд и более. При этом аппаратная часть (сервер, SSD) работает исправно, а настройки SQL кажутся оптимальными. Рассмотрим подробнее, почему так происходит, и разберем по шагам методы устранения этой проблемы.
Первая и самая вероятная причина существенной разницы в скорости — работа механизма ограничения прав доступа на уровне записей (RLS). Проанализируем, как 1С взаимодействует с СУБД в разных режимах:
RLS. Запрос уходит в PostgreSQL в «чистом» виде, обращаясь напрямую к таблицам данных.RLS заставляет платформу модифицировать исходный запрос. К каждому обращению к таблице (Документы, Справочники, Регистры) добавляются неявные JOIN с таблицами прав или вложенные запросы с условиями WHERE.Выясним причину: даже «пустое» ограничение или простое условие проверки прав заставляет планировщик PostgreSQL строить совершенно иной план выполнения. Вместо быстрого Index Scan (сканирование по индексу) СУБД может переключиться на Seq Scan (полное сканирование таблицы), так как добавленные условия прав делают использование индексов неэффективным с точки зрения планировщика.
Чтобы подтвердить теорию о разных планах, нам необходимо проанализировать ситуацию «глазами» СУБД. Рекомендуется использовать консоль запросов, поддерживающую вывод плана Query Plan. Выполним следующие действия:
Index Scan).Nested Loop по огромным таблицам прав или последовательные сканирования, проблема локализована в RLS.Если бизнес-логика позволяет, самым быстрым «рабочим» решением является перевод формирования тяжелого отчета в привилегированный режим. Это позволит коду выполняться без проверки прав доступа, фактически со скоростью администратора. Рассмотрим пример реализации через расширение конфигурации:
&НаСервере
Процедура ПриСформированииОтчетаНаСервере()
УстановитьПривилегированныйРежим(Истина);
// Код вызова основной схемы компоновки данных или формирования запроса
Отчеты.ЗадолженностьКлиентов.Сформировать(Параметры);
УстановитьПривилегированныйРежим(Ложь);
КонецПроцедуры
Использование УстановитьПривилегированныйРежим(Истина) отключает проверку RLS на время выполнения блока кода. Это особенно эффективно для отчетов по регистрам накопления в УТ 11, где условия прав могут быть крайне громоздкими.
Поскольку наша система работает на Windows, следует проверить специфические настройки postgresql.conf, которые влияют на построение временных таблиц, активно используемых 1С при проверке прав. Проанализируем ключевые параметры:
RLS помещались в оперативной памяти.Также крайне важно выполнить команду ANALYZE для всей базы данных. Это обновит статистику, и планировщик сможет более адекватно оценивать стоимость использования индексов при добавлении условий RLS.
Медленная работа под обычным пользователем часто связана с инициализацией сеансовых параметров при первом обращении к данным. В УТ 11 параметры, такие как ДоступныеПунктыВыдачи, ВидыЦен или Подразделения, заполняются динамически. Если у пользователя много ролей, проверка прав на эти объекты при заполнении параметров может занимать значительное время.
Проанализируем количество ролей в профиле пользователя. Если их более 50–100, платформа тратит много ресурсов на их суммирование. Попробуем объединить мелкие роли в одну специализированную роль или минимизировать их количество в профиле «Менеджер».
Не забудем про системные факторы, которые могут влиять на интерактивную работу обычных пользователей:
%AppData%\1C) и файлы журналов. Постоянная проверка временных файлов temp_statistics в Postgres может замедлять работу именно тех запросов, которые порождают много временных таблиц (что характерно для запросов с RLS).В современных конфигурациях (УТ 11.4 и выше) существует настройка «Упрощенный режим проверки прав доступа». Перейдем в раздел Администрирование — Настройки пользователей и прав. Если включен режим «Использовать ограничения на уровне записей», платформа будет выполнять сложные стыковки таблиц. Если бизнес-требования позволяют, стоит рассмотреть переход на упрощенный режим или полное отключение RLS для конкретных видов объектов, где наблюдается наибольшее замедление.
Подводя итог, отметим: если вы видите разницу в скорости между админом и пользователем, проблема почти всегда кроется в плане запроса, который деградирует из-за наложенных ограничений RLS. Последовательное применение ANALYZE, настройка work_mem и использование привилегированного режима для тяжелых отчетов позволяют сократить разрыв в производительности до минимума.