В практической работе с программой 1С:Зарплата и управление персоналом 3.1 технические специалисты часто сталкиваются со следующей ситуацией: у одного или нескольких пользователей начинает сильно зависать открытие справочника Сотрудники, а также поиск или прокрутка в нем. При этом у остальных сотрудников, включая системных администраторов, эта же форма работает молниеносно. Стандартные процедуры вроде очистки локального кэша 1С или перезапуска клиентского приложения не приносят никакого результата. Даже запуск сессии под этой учетной записью непосредственно на сервере приложений демонстрирует те же задержки.
В рамках этой статьи мы подробно разберем, почему возникает данная проблема, как её оперативно решить в пользовательском режиме и какие системные настройки необходимо выполнить для предотвращения подобных сбоев в будущем.
Для того чтобы понять природу этой проблемы, нам необходимо заглянуть на уровень взаимодействия платформы 1С и СУБД (в частности, PostgreSQL). Справочник Сотрудники в современных конфигурациях построен на базе механизма ДинамическийСписок. Динамические списки считывают данные из базы порциями, формируя оптимальные SQL-запросы в реальном времени.
Однако ситуация кардинально меняется, когда в дело вступают два фактора:
Кадровик или Табельщик) включен контроль доступа. При каждом обращении к базе данных платформа 1С автоматически модифицирует исходный SQL-запрос, накладывая на него сложные условия фильтрации (проверяются разрешенные организации, подразделения или группы доступа физических лиц).Сотрудник.ТекущееПодразделение.Родитель или ФизическоеЛицо.ОсновноеУдостоверение), настраивают сложные отборы, группировки или сортировки по неиндексированным полям.Когда эти два фактора объединяются, происходит следующее: транслятор 1С генерирует для СУБД PostgreSQL колоссальный по объему SQL-запрос со множеством левых соединений (LEFT JOIN) и тяжелых вложенных подзапросов, обеспечивающих проверку прав RLS. Из-за избыточной сложности запроса оптимизатор СУБД PostgreSQL ошибается при построении плана его выполнения. Вместо быстрого поиска по индексам (Index Scan) база данных переходит к последовательному чтению гигантских таблиц (Seq Scan) или неоптимальным вложенным циклам (Nested Loops). В результате простейший вывод списка на экран начинает занимать минуты, намертво блокируя рабочий процесс кадровика.
Поскольку у пользователей с полными правами (Администраторов) механизмы RLS отключены по умолчанию, СУБД мгновенно обрабатывает их запросы даже при наличии сложных пользовательских полей «через точку». Именно поэтому проблема носит исключительно индивидуальный характер.
Самый быстрый способ вернуть работоспособность справочника — полностью очистить пользовательские настройки этой формы, вернув её к исходному системному виду. Разберем по шагам, как это сделать администратору базы данных в пользовательском режиме:
Справочник.Сотрудники.ФормаСписка или аналогичному названию формы списка сотрудников).Del на клавиатуре).После проведения данной процедуры при следующем открытии справочника у пользователя восстановится стандартный лаконичный вид формы, а все «тяжелые» соединения исчезнут из SQL-запроса. Справочник снова начнет открываться мгновенно.
Чтобы минимизировать влияние ограничений прав доступа на СУБД, в Библиотеке стандартных подсистем (БСП) 1С был разработан специальный оптимизированный режим работы с правами доступа. Проверим и включим его:
Как это работает: При включении этого режима платформа перестает генерировать тяжелые условия «на лету» во время выполнения каждого запроса. Вместо этого система создает плоские вспомогательные таблицы (кэш прав доступа), данные в которых обновляются в фоновом режиме при изменении кадровых документов или прав. СУБД выполняет простые соединения с этими таблицами, что радикально ускоряет работу динамических списков под ограниченными правами.
Если торможение справочников началось внезапно (как часто и происходит после массового ввода документов или обновления конфигурации), это явный признак того, что планировщик PostgreSQL оперирует устаревшей статистикой распределения данных в таблицах.
Для исправления ситуации системному администратору или администратору СУБД необходимо запустить принудительный сбор статистики. Выполним в консоли СУБД или через утилиту pgAdmin следующий запрос для проблемной базы данных:
ANALYZE;
Для более глубокой очистки и сбора статистики рекомендуется запустить комбинированную команду:
VACUUM ANALYZE;
Регулярное выполнение команды ANALYZE (желательно настроить регламентную задачу в планировщике СУБД на еженощный запуск) гарантирует, что PostgreSQL будет строить наиболее эффективные планы запросов, задействуя нужные индексы даже при сложных пользовательских настройках интерфейса.
Если пользователи вашей системы регулярно перегружают динамические списки неоптимальными реквизитами, имеет смысл ограничить их возможности на уровне конфигурации.
Разберем, как запретить пользователям добавлять произвольные поля в список сотрудников:
Сотрудники, откроем его свойства и перейдем на вкладку Формы.Таблица (наш динамический список сотрудников).Ложь).После этого пользователи потеряют возможность самостоятельно добавлять новые колонки в эту конкретную форму списка через меню настройки интерфейса. При этом стандартные функции группировки, сортировки и отборов по уже выведенным колонкам останутся им доступны.
Если зависания справочника происходят преимущественно в момент ввода символов в строке быстрого поиска, корень проблемы может крыться в повреждении или неактуальности индекса полнотекстового поиска (ППД).
Проанализируем и исправим состояние индекса полнотекстового поиска через пользовательский интерфейс:
В случаях, когда пользователю критически важно сохранить его индивидуальные настройки формы, и простой сброс неприемлем, мы можем выяснить, какая именно колонка ломает СУБД. Для этого воспользуемся механизмом Технологического журнала (ТЖ) 1С.
Создадим в каталоге установки шаблонов конфигурации ТЖ файл настройки logcfg.xml со следующим содержимым:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8_logs\slow_queries" history="24">
<event>
<eq property="Name" value="DBPOSTGRS"/>
<gt property="Duration" value="5000000"/>
</event>
<property name="all"/>
</log>
</config>
Этот файл настроит сбор логов по СУБД PostgreSQL (событие DBPOSTGRS) для всех запросов, длительность выполнения которых превышает 5 секунд (5 000 000 микросекунд). Запустим сессию под проблемным пользователем, откроем справочник Сотрудники и дождемся его прорисовки.
После этого откроем файл лога в каталоге C:\v8_logs\slow_queries. Мы увидим проблемный SQL-запрос, сгенерированный платформой. Изучив структуру соединений LEFT JOIN в тексте запроса, разработчик сможет легко понять, к какому именно реквизиту формы обращается система, и точечно удалить только эту проблемную колонку из настроек формы пользователя, сохранив все остальные его персональные отборы.