Многие технические специалисты и администраторы систем на базе 1С:Управление торговлей 11 (УТ 11) сталкиваются с ситуацией, когда форма подбора товаров начинает работать крайне медленно. Проблема проявляется специфично: открытие формы или переход по иерархии групп занимает от 8 до 30 секунд, хотя стандартный «Замер производительности» в Конфигураторе показывает ничтожно малое время выполнения серверного кода (сотые доли секунды). В этой статье мы подробно разберем причины такого поведения системы, проанализируем влияние данных на производительность СУБД PostgreSQL и предложим конкретные шаги по оптимизации.
Рассмотрим ситуацию, когда по секундомеру мы видим задержку в 10 секунд, а замер фиксирует лишь 0,06 сек. Проанализируем, куда уходит основное время. Существует две основные причины такого расхождения:
ТаблицаЗначений в памяти формы или массив структур), платформа тратит значительное время на упаковку этих данных в XML или бинарный формат. Эти затраты не попадают в замер кода, так как это работа самой платформы.Выясним одну из самых неочевидных причин торможения. Как показывает практика, подбор начинает виснуть, если в системе зарегистрирован документ УстановкаЦенНоменклатуры с датой, которая больше (позже) даты текущего документа продажи. Рассмотрим механизм, который к этому приводит:
Когда мы открываем подбор из заказа или реализации, система формирует запрос к регистру сведений ЦеныНоменклатуры, используя конструкцию «Срез последних» на дату документа. Если в регистре появляется много записей с периодом «из будущего», планировщик запросов PostgreSQL может ошибочно выбрать метод полного сканирования индекса (Index Scan) вместо быстрого поиска. Это происходит из-за того, что СУБД приходится перебирать большое количество записей, чтобы убедиться, какая именно цена была актуальна на «прошлую» дату документа.
Особенно остро это проявляется в старых документах. Если менеджер создал заказ неделю назад, а сегодня установил новые цены, то при попытке отредактировать старый заказ подбор будет тормозить, так как система ищет цены в огромном массиве данных, накопленных за прошедшее время.
Проанализируем влияние индивидуальных соглашений с клиентами. Если в соглашении указаны уточнения по ценовым группам, запрос динамического списка в подборе становится крайне «тяжелым». Для каждой строки номенклатуры система должна выполнить:
При отключении иерархии в списке (режим «Список»), СУБД пытается обработать весь массив номенклатуры сразу, что при наличии сложных соединений по соглашениям приводит к зависанию формы на десятки секунд.
Разберем ситуацию, когда сервер 1С и сервер СУБД разнесены по разным виртуальным машинам. В этом случае критическим фактором становится сетевая задержка (latency). Поскольку динамический список при прокрутке или смене групп генерирует множество мелких запросов, задержка даже в 1-2 мс на каждый запрос суммируется.
Рекомендация: Если есть возможность, используйте протокол Shared Memory, разместив сервер 1С и СУБД на одном физическом сервере (или внутри одной ОС). Если это невозможно, убедитесь, что виртуальные машины находятся на одном гипервизоре и общаются через виртуальный коммутатор с минимальными задержками.
Рассмотрим конкретные действия, которые помогут вернуть скорость подбору товаров:
Проверьте настройки списка внутри формы подбора. Часто пользователи случайно устанавливают сортировку по полям, которые не индексированы (например, по реквизитам через точку). Попробуйте сбросить настройки формы в значение по умолчанию. Выясним, не включены ли лишние колонки: отображение остатков в разрезе всех складов или расчет цен «на лету» для всех видов цен сразу значительно замедляют работу.
Выполните обслуживание таблиц, связанных с ценами. Для этого используйте команды REINDEX и ANALYZE. В консоли СУБД это выглядит примерно так:
-- Пересоздание индексов для таблицы цен (имя таблицы может отличаться в зависимости от версии)
REINDEX TABLE _InfoRg12345;
-- Обновление статистики распределения данных
ANALYZE _InfoRg12345;
Это заставит планировщик PostgreSQL строить более оптимальные планы запросов, особенно при работе со срезом последних.
Если у вас установлены расширения (например, от сторонних разработчиков), временно отключите их и проверьте скорость. Обратите внимание на обработчик ПриПолученииДанныхНаСервере. Если в нем реализован обход строк в цикле с запросами к базе, это гарантированно приведет к тормозам. Пример неправильного кода, который нужно оптимизировать:
&НаСервере
Процедура Расширение_ПриПолученииДанныхНаСервере(ИмяОформления, Настройки, Строки)
Для Каждого Строка Из Строки Цикл
// ТАК ДЕЛАТЬ НЕЛЬЗЯ: Запрос в цикле убивает производительность
Строка.Значение.ДополнительныйРеквизит = ПолучитьДанныеИзБазы(Строка.Ключ);
КонецЦикла;
КонецПроцедуры
Вместо этого следует использовать пакетные запросы для всех ключей строк сразу.
В настройках подбора товаров (кнопка «Еще» — «Настройки») попробуйте отключить флаги отображения остатков и цен. Если после этого форма начала «летать», значит, проблема локализована в запросах к соответствующим регистрам (ЦеныНоменклатуры или ЗапасыИПотребности).
Хотя автор темы пробовал отключать ПП, стоит убедиться, что индекс действительно актуален. Иногда «зависшее» задание обновления индекса блокирует работу с таблицами номенклатуры. Рекомендуется полностью очистить индекс и пересоздать его в консоли администрирования серверов 1С.
Подводя итог, можно сказать, что проблема торможения подбора в УТ 11 чаще всего носит комплексный характер. Сочетание цен с будущими датами, сложных индивидуальных соглашений и особенностей работы PostgreSQL создает эффект «бутылочного горлышка», который сложно отловить обычным замером производительности. Используйте приведенные выше инструкции для планомерной диагностики вашей базы.