Многие технические специалисты сталкиваются с ситуацией, когда после перехода на современное оборудование (серверы x64, MSSQL 2019) и свежие релизы платформы 8.3, стандартный поиск в списках начинает вести себя непредсказуемо. Казалось бы, мощное железо должно ускорять процессы, но на практике поиск по коротким строкам проходит мгновенно, а при вводе чуть более длинного запроса система замирает на несколько минут. Проанализируем, почему это происходит и как вернуть системе былую производительность.
Рассмотрим механизм работы поиска в 1С. В платформе существует встроенный механизм — Полнотекстовый поиск (ПП). Важно понимать, что он работает не через стандартные индексы СУБД (MSSQL или PostgreSQL), а использует собственные индексные файлы. Эти файлы хранятся в каталоге сервера 1С (обычно внутри папки srvinfo).
Когда пользователь вводит запрос, например, в журнале заказов, система должна решить: использовать обычный SQL-запрос с оператором LIKE или обратиться к индексам ПП. Если ПП включен, платформа пытается задействовать его для поиска по всем реквизитам. Проблема «зависания» на строках типа «4100» при быстром поиске «410» часто связана с механизмом префиксного расширения запроса и морфологии.
Проанализируем ситуацию по шагам:
IN (...), который «подвешивает» уже сам SQL-сервер.Как показывает практика, в большинстве случаев для оперативной работы в списках (документы, справочники) полнотекстовый поиск не только не помогает, но и вредит. Если ваши пользователи ищут данные по конкретным полям (номер, контрагент, сумма), стандартных индексов базы данных более чем достаточно.
Разберем, как отключить этот механизм:
Важный момент: после отключения ПП система перейдет на использование стандартных SQL-запросов. Поскольку современные процессоры и дисковые подсистемы работают крайне быстро, поиск через LIKE по индексированным полям в 99% случаев будет отрабатывать за 1-2 секунды, что мы и наблюдали в примере с файловой базой.
Если специфика бизнеса требует глобального поиска по всей базе (например, поиск конкретного слова в комментариях или описаниях товаров), и отказаться от ПП нельзя, нужно выполнить глубокую настройку инфраструктуры.
Во-первых, выясним причину задержек при чтении данных. Поскольку индексы ПП — это файлы на диске, критически важно их расположение. Выполним перенос папки srvinfo на максимально быстрые диски NVMe. Использование обычных HDD или даже SATA SSD для нагруженных баз с включенным ПП недопустимо, так как процесс rmngr создает огромную очередь на чтение при выполнении поисковых запросов.
Во-вторых, проанализируем частоту выполнения регламентных заданий. Рассмотрим типичную ошибку: слишком частое обновление индекса. По умолчанию регламентное задание ОбновлениеИндексаПП может запускаться каждую минуту. Если база активно наполняется, индекс не успевает «устояться», что приводит к блокировкам. Рекомендуется настроить интервал обновления в зависимости от интенсивности ввода данных, а полную переиндексацию проводить только в часы минимальной нагрузки.
Часто поиск тормозит из-за того, что система пытается искать введенную строку во всех полях метаданных подряд. Мы можем оптимизировать этот процесс на уровне кода или настроек динамических списков. Проанализируем возможность ограничения области поиска.
Если вы разрабатываете собственную форму или модифицируете существующую, стоит использовать поиск по конкретным колонкам. Вместо общего поиска по списку, предложите пользователям использовать отборы по индексированным реквизитам. В метаданных у важных полей (Артикул, Номер, Код) свойство Индексировать должно быть установлено в значение Индексировать или Индексировать с доп. упорядочиванием.
В последних версиях платформы были замечены специфические особенности работы менеджера кластера. На x64 серверах процесс rmngr может потреблять избыточное количество оперативной памяти именно в моменты обращения к полнотекстовому индексу.
Выясним, не является ли ваша проблема следствием багов платформы:
rmngr в момент «зависания» поиска.Подводя итог, можно сказать: если вы столкнулись с необъяснимыми задержками при поиске в 1С, первым делом попробуйте отключить полнотекстовый поиск. В большинстве случаев это мгновенно решает проблему. Если же функция необходима, сосредоточьтесь на производительности дисковой подсистемы (NVMe) и чистоте индексных файлов, регулярно выполняя их полную пересборку через консоль администрирования или программно с помощью метода ПолнотекстовыйПоиск.ОчиститьИндекс() и последующего обновления.