← На главную

Разработчики и администраторы крупных баз данных на платформе 1С:Предприятие 8.3 часто сталкиваются с ситуацией, когда стандартная форма подбора номенклатуры в документе начинает сильно «тормозить» при открытии. Время ожидания может составлять от 15 до 50 секунд даже при относительно небольшом объеме справочника (например, около 40 000 позиций без характеристик). При этом замер производительности показывает, что основное время уходит на метод ОткрытьФорму, а загрузка процессора сервера приложений и СУБД остается минимальной (5–10%).

Особенно загадочно выглядит ситуация, когда под одной учетной записью (например, с полными правами) форма подбора открывается за 2–4 секунды, а под рабочим пользователем процесс зависает почти на минуту. В этой статье мы подробно разберем, почему возникает эта проблема, проанализируем технические нюансы работы динамических списков в управляемых формах и рассмотрим пошаговые инструкции по устранению задержек.

Выясняем первопричину: сервер 1С или СУБД?

Для начала нам необходимо локализовать, где именно происходит задержка: на стороне сервера СУБД (выполнение SQL-запроса) или на стороне сервера приложений 1С (сериализация данных, передача контекста, обработка на клиенте). Для этого выполним несколько последовательных шагов. Для раздельного анализа этих этапов можно использовать отчет для замера времени выборки, передачи и вывода данных в УТ 11.

Воспользуемся встроенным инструментом платформы — Замером производительности. Если замер показывает, что строка с вызовом ОткрытьФорму занимает более 80% времени, а серверный вызов ПриСозданииНаСервере отрабатывает относительно быстро, это верный признак того, что задержка происходит на этапе компоновки и выполнения запросов динамических списков при выводе данных на экран.

Для точной диагностики снимем трассировку запросов на стороне SQL-сервера с помощью утилиты SQL Server Profiler (или механизма Extended Events). Нам необходимо зафиксировать запросы, которые отправляет платформа 1С при открытии формы подбора. Проанализируем показатели Duration (время выполнения) и Reads (количество чтений с диска/из памяти):

1. Если суммарное время выполнения SQL-запросов близко к общему времени «зависания» формы, значит, СУБД строит неоптимальный план выполнения запроса динамического списка.
2. Если SQL-запросы отрабатывают мгновенно (за доли секунды), но форма все равно открывается долго, проблема кроется в сериализации данных на сервере 1С. В этом случае ключевую роль играет производительность одного (single) ядра процессора, на котором выполняется рабочий процесс 1С rphost. Старые процессоры с низкой тактовой частотой (например, архивные линейки Intel Xeon с частотой около 2.5–3.0 GHz старых поколений) физически не могут быстро переварить сложную структуру управляемой формы с несколькими динамическими списками.

Причина 1. Влияние ограничений прав на уровне записей (RLS)

Это классическая причина колоссальной разницы в скорости работы под разными пользователями. В конфигурации «1С:Управление торговлей 11» активно используется механизм RLS (Row Level Security) для разграничения доступа к складам, контрагентам, организациям или группам номенклатуры.

Когда форму подбора открывает пользователь с полными правами, платформа генерирует «чистый» SQL-запрос к таблицам остатков и цен. Но когда форму открывает пользователь с ограниченными правами, платформа 1С на лету модифицирует исходный запрос динамического списка, внедряя в него тяжелые подзапросы со множеством соединений для проверки прав доступа.

В результате СУБД строит совершенно другой план запроса, который может приводить к полному сканированию таблиц (Index Scan или Table Scan) вместо использования эффективных индексов. Время выполнения запроса вырастает в десятки раз.

Для решения этой проблемы выполним следующие действия:

1. Проверим, включен ли в базе данных производительный режим RLS. Перейдем в раздел НСИ и администрирование — Настройка пользователей и прав — Группы доступа и убедимся, что используется оптимизированный вариант работы с ограничениями.
2. Если это возможно по регламенту безопасности организации, временно назначим «проблемному» пользователю роль без ограничений RLS (или полные права) и проверим скорость открытия формы. Если форма открылась мгновенно, проблема однозначно в шаблонах ограничений прав доступа.
3. Оптимизируем настройки групп доступа: постараемся минимизировать количество условий (например, вместо ограничений по конкретным менеджерам или складам использовать более общие правила).

Причина 2. Пользовательские настройки динамических списков

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

