Почему тормозит справочник «Сотрудники» у одного пользователя в 1С:ЗУП 3.1 и как это исправить

← На главную

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

Рассмотрим подробно причины возникновения такой неисправности, проанализируем поведение СУБД PostgreSQL и платформы 1С, а также разберем пошаговый алгоритм решения проблемы без необходимости полного пересоздания учетной записи пользователя.

Анализ ситуации и поиск причин аномального замедления

Выясним, почему симптомы проявляются выборочно и только в клиент-серверном режиме под СУБД PostgreSQL. Проанализируем ключевые факторы, влияющие на поведение системы:

Хранение настроек в базе данных: Персональные настройки динамических списков, форматирования, отборов и видимости колонок сохраняются не только в локальном кэше пользователя на диске (в каталоге %AppData%), но и на сервере в специализированных таблицах СУБД — ХранилищеПользовательскихНастроекДинамическихСписков, ХранилищеНастроекДанныхФорм и ХранилищеСистемныхНастроек. Именно поэтому очистка локального кэша на ПК не дает результата.
Специфика генерации SQL-запросов динамическим списком: Если пользователь случайно добавил в настройки списка отбор, группировку или сортировку по полю через нескольким связям (например, ФизическоеЛицо.Подразделение.Организация), платформа перестраивает базовый SQL-запрос. В файловом режиме или СУБД MS SQL такой запрос может отрабатывать быстро, однако оптимизатор PostgreSQL (особенно на релизах платформы 8.3.11 и ниже) начинает выполнять полное сканирование таблицы (Seq Scan) вместо использования индексов (Index Scan).
Искажение результатов в замере производительности: При проведении замера производительности отладчик часто указывает на высокую длительность работы служебных процедур, таких как СоединенияИБ.ПараметрыБлокировкиСеансов(). Это связано с тем, что пока сервер 1С ожидает ответа от СУБД по тяжелому запросу списков, клиентский сеанс блокируется, и ближайший опрос фоновых блокировок встает в очередь ожидания, показывая аномальное время выполнения.

Шаг 1. Диагностика и локализация проблемы через замер производительности

Проанализируем поведение системы с помощью встроенного замера производительности в Конфигураторе 1С. Для этого выполним отладку под проблемным пользователем:

Запустим Конфигуратор и подключимся к серверной базе.
Включим режим отладки и откроем инструмент Отладка — Замер производительности.
Под проблемным пользователем зайдём в программу и откроем форма списка Справочник.Сотрудники.
Остановим замер и изучим вызовы с наибольшим суммарным временем исполнения.

Как правило, в замере будет фигурировать серверный вызов проверки блокировок сеанса:


Функция ПараметрыБлокировкиСеансов(ПолучитьКоличествоСеансов = Ложь) Экспорт
    
    Возврат СоединенияИБ.ПараметрыБлокировкиСеансов(ПолучитьКоличествоСеансов);
    
КонецФункции

Если код зависает на данной функции или на процедуре ПриСозданииНаСервере формы списка, это напрямую подтверждает, что СУБД PostgreSQL тратит основное время на построение плана исполнения запроса для конкретного набора настроек списка данного пользователя.

Шаг 2. Сброс и очистка настроек формы через интерфейс программы

Разберем стандартный способ сброса пользовательских настроек без применения программного кода. Выполнить эту операцию необходимо от имени Администратора системы:

Перейдем в раздел Администрирование — Настройки пользователей и прав.
Раскроем блок Персональные настройки пользователей и выберем пункт Очистка настроек.
В поле выбора пользователя укажем сотрудника, у которого возникает проблема.
Переключим флаг в положение Отдельные настройки.
В дереве настроек найдем раздел Справочник.Сотрудники и удалим все элементы, связанные с внешним видом формы и настройками динамического списка.

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

Шаг 3. Программное удаление элементов из хранилищ настроек

Если штатная очистка через интерфейс БСП не принесла результата, выполним программную очистку сохраненных данных формы списка справочника Сотрудники для целевого пользователя. Для этого запустим внешнюю обработку или выполним код в режиме Внешняя обработка / Программирование:


ИмяПользователя = "ПроблемныйКадровик"; // Укажите имя пользователя ИБ
ПользовательСсылка = Пользователи.НайтиПоИмени(ИмяПользователя);

Если ЗначениеЗаполнено(ПользовательСсылка) Тогда
    
    // 1. Очистка настроек динамических списков
    КлючОбъекта = "Справочник.Сотрудники.Форма.ФормаСписка/НастройкиДинамическогоСписка";
    ХранилищеПользовательскихНастроекДинамическихСписков.Удалить(КлючОбъекта, Неопределено, ИмяПользователя);
    
    // 2. Очистка настроек данных форм
    КлючФормы = "Справочник.Сотрудники.Форма.ФормаСписка";
    ХранилищеНастроекДанныхФорм.Удалить(КлючФормы, Неопределено, ИмяПользователя);
    
    // 3. Очистка системных настроек формы
    ХранилищеСистемныхНастроек.Удалить(КлючФормы, Неопределено, ИмяПользователя);
    
    Сообщить("Настройки справочника 'Сотрудники' успешно очищены для пользователя: " + ИмяПользователя);
Иначе
    Сообщить("Пользователь не найден!");
КонецЕсли;

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

Шаг 4. Переиндексация полнотекстового поиска (ППД)

При поиске по фамилии или иным текстовым реквизитам в 1С:ЗУП 3.1 задействуется механизм полнотекстового поиска. В случаях, когда индекс замусорен или содержал неактуальные ссылки, поиск у конкретных пользователей может вызывать длительное зависание сеанса. Проанализируем действия по сбросу индекса:

Откроем раздел Администрирование — Поддержка и обслуживание.
Перейдем в подраздел Регламентные операции — Управление полнотекстовым поиском.
Нажмем кнопку Очистить индекс.
После завершения очистки нажмем кнопку Обновить индекс и дождемся окончания фонового задания.

Шаг 5. Очистка сеансовых данных кластера и обновление платформы

Если очистка настроек и индексов не помогла, причиной проблемы могут быть зависшие кэши рабочих процессов кластера 1С и несовершенство оптимизатора релиза платформы 8.3.11.

Рассмотрим порядок технического обслуживания сервера:

Остановим службу кластера серверов 1C:Enterprise 8.3 Server Daemon.
Остановим службу базы данных PostgreSQL.
Перейдем в каталог данных кластера 1С (по умолчанию C:\Program Files\1cv8\srvinfo\reg_1541 для Windows или /var/1C/v8.3/srinfo для Linux).
Очистим папки временных файлов сеансов и рабочих процессов (файлы вида snaccnt*, папки временно создаваемых сессий).
Запустим службу PostgreSQL и службу кластера 1С.
При возможности выполним обновление платформы 1С:Предприятие с устаревших версий (таких как 8.3.11.3034) на более актуальные релизы (ветки 8.3.2x), в которых существенно оптимизирована работа с планировщиком запросов PostgreSQL при формировании динамических списков.

Следование описанному алгоритму позволяет полностью устранить торможение справочника у индивидуального пользователя, сохранив его учетную запись, права доступа и историю работы в базе данных.