Стал тормозить динамический поиск в формах в комплексной автоматизации. Стала тормозить после какого то обновления, толи после включения производства 2.5, толи если после чегото не понятно.
Открываешь форму, например, документы продажи, или производства, где несколько документов, и есть единое поле для поиска по всем полям. При вбивании в это поле названия контрагента, у некоторых пользователей зависает от 5 сек до 10 минут. У некоторых работает быстро (3-5 сек).
Есть RLS. Пробовал отключать, не помогает. Пробовал замер производительности, не отловил, все быстро, на чем зависает отладкой не показывает. Пробовал делать тестирование со всеми галками, отключал включал полнотекстовый поиск, результата ноль. Помогите куда копать?
КА - 2.5.9.143
Платформа 8.3.22.1704 (x32- клиент + x64 сервер 1с)
MS SQL.
(19) Ага, спасибо, уже увидел что пользователь добавлен в тучу груп доступа, возможно он их всех соединяет в запросе на этом тормоза... Попробовал добавить в одну группу - тормоза теже...(
В общем методом тыка)
Похоже помогло по шагам следующее:
1) Очисктка файла полнотекстого поиска
2) Отключение полнокстого поиска
3) Отключение RLS
4) перевод режима RLS с производительного на стандартный
5) Включение RLS
6) Отключение части колонок в динамичесокм списке, спасибо (7)
Вроде сейчас работает более менее. Буду завтра пробовать, когда все в базу зайдут, и на том торомзном ПК.
(1) На форме только динамический список? Нет ли выводимых табличных частей? Если есть, исключите поиск по ним через метод динамического списка УстановитьОграниченияИспользованияВОтборе.
(2) У одних и техже. Кэш им чистил не помогает. (удалял базу из списка и заново добавлял)
Оно как то не системно проявляется, один раз засек у себя под администратором, но было один раз!
Чаще всего по моему опыту стандартные, не доработанные динамические списки начинают тормозить из за сортировки. Которая включается случайно, нажатием на шапку колонки дин.Списка
На тормозном компе, При замере производительности
Показывает тормоза на строке в модуле ОбщийМодуль.ДлительныеОперации.Модуль
646 строка:
Задание = Задание.ОжидатьЗавершенияВыполнения(ПараметрыВыполнения.ОжидатьЗавершение);
вызов - 1, время - 0,289349 в процентах - 59,39%
Общее время 0.28, хотя зависание несколько минут... Толи фоновые задания какие то, то что не понятно...
(14) Запустил на сервере напрямую, где под админом не тормозило, Зашел под тормозным пользователем, и тормоза появились. Похоже все таки в RLS дело. Кто то писал что на новой платформе 8.3.22.1704 есть проблема с RLS, может в этом дело.
"Единое поле поиска по всем полям" иногда (обычно почти всегда) юзает помимо сверхгигантских неоптимальных запросов еще и полнотекстовый поиск. Если его снести, то только одно это иногда дает эффект. У Юры Премитина про это была большая и хорошая статья, но злобные буратины из 1Са изгнали его с этого сайта. Но в гугле все есть.
https://infostart.ru/1c/articles/1056842/ - вот статья, не знаю, его ли.
(17) А там (в статье) вообще про его включение сказано, что поможет, если все отображаемые поля динамического списка будут попадать в полнотекстовой поиск. Там вообще объемная статья, я вот даже подзабыл, оказывается, что Юра предлагал как раз включить полнотекстовой поиск и убрать все поля из списка, которые в полнотекстовой поиск не включены. Ну и посмотреть, работают ли РЗ перестроения и слияния.
В общем испробовал все что можно, реально что более менее помогает, это олтключение RLS. без разграничения прав на уровне записей работает относительно быстро (до 7 секунд).
Не хочется RLS отключать.
(18) У Гилева в курсе по оптимизации запросов было замечание что использование двух разных ролей для доступа к одному тому же объекту равноценно использованию ИЛИ, что может замедлять запрос. Может быть посмотреть в этом направлении...
(19) Ага, спасибо, уже увидел что пользователь добавлен в тучу груп доступа, возможно он их всех соединяет в запросе на этом тормоза... Попробовал добавить в одну группу - тормоза теже...(
В общем методом тыка)
Похоже помогло по шагам следующее:
1) Очисктка файла полнотекстого поиска
2) Отключение полнокстого поиска
3) Отключение RLS
4) перевод режима RLS с производительного на стандартный
5) Включение RLS
6) Отключение части колонок в динамичесокм списке, спасибо (7)
Вроде сейчас работает более менее. Буду завтра пробовать, когда все в базу зайдут, и на том торомзном ПК.
(1) была аналогичная проблема в форме списка журнала документов на ЕРП;
возможно проблема в том, что реквизит Документ составного типа и может быть разных типов, и вероятно RLS эту ситуацию отрабатывает криво ...
В качестве решения сделал расширение в котором переопределил все роли работающие с объектом (журнал документов) и для поля Просмотр ставил галочку Разрешить (ограничения убирал). Задолбался если честно всё это прокликивать (сразу предупреждаю). Полностью проблему не решило, но лучше стало.
Особо сильно нагружала колонка состояние ЭДО, похоже на ней основное зависание было, в общем сейчас с отключеными лишними колонками работает быстрее.
Вопрос закрыт. Всем спасибо, удачного дня.
Добавлю в тред, может кому поможет:
при поиске в динамическом списке наглухо зависал клиент (потребление памяти не растет, а ЦП грузит).
Помогло отключение условного оформления в форме (оформление перенес в настройки списка).
У нас УНФ на платформе 1С:Предприятие 8.3 (8.3.20.1710)
Уже давно периодически подвисает наглухо при динамическом поиске в журнале заказ покупателя.(полнотекстовый отключен).
Решение не нашли, но выявили что если колонку "комментарий" из журнала убрать, то зависания нет.
Наш выход или колонку отключать или пользоваться поиском через Alt+F.