Типичный пример: пользователь случайно кликнул по шапке колонки «Доступно», «Остаток» или «Цена», чтобы отсортировать товары. В форме подбора УТ 11 эти поля являются расчетными (виртуальными). Для вывода списка с такой сортировкой СУБД вынуждена рассчитать остатки и цены абсолютно по всем 40 000 позициям номенклатуры, отсортировать этот гигантский массив в оперативной памяти и только потом вернуть первые 30 строк на экран. В то же время у другого пользователя, у которого сортировка установлена по умолчанию (по коду или наименованию), СУБД мгновенно выдает первые строки благодаря индексам.

Для исправления этой ситуации выполним сброс настроек по шагам:

1. Зайдем под проблемным пользователем в форму подбора.
2. Нажмем кнопку Еще — Изменить форму, в открывшемся окне нажмем кнопку Еще — Установить стандартные настройки.
3. Нажмем кнопку Еще — Настроить список и выберем команду Установить стандартную настройку на вкладках отборов, сортировки и группировки.
4. Если доступ к интерфейсу пользователя затруднен, администратор системы может очистить его настройки централизованно через меню НСИ и администрирование — Поддержка и обслуживание — Управление настройками пользователей, где можно полностью удалить сохраненные настройки форм и историю выбора для конкретной учетной записи.

Причина 3. Контекст открываемого документа (склады и соглашения)

Форма подбора в УТ 11 не открывается «сама по себе» — она жестко привязана к контексту документа, из которого была вызвана. При инициализации формы в ее динамические списки передаются параметры: склад, соглашение, организация, валюта, дата документа.

Разберем, как эти параметры влияют на скорость работы:

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

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

Причина 4. Параметрический сбой (Parameter Sniffing) в MS SQL Server

Иногда СУБД MS SQL Server некорректно кэширует планы выполнения для параметризованных запросов, генерируемых платформой 1С. Это явление называется Parameter Sniffing. При первом вызове динамического списка (например, под администратором с определенным набором параметров) SQL Server строит план, оптимизированный под эти конкретные параметры. В дальнейшем, когда обычный пользователь с другими параметрами открывает ту же форму, SQL Server пытается применить старый закэшированный план, который оказывается крайне неэффективным.

Для исправления этой ситуации выполним профилактическое обслуживание базы данных на уровне СУБД:

1. Обновим статистику базы данных. Для этого в SQL Server Management Studio (SSMS) выполним следующий скрипт:
   Скопировать код

   
   USE [Имя_Вашей_Базы_Данных];
   EXEC sp_updatestats;
   

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

   
   USE [Имя_Вашей_Базы_Данных];
   DBCC FREEPROCCACHE;
   

3. Настроим регулярное регламентное задание в SQL-агенте для обновления статистики (например, каждую ночь или несколько раз в день с параметром FULLSCAN для критически важных таблиц регистров остатков и цен).

Причина 5. Избыточность динамических списков и доработка формы

Если все вышеперечисленные административные меры не принесли желаемого результата, а переходить на более мощное серверное оборудование (с высокой частотой процессора на одно ядро, например от 4.0 GHz) нет возможности, придется прибегнуть к оптимизации самого механизма подбора.

В типовой УТ 11 форма подбора содержит до 5 динамических списков, которые инициализируются и отправляют запросы одновременно при открытии формы. Мы можем пойти по пути разумного упрощения формы подбора через механизм расширений конфигурации (без изменения основной конфигурации, чтобы сохранить ее на поддержке):

1. Создадим расширение конфигурации и добавим в него форму подбора номенклатуры.
2. Отключим автоматическое обновление тех динамических списков, которые не требуются пользователю в первую секунду открытия формы (например, дерево групп номенклатуры, список ранее выбранных товаров или сопутствующие товары).
3. Настроим инициализацию и выполнение запросов этих списков по требованию (например, при переходе пользователя на соответствующую вкладку или по нажатию кнопки).
4. В свойствах основных динамических списков установим свойство ДинамическоеСчитываниеДанных в значение Истина и ограничим количество выбираемых записей на одну страницу (свойство ПорцияПриЗапросе). Это позволит СУБД отдавать данные небольшими порциями, существенно снижая время ожидания первой порции данных на клиенте.

Применяя данные методики комплексно — от анализа технологического журнала и SQL-трассировки до сброса пользовательских настроек и оптимизации планов СУБД — мы сможем гарантированно вернуть скорость открытия формы подбора номенклатуры к комфортным 1–3 секундам, обеспечив стабильную и быструю работу пользователей в системе. Для регулярного выполнения профилактических работ, включая архивирование и тестирование баз по расписанию, можно использовать инструмент для автоматизации обслуживания 1С.