При работе в программе 1С:Документооборот редакции 1.4 (особенно на релизах ветки 1.4.1.9) крупные организации часто сталкиваются с критическим падением производительности. Ситуация выглядит следующим образом: при добавлении нового сотрудника в базу, изменении его подразделения или настройке прав система зависает на длительное время (от тридцати минут до нескольких часов), происходит переполнение журнала транзакций СУБД, а пользователи начинают жаловаться на крайнюю медлительность при открытии любых списков документов. Причиной тому служат неоптимальные алгоритмы расчета ограничений доступа на уровне записей (RLS) и особенности работы с дескрипторами доступа.
В этой статье мы подробно разберем, почему возникают эти проблемы, проанализируем внутренние механизмы конфигурации и рассмотрим практические шаги по оптимизации системы и восстановлению быстродействия.
---
Для того чтобы понять, почему добавление одного пользователя приводит к коллапсу всей системы, обратимся к структуре метаданных и коду конфигурации. Основные вычисления прав происходят вокруг регистра сведений СоставСубъектовПравДоступа. Проанализируем цепочку событий при изменении подразделения сотрудника в регистре сведений СведенияОПользователях:
СоставСубъектовПравДоступа.УдалитьВсехРуководителей. Ее задача — определить вышестоящие подразделения по иерархии для текущего сотрудника и очистить записи в регистре СоставСубъектовПравДоступа, где фигурируют эти подразделения.УдалитьНеактуальныеЗаписиВерхнихУровней, которая выполняет тяжелые запросы на удаление правообразующих записей.На крупных предприятиях со сложной организационной структурой, где глубина вложенности подразделений составляет 5 и более уровней, а количество пользователей превышает несколько сотен, выборка при таком пересчете может достигать 140 000 — 250 000 записей за один раз! Попытка СУБД выполнить массовое удаление и последующую вставку сотен тысяч строк в рамках одной транзакции приводит к блокировкам таблиц, лавинообразному росту журнала транзакций (который может раздуваться до 30 Гб и более) и полной остановке совместной работы пользователей.
Параллельно с этим при открытии любых динамических списков документов (например, входящих или исходящих) механизм RLS пытается на лету соединить основные таблицы объектов с регистром ПраваПоДескрипторамДоступа и регистром СоставСубъектовПравДоступа. Из-за огромного объема данных в этих таблицах СУБД строит неоптимальные планы запросов, что выражается в «зависании» интерфейса у конечных пользователей.
---
Еще один скрытый и крайне важный фактор замедления — это накопление записей по помеченным на удаление объектам. Разберем эту проблему подробнее.
В процессе жизнедеятельности компании пользователи регулярно помечают на удаление устаревшие документы, файлы или задачи. Однако в редакции 1.4 дескрипторы доступа (записи в регистре сведений ПраваПоДескрипторамДоступа) для таких помеченных объектов зачастую остаются активными и не удаляются автоматически. В результате СУБД продолжает обрабатывать миллионы «мусорных» связей при каждом выполнении RLS-запроса, тратя ресурсы процессора и дисковой подсистемы впустую.
---
Если у вас нет возможности оперативно перейти на более современные редакции (2.1 или 3.0), выполним комплекс мер по стабилизации работы текущей базы «1С:Документооборот 1.4».
Это первое и самое важное действие, которое позволит убрать длительные зависания интерфейса при оперативной работе пользователей. Нам необходимо разгрузить основной поток транзакций.
Перейдем в раздел Настройки -> Управление расчетом прав и включим опцию Отложенное обновление прав доступа. Данный режим разделяет весь процесс расчета на две очереди:
Обязательно настройте расписание регламентного задания Обновление прав доступа (долгое) так, чтобы оно запускалось исключительно в ночное время (например, с 22:00 до 06:00), когда нагрузка на СУБД минимальна.
Проанализируем состояние регистров прав и избавимся от неиспользуемых записей. Выполним следующие действия:
ПраваПоДескрипторамДоступа.Поскольку при расчете прав происходят массовые изменения в таблицах, статистика СУБД мгновенно устаревает. Это заставляет оптимизатор SQL выбирать неэффективные планы запросов (например, сканирование всей таблицы Index Scan вместо поиска по индексу Index Seek). Настроим регламентные операции на сервере баз данных (MS SQL Server или PostgreSQL):
СоставСубъектовПравДоступа (на уровне SQL это таблица с именем вида _InfoRgXXXX) и регистру ПраваПоДескрипторамДоступа. В MS SQL Server для этого используется команда:
UPDATE STATISTICS _InfoRgXXXX WITH FULLSCAN, COLUMNS;
Описанная авторами на форуме проблема с «бесконечным размножением рабочих процессов» (rphost) и утечками памяти на платформе 8.3.4/8.3.5 напрямую связана с выполнением тяжелых фоновых заданий по расчету прав. Для борьбы с этим применим следующие административные меры на уровне кластера 1С:
86400 секунд (24 часа) или даже 43200 секунд (12 часов) для принудительного высвобождения заблокированной памяти).---
Если все вышеперечисленные меры не приносят желаемого долгосрочного эффекта, наиболее верным стратегическим решением станет планирование перехода на редакцию 2.0/2.1. Фирма «1С» полностью переработала архитектуру безопасности и дескрипторов в последующих версиях: