Почему документы в 1С загружаются долго только у одного пользователя и как это исправить?

Ситуация, когда у одного пользователя система «летает», а у другого аналогичное действие занимает минуты, является одной из самых сложных диагностических задач для разработчика 1С. Особенно часто это проявляется при работе с документами подсистемы «Взаимодействия» (письма, звонки) в крупных конфигурациях, таких как 1С:ERP или Комплексная автоматизация. Проблема осложняется тем, что стандартный замер производительности часто не показывает реальную картину задержки. В этой статье мы подробно разберем, как локализовать и устранить причины избирательных тормозов.

Анализируем симптомы: почему замер производительности может «врать»

Рассмотрим ситуацию: менеджер создает исходящее письмо, и при нажатии кнопки «Провести и закрыть» система зависает на 1.5–2 минуты. При этом под полными правами (администратор) операция занимает секунды. Первое, что мы делаем — запускаем Замер производительности. Однако здесь нас ждет ловушка: замер может показать суммарное время выполнения кода, например, 20 секунд, в то время как пользователь ждет все 120.

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

Шаг 1: Исключаем влияние окружения и настроек профиля

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

1. Очистка кэша: Попробуем удалить базу из списка и добавить её заново. Это принудительно создаст новый локальный кэш. Однако, если проблема воспроизводится на разных компьютерах под одной учётной записью 1С, кэш ни при чем.
2. Копирование настроек: Попробуем создать нового пользователя (копированием того, у которого всё работает) и зайти под ним. Если под новым пользователем тормозов нет — проблема в сохраненных настройках.
3. Очистка настроек пользователя: Перейдем в раздел Администрирование — Настройки пользователей и прав — Персональные настройки пользователей. Очистим все настройки отчетов и формы. Проанализируем ситуацию: иногда накопленный годами «мусор» в сохраненных настройках (особенно в тяжелых отчетах) может замедлять инициализацию связанных объектов.

Шаг 2: Проверка гипотезы RLS (Access Control List)

Если при назначении пользователю роли «Полные права» проблема мгновенно исчезает — мы имеем дело с RLS. Рассмотрим подробнее, как это работает в подсистеме взаимодействий. Доступ к письму часто ограничен не только правами на сам документ Документ.ЭлектронноеПисьмоИсходящее, но и правами на его «Предмет» (Заказ клиента, Сделка, Партнер).

Если у пользователя настроены сложные ограничения (например, «видеть только своих клиентов»), то при записи письма система выполняет многоуровневую проверку всей цепочки связанных объектов. Разберем, как проверить эффективность RLS:

1. Метод исключения: Попробуем поочередно отключать роли у пользователя. Если ролей слишком много, можно временно очистить Шаблоны ограничений в конфигураторе для конкретных ролей. Если после очистки шаблонов «всё полетело» — причина найдена.
2. Анализ избыточности: Проанализируем, не назначены ли пользователю несколько ролей, ограничивающих один и тот же объект. 1С не рекомендует пересекающиеся ограничения по одному объекту в разных ролях, так как СУБД приходится объединять (через OR или UNION) несколько тяжелых условий, что убивает производительность.

Шаг 3: Оптимизация регистра «Наборы значений доступа»

В современных конфигурациях используется механизм «Производительного RLS». Он опирается на данные в регистре сведений РегистрСведений.НаборыЗначенийДоступа. Одной из известных проблем является потеря индексов или их неэффективность в этом регистре.

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

• НомерНабора
• ЗначениеДоступа
• Уточнение
• СтандартноеЗначение

После внесения изменений необходимо обновить конфигурацию базы данных и выполнить обновление вспомогательных данных доступа через консоль администратора (раздел Обслуживание — Управление доступом — Обновить).

Шаг 4: Борьба с «Parameter Sniffing» на уровне SQL

Бывает так, что код оптимален, индексы на месте, но SQL-сервер «тупит» только на конкретном пользователе. Это может быть связано с механизмом Parameter Sniffing. SQL-сервер кэширует план выполнения запроса. Если первый раз запрос (с RLS-фильтрами) был выполнен под пользователем с одним набором прав, сервер может построить план, который будет крайне неэффективен для другого пользователя с другим объемом данных.

Для решения выполним следующие действия на стороне сервера БД:

-- Очистка кэша планов для конкретной базы данных
DECLARE @DBID INT = DB_ID('Имя_Вашей_Базы');
DBCC FLUSHPROCINDB(@DBID);
GO

-- Обновление статистики для таблиц доступа
UPDATE STATISTICS _InfoRgXXXX; -- Имя таблицы регистра НаборыЗначенийДоступа в SQL
GO

Это заставит СУБД пересчитать планы выполнения с учетом актуального распределения данных.

Шаг 5: Ручная отладка по шагам (Stopwatch метод)

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

Обратите внимание на системные вызовы в модулях:

• УправлениеДоступом
• РаботаСПочтовымиСообщениями
• ОбщегоНазначенияБСП

Если вы видите, что выполнение «замирает» на стандартном методе ЭтотОбъект.Записать() или на вызове платформенной функции проверки прав, значит, проблема стопроцентно локализована в механизме RLS и SQL-запросах, которые он генерирует. В этом случае проверьте, не включено ли у пользователя слишком много групп доступа, в каждой из которых настроены свои виды доступа (по организациям, по подразделениям, по группам партнеров). Чем больше видов доступа активно одновременно, тем сложнее становится итоговый SQL-запрос.

Резюме и рекомендации

Подведем итоги. Если у одного пользователя 1С тормозит при записи документа, а у администратора — нет, пройдите по этому чек-листу:

1. Проверьте, воспроизводится ли проблема на другом ПК под этим же пользователем (исключаем локальный кэш 1С).
2. Очистите настройки пользователя (отчеты, формы, рабочие столы).
3. Проверьте актуальность индексов в регистре НаборыЗначенийДоступа.
4. Убедитесь, что у пользователя нет избыточных, дублирующих друг друга ролей.
5. Обновите статистику SQL-сервера.

Помните, что подсистема Взаимодействия в 1С:ERP очень чувствительна к правам на связанные объекты. Иногда проще пересмотреть модель доступа пользователя, чем пытаться оптимизировать гигантские запросы, генерируемые RLS.