Работа в программе 1С:Управление торговлей 11.5 часто сопряжена с интенсивным использованием окна подбора товаров. Одной из наиболее критичных проблем, с которой сталкиваются пользователи после обновления платформы или конфигурации, является полное зависание интерфейса при попытке найти товар с включенным флагом «В наличии на складе». Проблема осложняется тем, что по отдельности функции могут работать корректно: полнотекстовый поиск (ППД) ищет товары, а фильтр остатков отображает наличие. Однако их совместное использование приводит к «мертвому» зависанию на несколько минут или до завершения сеанса.
В этой статье мы подробно разберем, почему возникает эта ситуация, как диагностировать узкие места и какие шаги необходимо предпринять для восстановления быстродействия системы. Мы проанализируем взаимодействие механизмов полнотекстового поиска и запросов к регистрам накопления, а также рассмотрим влияние настроек сервера СУБД.
Для начала проанализируем ситуацию: когда в форме подбора активен полнотекстовый поиск, система сначала обращается к индексу ППД, чтобы получить список подходящих ссылок на номенклатуру. Как только мы включаем флаг «В наличии», динамический список формы подбора модифицирует свой текст запроса. Теперь он должен не просто вывести список товаров, но и соединить его (через JOIN) с виртуальной таблицей остатков регистра ЗапасыНаСкладах (или ТоварыНаСкладах в зависимости от настроек).
Если в базе данных сотни тысяч позиций номенклатуры, и поиск выдает широкий результат (например, по части артикула), формируется огромная временная таблица. Попытка наложить на нее остатки в реальном времени создает колоссальную нагрузку на дисковую подсистему и процессор сервера. Рассмотрим подробнее основные причины деградации производительности в этом узле.
Прежде чем менять настройки, нам необходимо выяснить, на чем именно «затыкается» система. Выясним причину с помощью штатных инструментов. Первым делом выполним замер производительности в конфигураторе. Если замер не показывает конкретную строку кода (так как зависание происходит внутри динамического списка, то есть на стороне СУБД), нам потребуется Технологический журнал (ТЖ).
Настроим сбор событий DBMSSQL (или DBPOSTGRS) и SDBL с длительностью выполнения более 10–20 секунд. Проанализируем полученный лог. Если мы видим запрос, который выполняется 400-500 секунд, это подтверждает, что проблема в неоптимальном плане запроса SQL. Пример настройки logcfg.xml для отлова тяжелых запросов:
<config xmlns="http://v8.1c.ru/8.0/tech-log">
<dump location="C:\dumps" create="true" save="10"/>
<log location="C:\logs\sql_trace" history="2">
<event>
<eq property="Name" value="DBMSSQL"/>
<gt property="Duration" value="10000000"/>
</event>
<property name="all"/>
</log>
</config>
Обратите внимание на свойство Duration. После получения текста запроса из лога, его можно проанализировать в консоли SQL Server Management Studio (SSMS), построив план выполнения.
Рассмотрим ситуацию, описанную многими администраторами: при отключенном полнотекстовом поиске включение флага «В наличии» вешает базу на 7–10 минут. Это классический симптом проблемы с итогами регистров накопления. Когда дата рассчитанных итогов значительно отстает от текущей даты (или в базе есть документы, проведенные «будущим числом»), 1С не может использовать готовую таблицу итогов.
Вместо этого сервер вынужден вычислять остатки «на лету», сканируя всю таблицу движений регистра (_AccumRegTotals превращается в сканирование _AccumRegChangeRec). Чтобы исправить это, выполним следующие действия:
ЗапасыНаСкладах и ТоварыНаСкладах.После обновления платформы (например, переход на последние релизы ветки 8.3.25) старые планы запросов в кеше SQL могут стать неэффективными. Платформа начинает иначе формировать запросы SDBL, и оптимизатор СУБД может ошибочно выбрать Index Scan вместо Index Seek.
Проанализируем ситуацию на стороне сервера БД. Рекомендуется выполнить регламентные операции:
_FullTextIndex.Для MS SQL Server это можно сделать простым скриптом в SSMS или через планы обслуживания (Maintenance Plans).
Разберем, почему штатная работа ППД может мешать подбору. Полнотекстовый поиск в 1С работает по принципу поиска с начала слова. Если пользователь вводит короткое сочетание цифр, которое встречается в середине артикулов, ППД может выдать слишком много результатов или, наоборот, не найти ничего, если не настроены правила разделения слов. При необходимости скорректировать работу механизма можно применить обработку для смены версии полнотекстового поиска.
Важный момент: в новых версиях УТ 11.5 в окне подбора можно переключить режим поиска. Если нажать «Настройки» (или «Еще» — «Настройки»), проверьте пункт «Способ поиска». Там может быть доступен выбор между «Полнотекстовым поиском» и «Поиском по строке». Поиск по строке использует конструкцию LIKE %Текст%. Хотя он считается более медленным для огромных справочников, он работает гораздо стабильнее в связке с фильтрами по остаткам, так как весь запрос выполняется в рамках одного обращения к SQL, без участия промежуточного индекса ППД. Для реализации удобного и быстрого поиска в подборе также можно использовать инструмент гибкого поиска в списках и формах выбора.
Если зависания продолжаются, существует вероятность повреждения самих файлов индекса полнотекстового поиска на сервере. Рассмотрим шаги по их принудительному обновлению:
FTXT в папке сервера 1С.Также не лишним будет очистить кеш сервера 1С. Для этого необходимо остановить службу Agent 1C:Enterprise, зайти в папку srvinfo и удалить содержимое папок snccntx и папок с GUID-именами баз (кроме файлов конфигурации).
Проанализируем еще одну скрытую причину. Если у пользователя, у которого зависает подбор, включены ограничения прав (например, он видит только свой склад или только определенную группу номенклатуры), то любой запрос к остаткам «обрастает» огромным количеством дополнительных условий WHERE. В новых версиях УТ шаблоны RLS стали более универсальными, но и более тяжелыми.
Проверим гипотезу: запустим подбор под пользователем с полными правами. Если под полными правами зависания исчезают, значит проблема в производительности RLS. В этом случае стоит рассмотреть переход на «Производительный режим» ограничений прав (настраивается в разделе Общие настройки — Группы доступа).
Зависание поиска в подборе УТ 11.5 — это комплексная проблема. Чаще всего она решается не «игрой» с флажками, а системным подходом к обслуживанию базы данных. Посмотрим на краткий чек-лист действий:
RLS.Соблюдение этих рекомендаций позволяет сократить время отклика окна подбора с нескольких минут до долей секунды, обеспечивая комфортную работу менеджеров по продажам.