← На главную

Многие технические специалисты сталкиваются с ситуацией, когда в конфигурации 1С:Управление торговлей 11.5 пользователи с ограниченными правами жалуются на крайне медленную работу системы. При этом у администраторов с полными правами всё «летает». Особенно ярко проблема проявляется при открытии тяжелых журналов, таких как «Документы продажи», где время ожидания может достигать нескольких минут. Давайте детально разберем причины этого явления и пошагово рассмотрим способы оптимизации производительности.

Разберем механику проблемы: почему права доступа замедляют базу?

Основная причина кроется в механизме RLS (Record Level Security) — ограничении доступа на уровне записей. Когда пользователь с ограниченными правами открывает список документов, платформа 1С не просто делает запрос к базе данных, а динамически модифицирует его. К основному запросу добавляются многочисленные условия WHERE и соединения JOIN, которые проверяют, имеет ли пользователь право видеть каждую конкретную запись (например, по организации, складу или менеджеру).

В современных конфигурациях, таких как УТ 11.5 или ERP, количество ролей и сложность условий доступа колоссальны. Это приводит к тому, что итоговый SQL-запрос становится перегруженным, и планировщик СУБД (будь то PostgreSQL или MS SQL) не может построить оптимальный план выполнения.

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

Первое, что мы должны проанализировать — это текущий режим работы ограничений доступа. В платформе 8.3 существует два режима: стандартный и производительный. Рассмотрим подробнее производительный режим.

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

1. Перейдем в раздел НСИ и администрирование — Настройка пользователей и прав.
2. Найдем пункт Ограничение доступа на уровне записей.
3. Убедимся, что выбран вариант использования производительного режима (в некоторых релизах это настраивается через константу ВариантРаботыОграниченияДоступа).

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

Шаг 2. Оптимизация профилей и ролей пользователей

Проанализируем структуру прав конкретного пользователя. В УТ 11.5 часто встречается избыточность: одному сотруднику назначается 10–15 профилей групп доступа, в каждом из которых десятки ролей. При формировании запроса платформа вынуждена объединять условия из всех этих ролей оператором OR (ИЛИ).

Для оптимизации рекомендуется:

• Создавать минимальное количество профилей для одного пользователя.
• Если это возможно, объединять несколько мелких ролей в одну общую роль под конкретную производственную задачу.
• Избегать дублирования прав в разных ролях.

Помните: чем меньше условий OR будет в итоговом SQL-запросе, тем быстрее СУБД вернет результат.

Шаг 3. Настройка PostgreSQL для работы с тяжелыми запросами

Если ваша база работает на PostgreSQL, стандартные настройки «из коробки» часто не справляются с нагрузкой RLS. Выясним, какие параметры планировщика помогут ускорить выполнение запросов:

Во-первых, обратим внимание на random_page_cost. Для систем на быстрых SSD-дисках рекомендуется снизить этот параметр до 1.1 или даже 1.0 (по умолчанию он равен 4). Это заставит планировщик чаще использовать индексы вместо полного сканирования таблиц.

Во-вторых, проанализируем параметр jit (Just-In-Time compilation). В версиях PostgreSQL 12 и выше он включен по умолчанию. Однако для 1С он часто вреден, так как время на компиляцию плана запроса может превышать время его выполнения. Попробуем отключить его командой:

jit = off

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

Шаг 4. Оптимизация динамических списков и журналов

Проблема 8-минутного открытия журнала продаж часто связана не только с базой, но и с настройками самого списка в интерфейсе. Рассмотрим, как облегчить работу ДинамическогоСписка:

• Проверим наличие произвольных запросов в журнале. Если в запросе списка используются левые соединения (LEFT JOIN) с таблицами, на которые также наложен RLS, нагрузка растет в геометрической прогрессии.
• Включим опцию Динамическое считывание данных. Это позволит системе подгружать только видимую часть записей, а не пытаться обработать весь массив данных.
• Минимизируем использование полей типа Представление для ссылочных данных (Склад, Организация, Менеджер) в колонках списка. Получение представления — это дополнительный запрос и дополнительная проверка прав.

Шаг 5. Тюнинг MS SQL Server (TempDB)

Если вы используете MS SQL Server, одной из причин тормозов при включенном RLS может быть перегрузка временной базы данных tempDB. Именно в ней строятся временные таблицы для проверки прав.

Проанализируем состояние tempDB:

1. Убедимся, что файлы tempDB вынесены на самый быстрый диск (NVMe/SSD).
2. Количество файлов данных tempDB должно соответствовать количеству ядер процессора (но не более 8, согласно общим рекомендациям Microsoft для типичных нагрузок).
3. Проверим настройки авторасширения файлов — они должны быть одинаковыми для всех файлов данных, чтобы запись шла равномерно.

Шаг 6. Индексация полей доступа

Выясним, по каким полям настроено ограничение доступа. Если в УТ 11.5 вы ограничиваете доступ по «Подразделению» или «Складу», эти поля обязательно должны быть индексированы в соответствующих документах и справочниках. Без индексов по полям, участвующим в условиях RLS, СУБД будет вынуждена перебирать все записи в таблице (Full Table Scan), что и приводит к «зависаниям» на несколько минут.

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