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

Ситуация, когда информационная база работает быстро у всех сотрудников, кроме одного «счастливчика», — классическая проблема для крупных систем на базе 1С:Управление холдингом или 1С:Документооборот. Часто стандартные советы вроде «почисти кэш» или «перезагрузи компьютер» не помогают. В этой статье мы подробно разберем, почему возникает такая избирательная медлительность, и пройдем по шагам диагностики: от простых настроек до анализа планов запросов SQL-сервера.

Проанализируем первичные симптомы

Рассмотрим ситуацию: пользователь жалуется на зависание программы (до 10 минут) при открытии форм списков (например, «Задачи мне») или при проведении документов. При этом аппаратные ресурсы компьютера (процессор Ryzen 3, 8 ГБ ОЗУ, SSD) в норме, а в терминальном режиме проблема сохраняется. Это сразу говорит нам о том, что дело не в «железе» клиента, а в специфике данных или настроек, привязанных к конкретной учетной записи в 1С.

Шаг 1. Очистка пользовательских настроек и кэша

Прежде чем переходить к тяжелой артиллерии, исключим стандартные факторы. Выясним причину через очистку системных данных:

1. Локальный кэш: Удалим базу из списка и добавим её заново. Это принудительно создаст новые папки в %AppData%\1C\1Cv8.
2. Настройки форм: В режиме 1С:Предприятие перейдем в «Администрирование» — «Настройки пользователей и прав» — «Очистка настроек». Выберем проблемного пользователя и удалим все настройки внешнего вида и отборы.
3. Таблица SystemSettings: Иногда настройки «раздуваются» до таких объемов, что их чтение занимает секунды. Если очистка через интерфейс не помогла, можно рассмотреть очистку на уровне БД (с осторожностью).

Шаг 2. Диагностика механизма RLS (Record Level Security)

Проанализируем наиболее вероятную причину — ограничение прав на уровне записей. Механизм RLS добавляет к каждому SQL-запросу дополнительные условия (подзапросы), проверяющие, имеет ли пользователь право видеть конкретную строку. Если у пользователя сложная иерархия прав или он состоит во множестве групп доступа, итоговый запрос превращается в «монстра» на несколько страниц текста.

Рассмотрим важные нюансы RLS:

• Производительный режим: Убедимся, что в базе включен «Производительный режим» RLS (доступен с платформы 8.3.16). В этом режиме проверка прав опирается на предварительно рассчитанные данные в специальных таблицах, что значительно ускоряет работу.
• Иерархические проверки: Если права настроены по подразделениям с учетом иерархии, 1С приходится каждый раз обходить дерево подчиненности. Для одного пользователя (например, руководителя высокого уровня) это может стать критичным фактором.
• Конфликт ролей: Проверим, нет ли у пользователя «лишних» ролей. Бывают случаи, когда предоставление более широких прав (например, чтение всех процессов) парадоксальным образом ускоряет систему, так как 1С перестает накладывать сложные фильтры RLS.

Шаг 3. Анализ формы «Задачи мне» в 1С:Документооборот

Форма «Задачи мне» — одна из самых ресурсоемких. Она собирает данные из регистров сведений, задач, бизнес-процессов и предметов. Разберем, что может тормозить её открытие у конкретного человека:

1. Замещение и делегирование: Если пользователь является замещающим для нескольких топ-менеджеров, система при каждом открытии списка динамически вычисляет права на все задачи этих руководителей.
2. Очередь обновления прав: В 1С:Документооборот существует регистр ОчередьОбновленияПрав. Если по данному пользователю накопилось много необработанных записей, система может пытаться «досчитать» права в момент обращения, что вызывает фриз.
3. Динамические списки: Проверим настройки динамического списка. Пользователь мог случайно установить сложный отбор или сортировку по неиндексированному полю, что заставляет SQL выполнять Table Scan (полный перебор таблицы).

Шаг 4. Работа с замерщиком производительности

Чтобы не гадать, выполним замер производительности именно под сеансом проблемного пользователя. Посмотрим на примере, как это сделать:

1. Запустим конфигуратор, перейдем в меню «Отладка» — «Подключение».
2. Выберем сеанс пользователя и нажмем «Подключить».
3. Включим замер производительности (кнопка на панели или F12).
4. Попросим пользователя выполнить действие (например, открыть форму).
5. Изучим результат. Обратим внимание на колонку «Чистое время». Если основное время уходит на метод ОткрытьФорму() или ВыполнитьЗапрос(), значит проблема в данных или RLS на уровне сервера БД.

Шаг 5. Проблемы на стороне SQL-сервера (Parameter Sniffing)

Иногда корень зла кроется в кэше планов запросов SQL Server. Выясним причину через механизм Parameter Sniffing. Сервер сохраняет план выполнения запроса, исходя из параметров первого запуска. Если первый раз запрос был выполнен для пользователя с двумя задачами, а у нашего «проблемного» пользователя их две тысячи, старый план будет крайне неэффективным.

Как лечить:

• Обновить статистику по таблицам, связанным с задачами и правами доступа.
• Очистить кэш процедурных планов для конкретной базы (команда DBCC FREEPROCCACHE).
• Настроить регламентное переиндексирование таблиц.

Шаг 6. Использование Технологического журнала (ТЖ)

Если замер производительности не дает четкого ответа (например, время «теряется» где-то между клиентом и сервером), настроим Технологический журнал. Это позволит увидеть реальные SQL-запросы, которые 1С отправляет к базе данных.

Создадим файл logcfg.xml со следующим содержимым для сбора событий DBMSSQL:

<config xmlns="http://v8.1c.ru/7.4/get/logcfg">
  <log location="C:\LOGS\SQL_Slow" history="2">
    <event>
      <eq property="Name" value="DBMSSQL"/>
      <gt property="Duration" value="100000"/> <!-- фиксируем запросы дольше 0.1 сек -->
    </event>
    <property name="All"/>
  </log>
</config>

Проанализировав полученный лог, мы увидим текст запроса. Если в нем присутствуют конструкции WHERE 0=1 или бесконечные JOIN к таблицам прав — мы нашли виновника в лице RLS.

Резюме и практические советы

Разберем краткий чек-лист для исправления ситуации:

1. Проверьте дубли пользователей: Убедитесь, что в справочнике «Пользователи» и «Физические лица» нет дублей, которые могут конфликтовать в регистрах расчета прав.
2. Эксперимент с правами: Временно дайте пользователю полные права. Если тормоза исчезли — проблема на 100% в настройках RLS или сложности групп доступа.
3. Копия базы: Если на копии базы (развернутой из бэкапа) под этим же пользователем всё работает быстро — проблема в статистике SQL или серверном кэше текущего инстанса. Поможет реиндексация.
4. Сетевой фактор: Если пользователь работает через VPN, проверьте размер пакетов MTU. Из-за специфических прав объем передаваемых данных формы может быть выше, что при фрагментации пакетов дает эффект «зависания».

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