1с зависает поиск в динамическом списке
Для динамического списка используется произвольный запрос, основная таблика Справочник.Контрагенты, к ней используются соединения для получения "Сектора" (Справочник.Сектора) и "Города" (Справочник.Города). Далее это все изпользуется в группировки, чтобы в динамическом списке все выглядело в виде дерева Сектор --> Город --> Контрагент. Но вот незадача, динамический список в котором около 100 элементов в такой вложенности группировок при обновлении (F5) очень сильно зависает на 5-10 секунд. Если группы все свернуть то тормозить перестает. Проверял сам запрос, работает быстре. Почему при группировках тормозит динамический списак и как это лечить?
Запрос собирает задания по контрагентам и распределяет их по датам, т.е. выводит некий календарь на неделю сколько заданий на какую дату у конкретного контрагента. РегистрСведений.Задания.СрезПоследних КАК ЗаданияСрезПоследних
Какие задействованы настройки в динамическом списке, кроме группировок? Отбор, сортировка, оформление?
Можно попробовать переписать СрезПоследних в соединениях на свой код, кода будет больше, но и эффективность скорее всего будет выше.
Кстати, в ты пишешь про секторы и города, в запросе чего-то не хватает. Или для группировки поля берутся через точку?
>> Если группы все свернуть то тормозить перестает А если совсем убрать группировки, то хоть какие-то тормоза ощущаются?
Да, в запросе нехватает секторов, потому что пришлось от них избавится от тормозов. Т.е. уменьшив количество уровней. Если запрос такой и оставить а группировки убрать - тормоза сразу проходят. Пробовал без запроса на основной таблице. Сделал несколько группировок и пошли тормоза. Релиз последний 205
Посмотрел у себя. Сделал в списке 2 уровня группировок. По счетчику серверных вызовов сразу стало видно, что идет насилие над сервером. Без группировок производится один серверный вызов. С двумя группировками у меня получилось порядка 80 вызовов. Можно еще технологический журнал настроить и посмотреть,что там происходит.
Я думаю у оптимизатора запросов от запроса крыша съезжает. Нельзя в таком запросе использовать ВТ, ложи все во временные таблицы.
Открыли документ Счет, в поле Контрагент набираете первую букву & поиск осуществляется, набираете вторую (третью) букву и список становится пустым - это слетел индекс полнотекстового поиска, его нужно обновить:
- Главное меню - Все функции - Стандартные - Управление полнотекстовым поиском
Если Пункт меню Все функции недоступен, то включить его можно в меню Сервис - Параметры - Показывать Все функции
или такой вариант:
Меню - Администрирование - Поддержка и обслуживание - Регламентные операции - Полнотекстовый поиск данных - Настроить - Очистить индекс - Обновить индекс
Похожие FAQ
17 правил для составления оптимального ЗАПРОСа к данным базы 1С 44
Для формирования и выполнения запросов к таблицам базы данных в платформе 1С используется специальный объект языка программирования Запрос . Создается этот объект вызовом конструкции Новый Запрос . Запрос удобно использовать, когда требуется получ Google maps : вывод точек на карту и режим панорамы 7
В отличие от яндекс карт в GMaps можно использовать панорамы - за что им большой плюс! Надеюсь в яндексе прочитают этот пост и тоже когда-нибудь это сделают! Для клиента нужно было сделать вывод объектов на карту С возможностью просмотра панора База 1С при запуске уходит в дамп и вылетает 1
В последнее время частенько обращаются пользователи у которых после замены или ремонта компьютера 1С не запускается, а точнее при открытии уходит в dump и вылетает. Как правило, решение одно: Отключить аппаратное ускорение видеокарты В Window Блокировка записей, невозможно изменить или удалить из регистра. Конфликт блокировок MS SQL + 1C 3
При попытке удалить запись из регистра сведений - получаю ошибку: она заблокирована, ошибка блокировок и т.д. Отключил всех пользователей, перезапустил сервер, пробую удалить - опять ошибка блокировки :( Путем тестов было вяснено, что проблема Ввод данных по командировкам в программе ЗУП 0
Ввод сведений о командировках в программе 1С: Зарплата и управление персоналом 8 (ред.30) осуществляется в Разделе Кадры - Все кадровые документы - Создать - Командировка Откроется документ: Ввод сведений о командировках в программ Посмотреть все результаты поиска похожих
Еще в этой же категории
Запуск базы 1С в режиме запуска Обычное приложение или Управляемое приложение 28
Для принудительного запуска предприятия в Обычном или Управляемом приложении используются следующие ключи: /RunModeOrdinaryApplication запуск толстого клиента в обычном режиме, несмотря на настройки конфигурации и пользователя, от имени которого Как изменить картинку главное в панели инструментов УП 1С? 7
Разрабатывая конфигурацию, задался вопросом: Как изменить картинку раздела "Главное" в интерфейсе Такси? Сразу скажу, беглый поиск по настройкам не помог, но оказалось все не так сложно. В свойствах конфигурации есть пункт "Картинка основного разде Использование модальных окон в данном режиме запрещено! Модальные окна не работают, как быть? 4
В конфигураторе в свойства конфигурации, есть параметр «Режим использования модальности» Если установить Не использовать , то - принципе весь код, который после ОткрытьФормуМодально() Вопрос(), Предупреждение(), Выборов и диалогов открытия-сохр Пример хранения изображений в базе (отдельный справочник), в интерфейсе Такси и без модальности 3
Часто разрабатывая некую конфигурацию, пользователи хотят прикреплять к элементу справочника фото и чтобы они хранились в базе данных. В этой статье я расскажу как к справочнику объекты строительства подключить хранилище фотографий в виде справочни Как из панели меню убрать пункт Вид и отключить Настройка панели? 3
Нужно чтобы пользователи не могли менять настроенный для них интерфейс! Решение: Для отключения нужно в правах доступа у корневого элемента конфигурации убрать право " Сохранение данных пользователя ". Отключатся настройка панелей и пункт ме Посмотреть все в категории 1С Общие вопросы - Управляемые формы и Такси
Функциональность нового поиска основана на двух механизмах:
— полнотекстовый поиск (работает очень быстро и требует минимум вычислительных ресурсов);
— поиск средствами СУБД (в общем случае длительность поиска и затраты вычислительных ресурсов пропорциональны объему информации в таблице).
В текущей реализации поиск в списке будет осуществляться без использования полнотекстового поиска в следующих случаях (источник):
— полнотекстовый индекс выключен на уровне информационной базы;
— объект основной таблицы не индексируется полнотекстовым индексом;
— в результате поиска с помощью полнотекстового поиска, была получена ошибка.
Если же полнотекстовый поиск включен в информационной базе, а индекс не обновлен совсем или частично (из моей практики 95% информационных баз Заказчиков), то пользователь при поиске получит либо недостоверный, либо пустой результат поиска.
Спрашиваем у Фирмы 1С — как быть? как гарантировать достоверность результатов поиска всегда?
Получаем ответ: Да, для того, чтобы результаты поиска при включенном полнотекстовом поиске были актуальными, нужно следить за тем, чтобы индекс полнотекстового поиска был актуальным.Других вариантов эффективного и актуального поиска пока нет (источник).
А существует ли вообще «актуальный полнотекстовый индекс»? Зависит от числа пользователей, интенсивности изменения информации в базе и частоты запуска обновления индекса. Обычно обновление индекса запускают раз в 60 секунд. Хорошо, если объектов было изменено не много, и процедура успела обработать все изменения за эти 60 секунд. А если сделали перепроведение группы документов, или массовую перезапись справочника? В этом случае никто не может гарантировать время, через которое поиск по индексу снова даст достоверные данные.
В принципе, это не особо критично, кроме нескольких ситуаций. Частый вариант работы пользователей — установить в списке отбор по какому-то значению, например «Контрагенту», ввести новый или скопировать существующий документ и записать. Со старым поиском новый документ моментально был виден в списке. Теперь пользователь его увидит только через N секунд в лучшем случае, где N скорее ближе к 50-60 секундам, нежели к 2-3.
Если не заметить, что нового документа нет и по отобранным результатам предоставить информацию кому-либо, то она будет заведомо недостоверной.
Это было в случае нормальной работы с информационной базой. А что будет в специфических ситуациях? Приведу пару примеров.
1) В рабочей базе полнотекстовый индекс включен и часто обновляется. Пользователь просит развернуть ему копию рабочей базы, что по ней заняться анализом данных.
Восстанавливаем бэкап и даем доступ. Вот только полнотекстовый поиск работать не будет, т.к. индекс хранится не в СУБД, а в отдельных файлах (и в файловом, и в клиент-серверном варианте). Индекса нет в dt-файле.
т.е. чтобы пользователь смог использовать поиск по спискам — надо выключить полнотекстовый индекс в этой базе. Правда пользователь будет слегка удивлен тому, что поиск будет выполняться гораздо дольше. Либо перестроить индекс по всей базе.
2) (Актуально для более менее больших баз). В рабочей базе полнотекстовый индекс включен и часто обновляется. Наступает конец месяца и начинается закрытие периода. Начинаем массово грузить и перепроводить документы. Для снижения нагрузки на систему блокируем выполнение регламентных заданий, соответственно, и обновление индекс останавливается. Пользователи будут, мягко говоря, в недоумении — чего же в списках нет новых или измененных документов. Единственный выход — отключить полнотекстовый поиск для информационной базы, и, соответственно, получить еще большую нагрузку на оборудование за счет тяжелого поиска по всем реквизитам.
Таким образом, как мне кажется, операция по обновлению индекса станет еще одной головной болью администраторов информационных баз.
Система, ранее гарантировавшая 100% достоверность и актуальность информации в любой момент, сейчас превращается скорее в справочную систему, в которой нельзя быть полностью уверенным.
А пользователи получают еще один повод для упрека ИТ-шников — «ваша система неправильно работает».
И все же в этом черном ящичке (динамическом списке) есть узкие места, которые влияют на производительность. Попробую описать пойманные места. Запросы в динамическом списке просты, с одной основной таблицей и без фактических соединений на уровне языка 1С.
Платформа воспроизведения: 1С:Предприятие 8.3 (8.3.6.2237)
Конфигурация: Управление торговлей, редакция 11.1 (11.1.9.56)
Процессор: 2х Intel Xeon X5660 2.8 ГГц
ОС:Win server 2008 R2 enterprise SP1 64x
MS SQL Server 2012. Выделено памяти 50 ГБ.
1С Сервер 64 (8.3.6.2237)
Все статистики и индексы абсолютно обновлены + полнотекстовые. В базе только один я, то есть никаких данных не добавляется и не изменяется. Никаких больше фонновых заданий не запущено.
Вступная часть:
Все начинается как обычно с маленького вопроса и как обычно перерастает в целый ряд вопросов «почему?»…
У пользователей было замечено частое подвисание ДС (динамический список). Со слов пользователя, крутятся часики и программа замирает.
Расследование:
Долго не пришлось искать, поскольку конфигурация давно уже изменена (не типовая на 100%), то кто-то постарался и установил у пользователей автоматическое обновление в 10 секунд, при этом на уровне конфигурации. Если кто не в курсе, это находится здесь:
На этом не все, часики, конечно, мы устранили. Но в процессе поиска и оптимизации долгих запросов на сервисах Гилева, попадаются опять же наши запросы и наш список, но с использованием оператора поиска LIKE «%%», то есть пользователи осуществляли поиск по части строки. А сервис регистрирует какие-то космические цифры от 10 секунд до (кто бы подумал) 600 секунд. Усомниться в сервисе нет причин, проверено запросом в процессе работы пользователей:
Я понимаю вашу терпеливость и жажду «запрос в студию», но, обещаю, мы к этому обязательно подойдем, и они еще успеют надоесть 🙂
Ну вот, почти добрались, запускаем первую трассировку по ДС. Я для себя сделал открытие, ну я в принципе понимал модель работы ДС, но никогда не видел этого на уровне трассировки. Так вот, на этом уровне к базе идет четыри похожих запроса, разница между ними только в условиях. Для проверки приложил их тексты отдельно (Query1.txt — Query4.txt). Кстати, когда открыть список на форме впервые, то запрос будет только один.
Здесь, как видим, нет никаких операторов LIKE. Собственно, это правильно, поскольку это просто обновили список без условий. А теперь представляем ту ситуацию, что была прежде, уровень автообновления 10 секунд и поиск по части строки, который работает крайне интересно. То есть мы уже приблизились к тому, что нагружает сервер СУБД. Забегая наперед, сейчас вообще думаем у части пользователей поубирать автообновления ДС, зачем нагружать сервер лишними пакетами запросов.
После экспериментов на реквизиты, по которым делали пользователи поиск, накладываем Индексировать с доп. упорядочиванием, чем-таки вырываем частичную победу в производительности:
Здесь Вы получаете доступ к публикациям, в которых профессионалы делятся своим уникальным опытом. Для Вас мы собрали более 30 000 различных материалов по 1С.
Рейтинг: 1105
И все же в этом черном ящичке (динамическом списке) есть узкие места, которые влияют на производительность. Попробую описать пойманные места. Запросы в динамическом списке просты, с одной основной таблицей и без фактических соединений на уровне языка 1С.
Платформа воспроизведения: 1С:Предприятие 8.3 (8.3.6.2237)
Конфигурация: Управление торговлей, редакция 11.1 (11.1.9.56)
Процессор: 2х Intel Xeon X5660 2.8 ГГц
ОС:Win server 2008 R2 enterprise SP1 64x
MS SQL Server 2012. Выделено памяти 50 ГБ.
1С Сервер 64 (8.3.6.2237)
Все статистики и индексы абсолютно обновлены + полнотекстовые. В базе только один я, то есть никаких данных не добавляется и не изменяется. Никаких больше фонновых заданий не запущено.
Вступная часть:
Все начинается как обычно с маленького вопроса и как обычно перерастает в целый ряд вопросов "почему?".
У пользователей было замечено частое подвисание ДС (динамический список). Со слов пользователя, крутятся часики и программа замирает.
Расследование:
Долго не пришлось искать, поскольку конфигурация давно уже изменена (не типовая на 100%), то кто-то постарался и установил у пользователей автоматическое обновление в 10 секунд, при этом на уровне конфигурации. Если кто не в курсе, это находится здесь:
На этом не все, часики, конечно, мы устранили. Но в процессе поиска и оптимизации долгих запросов на сервисах Гилева, попадаются опять же наши запросы и наш список, но с использованием оператора поиска LIKE "%%", то есть пользователи осуществляли поиск по части строки. А сервис регистрирует какие-то космические цифры от 10 секунд до (кто бы подумал) 600 секунд. Усомниться в сервисе нет причин, проверено запросом в процессе работы пользователей:
Я понимаю вашу терпеливость и жажду "запрос в студию", но, обещаю, мы к этому обязательно подойдем, и они еще успеют надоесть :)
Ну вот, почти добрались, запускаем первую трассировку по ДС. Я для себя сделал открытие, ну я в принципе понимал модель работы ДС, но никогда не видел этого на уровне трассировки. Так вот, на этом уровне к базе идет четыри похожих запроса, разница между ними только в условиях. Для проверки приложил их тексты отдельно (Query1.txt - Query4.txt). Кстати, когда открыть список на форме впервые, то запрос будет только один.
Здесь, как видим, нет никаких операторов LIKE. Собственно, это правильно, поскольку это просто обновили список без условий. А теперь представляем ту ситуацию, что была прежде, уровень автообновления 10 секунд и поиск по части строки, который работает крайне интересно. То есть мы уже приблизились к тому, что нагружает сервер СУБД. Забегая наперед, сейчас вообще думаем у части пользователей поубирать автообновления ДС, зачем нагружать сервер лишними пакетами запросов.
После экспериментов на реквизиты, по которым делали пользователи поиск, накладываем Индексировать с доп. упорядочиванием, чем-таки вырываем частичную победу в производительности:
Читайте также: