В процессе эксплуатации высоконагруженных систем на базе 1С:ERP Управление предприятием 2 администраторы и разработчики часто сталкиваются с труднообъяснимыми задержками в работе интерфейса. Одной из наиболее специфических проблем являются периодические «замирания» программы, которые происходят с четкой периодичностью, даже если пользователь не совершает никаких активных действий. Рассмотрим детально ситуацию, когда наличие интерактивных прав на документ Заказ клиента приводит к зависаниям системы каждые 60 секунд, и разберем методы решения этой проблемы.
Типичная картина проблемы выглядит следующим образом: пользователь работает в тонком клиенте, и каждые 60 секунд интерфейс блокируется на 10–30 секунд. В этот момент курсор принимает форму «песочных часов», и хотя он перемещается по экрану, нажать на кнопки или переключить вкладки невозможно. Проанализируем ключевой фактор: строгая периодичность в одну минуту. В платформе 1С:Предприятие 8.3 этот интервал по умолчанию зарезервирован для механизма Автообновления динамических списков.
Разберем, почему это происходит именно при наличии прав на Заказ клиента. Опытным путем устанавливается, что зависания возникают только тогда, когда у пользователя в роли включено интерактивное право Просмотр. Если оставить только базовые права (Чтение, Изменение, Добавление), проблема исчезает. Это указывает на то, что задержка происходит не на уровне выполнения запроса к базе данных, а на этапе обработки метаданных и проверки прав доступа интерфейсного уровня.
Выясним техническую подоплеку. В версиях платформы, начиная с 8.3.15.1747, был замечен баг, связанный с деградацией производительности при проверке интерактивных прав доступа. Когда открыт любой динамический список (например, журнал документов или рабочий стол менеджера), платформа инициирует фоновый опрос сервера. Если у пользователя подключен механизм RLS (Record Level Security), система вынуждена при каждом обновлении проверять не только права на таблицу, но и права на отображение конкретных элементов управления.
Проблема усугубляется тем, что документ Заказ клиента в ERP является крайне сложным объектом. Его RLS-шаблоны часто включают проверки по цепочкам:
При проверке интерактивного права Просмотр платформа пытается сопоставить права доступа с элементами формы и метаданными, что вызывает блокировку основного потока клиентского приложения (UI-thread) до тех пор, пока сервер не вернет полный результат проверки прав для текущего контекста.
Проанализируем ситуацию с ограничением доступа на уровне записей. Часто разработчики пытаются отключить RLS в профилях групп доступа, но это не приносит результата. Рассмотрим, почему это происходит: проверка прав замедляется, если сложные шаблоны RLS прописаны непосредственно в роли. Даже если физически ограничений по группам доступа нет (т.е. пользователю разрешено всё), платформа всё равно выполняет синтаксический анализ и компиляцию запроса RLS при каждом обращении к объекту.
Чтобы убедиться в этом, попробуем провести эксперимент: временно удалим текст RLS из роли для права Чтение и Просмотр. Если зависания прекращаются, значит, мы столкнулись с неоптимальной работой менеджера прав доступа платформы.
Первым и самым эффективным решением является переход на более современные версии платформы. Начиная с релизов 8.3.16.1063 и выше, механизмы кэширования дескрипторов прав доступа были существенно переработаны. Если обновление платформы в данный момент невозможно, выполним очистку серверного кэша метаданных:
1С:Предприятия.%ProgramFiles%\1cv8\srvinfo).snccntrc (в ней хранятся счетчики и кэш сеансов).Это позволит системе пересчитать права доступа «с чистого листа», исключив влияние «протухших» записей в кэше, которые могли накопиться после обновления конфигурации.
В современных релизах 1С:ERP 2.4 и 2.5 реализован так называемый «RLS 2.0» (универсальный механизм). Разберем по шагам, как его задействовать для снижения нагрузки:
Этот механизм переносит тяжелые вычисления прав из реального времени (момент запроса данных пользователем) в фоновый режим. Специальные регламентные задания подготавливают данные в таблицах прав, и платформе остается лишь выполнить простое соединение (JOIN) с этими таблицами, что значительно быстрее, чем вычисление сложных вложенных запросов в шаблонах RLS.
Важный нюанс: если вы используете платформу версии 8.3.15, данная «галка» может не решить проблему интерактивных зависаний, так как задержка происходит на этапе передачи состояния прав от сервера к клиенту, а не только при выполнении SQL-запроса.
Если мы понимаем, что зависание провоцируется автообновлением, мы можем изменить поведение динамических списков. Проанализируем код формы списка документов Заказ клиента. Мы можем программно управлять интервалом обновления или вовсе отключить его для проблемных категорий пользователей.
Пример обращения к настройкам списка в коде формы:
// В процедуре ПриСозданииНаСервере или ПриОткрытии
Если НЕ ПравоДоступа("ПолныеПрава", Метаданные) Тогда
// Отключаем или увеличиваем интервал автообновления
ЭтаФорма.Элементы.Список.ПериодАвтоОбновления = 300; // 5 минут вместо 1
КонецЕсли;
Это не устранит саму причину замедления (баг платформы), но сделает работу пользователя более комфортной, так как зависания будут происходить значительно реже.
Подводя итог, можно сказать, что проблема «минутных зависаний» — это комплексный инцидент, сочетающий в себе архитектурную сложность ERP и технические несовершенства конкретных версий платформы. Для исправления ситуации рекомендуем придерживаться следующего алгоритма:
Заказ клиента прописаны сложные RLS, попробуйте перевести их на использование универсального механизма (RLS 2.0).Чтение.Соблюдение этих шагов позволит восстановить стабильную работу системы и исключить непроизводительные простои пользователей 1С:ERP.