С развитием платформы 1С и внедрением технологии «живого поиска» многие пользователи и администраторы столкнулись с неприятной проблемой: при попытке найти товар в справочнике или документ в журнале система «намертво» зависает. Особенно остро эта проблема проявилась в ветке платформы 8.3.10, но она может встречаться и в более поздних релизах из-за специфических настроек базы данных или серверного окружения.
В рамках этой статьи мы подробно разберем, почему возникают подобные «висюки», проанализируем технические причины на уровне СУБД и предложим пошаговый алгоритм действий для восстановления нормальной работы системы. Мы рассмотрим как административные методы, так и программные способы оптимизации.
Разберем ситуацию, которая чаще всего встречается на платформе 8.3.10. Проблема заключается в том, что механизм прерывания предыдущего запроса при вводе нового символа в строке поиска работает некорректно. Когда пользователь начинает быстро набирать текст, система инициирует фоновые запросы к серверу. Если база большая (например, более 40 Гб), запросы не успевают обрабатываться и «наслаиваются» друг на друга, вызывая блокировку основного потока интерфейса.
Как решить: Первым делом необходимо проверить версию платформы. Официально данная ошибка (под номером 10179066) была исправлена в релизе 8.3.10.2375. Если вы используете версию ниже этой, настоятельно рекомендуем выполнить обновление. Практика показывает, что переход на актуальные сборки (8.3.12 и выше) полностью устраняет зависания, связанные именно с недоработкой алгоритма динамических списков.
Если обновление платформы не помогло или вы уже используете свежий релиз, проанализируем состояние полнотекстового индекса. Полнотекстовый поиск — это вспомогательный механизм, который хранит свои индексы отдельно от таблиц SQL в специальных файлах в каталоге кластера. Часто индекс «бьется» или переполняется, что приводит к разрыву соединения с сервером баз данных.
Рассмотрим порядок действий для очистки и пересоздания индекса:
Если стандартная обработка зависает при попытке входа, выясним, как решить проблему радикальным (физическим) способом. Выполним следующие шаги:
1C:Enterprise 8.3 Server Agent.C:\Program Files\1cv8\srvinfo\reg_1541\<GUID_вашей_базы>\1Cv8FTxt.1Cv8FTxt.Важный нюанс: Проверьте параметр Максимальный размер индекса. По умолчанию он может быть ограничен 1 Мб. Для крупных баз данных это значение следует увеличить до 50-100 Мб, чтобы избежать частого слияния фрагментов индекса, которое блокирует работу пользователей.
Проанализируем ситуацию, когда зависания происходят только у определенных групп пользователей. Часто виновником становится механизм RLS (Row Level Security) — разграничение доступа на уровне записей. Когда пользователь вводит текст в строку поиска, 1С формирует сложный SQL-запрос, в который «подмешиваются» условия прав доступа.
Если условия RLS написаны неоптимально (содержат вложенные запросы к тяжелым таблицам или не используют индексированные поля), итоговый SQL-запрос может выполняться десятки секунд. MS SQL Server при этом может столкнуться с проблемой Parameter Sniffing, когда один раз построенный план запроса становится неэффективным для других поисковых строк. Для диагностики таких ситуаций и анализа проблемных запросов на стороне СУБД можно использовать обработку для анализа нагрузки и запросов SQL-сервера.
Для решения этой проблемы мы рекомендуем:
EXEC sp_updatestats;
DBCC FREEPROCCACHE;
Иногда типовые механизмы поиска работают слишком «широко», пытаясь искать совпадение по всем полям сразу. Рассмотрим пример оптимизации через событие ОбработкаПолученияДанныхВыбора. Если мы знаем, что пользователи чаще всего ищут номенклатуру по артикулу, мы можем программно ограничить нагрузку на систему, запретив поиск при вводе слишком короткой строки.
Посмотрим на пример реализации в модуле менеджера объекта:
Процедура ОбработкаПолученияДанныхВыбора(ДанныеВыбора, Параметры, СтандартнаяОбработка)
// Если введено меньше 3 символов, не запускаем тяжелый поиск
Если СтрДлина(Параметры.СтрокаПоиска) < 3 Тогда
СтандартнаяОбработка = Ложь;
Возврат;
КонецЕсли;
// Дополнительная логика поиска по специфическим полям
// ...
КонецПроцедуры
Такой подход позволяет значительно снизить количество «пустых» и тяжелых запросов к базе данных, когда пользователь вводит только первую букву или цифру.
Не забудем проверить настройки серверного окружения. Поскольку полнотекстовый индекс состоит из множества мелких файлов, работа с ними критически зависит от скорости дисковой подсистемы и отсутствия внешних блокировок. Выясним, что может мешать системе:
rphost. Это вызывает задержки и ошибки доступа. Решение: Добавьте папку srvinfo (и все её подпапки) в исключения антивирусного сканирования.Подводя итог, можно сказать, что решение проблемы зависания при поиске требует комплексного подхода. В первую очередь необходимо обновить платформу, так как это устраняет большинство известных багов «живого поиска». Во вторую очередь — обслуживать полнотекстовый индекс: регулярно выполнять его слияние и при необходимости полную перегенерацию. При большом количестве систем архивирование, обновление и тестирование нескольких информационных баз 1С можно выполнять автоматически по расписанию.
Если же проблема остается, следует переходить к анализу технологического журнала (ТЖ) для выявления конкретных длительных SQL-запросов и оптимизации условий RLS. Помните, что комфортная работа пользователя в современных решениях 1С напрямую зависит от качества настройки серверной части и актуальности программного обеспечения. Для быстрой расшифровки полученных из журнала запросов в термины метаданных 1С подойдёт обработка для перевода SQL-запросов в имена объектов конфигурации.