База файловая, пробовал на терминале запускать тоже самое, первые поиска 3 очень долгие, до 1 мин может доходить ожидание. Так же говорят что иногда такие подвисания происходят вовремя дня. 15 000 номенклатур.
при первом поиске заметил что трафик по сели входящий увеличивается , как будто подгружается вся таблица номенклатуры. Вопрос где она хранится? в ОЗУ? если так то может ли она быть вытеснена другими программами из памяти?
Запрос динамического списка
ВЫБРАТЬ
СправочникНоменклатура.Ссылка,
СправочникНоменклатура.Код,
СправочникНоменклатура.Наименование,
СправочникНоменклатура.ВидНоменклатуры,
СправочникНоменклатура.ТоварнаяКатегория,
СправочникНоменклатура.Марка,
ВЫБОР
КОГДА СправочникНоменклатура.ЭтоГруппа
ТОГДА -1
ИНАЧЕ -1 + ВЫБОР
КОГДА СправочникНоменклатура.ПометкаУдаления
ТОГДА 1
ИНАЧЕ 0
КОНЕЦ + ВЫБОР
КОГДА СправочникНоменклатура.ВидНоменклатуры.ИспользованиеХарактеристик = ЗНАЧЕНИЕ(Перечисление.ВариантыВеденияДополнительныхДанныхПоНоменклатуре.НеИспользовать)
ТОГДА 1
ИНАЧЕ 3
КОНЕЦ
КОНЕЦ КАК ИндексКартинки,
СправочникНоменклатура.ЕдиницаИзмерения,
СправочникНоменклатура.Артикул,
СправочникНоменклатура.НаименованиеПолное,
СправочникНоменклатура.Вес,
СправочникНоменклатура.СтавкаНДС,
СправочникНоменклатура.Весовой,
СправочникНоменклатура.ТипНоменклатуры,
ТоварыНаСкладахОстатки.КоличествоОстаток
ИЗ
Справочник.Номенклатура КАК СправочникНоменклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки(,{(Склад=&СкладОстатков)}) КАК ТоварыНаСкладахОстатки
ПО СправочникНоменклатура.Ссылка = ТоварыНаСкладахОстатки.Номенклатура
{ГДЕ (&ТолькоОстатки=Ложь)ИЛИ(isNull(ТоварыНаСкладахОстатки.КоличествоОстаток,0)<>0)} // если показывать ТОЛЬКО с остатками
Если галка "Динамическое считывание" не стоит, то считывание выполняется в кэш порциями по тысяче или полторы элементов. Ну и плюс холодный старт, пока таблицы "прогреются".
Фигачить соединение с регистром накопления в динамический список - это сурово. К такому его не готовили :)
(4) Может. Если как ты говоришь, до 1 мин может "зависать", то можешь попробовать "выцепить" виновника. Открой мониторинг дисковых операций и смотри на какие файлы приходится максимум операций в момент зависания - на файлы ППД или на файлы БД. Да и вообще очередь к диску полезно будет помониторить. Полагаю, в моменты зависания поиска она зашкаливает.
Еще вот такое на ИТС пишут: "В том случае, если ни один из индексов таблицы не соответствует заданному пользователем упорядочиванию, механизм динамического просмотра не будет задействован, и из информационной базы будут считываться сразу все данные, которые потенциально могут быть отображены в списке".
В общем, как бы то ни было - подозреваю что комбинация "тяжелого" запроса динамического списка, его настроек плюс поиск через ППД приводят к ситуации, когда вычитывается весь справочник с остатками по нему. Порционное считывание вообще очень легко "сломать".
А как именно применяются фильтры поиска ППД на низком уровне и какие могут быть расклады по производительности - такой информации я вообще нигде не находил.
(7)Работает в базе 2 пользователя один на терминале, второй по сети. Оказалось что долгий поиск начинается после изменения данных справочника номенклатуры пользователем в терминале, А у второго пользователя, который по сети, при поиске, выходит что подгружается вся таблица номенклатуры как после холодного старта. Что с этим можно сделать?
у второго пользователя, который по сети, при поиске, выходит что подгружается вся таблица номенклатуры как после холодного старта. Что с этим можно сделать?
Телепаю: поставить серверную ОС.
Потому что больше всего это похоже на "проблему второго пользователя" - отключение сетевого кэширования на десктопных Windows в качестве файл-сервера.
(10) Второму пользователю который работает через локальную сеть, у которого есть просто шара к файловой базе надо поставить серверную ОС? я правильно понял?
Думать надо было, когда добавляли соединение с регистром накопления в запрос динамического списка. Что делать? Убрать его нафиг.
И рыбку съесть и удобно присесть - не получится.
Так просто задачи такого рода не решаются.
Отображение текущих остатков можно сделать в стиле толстого клиента - через оформление строк (так хотя бы регистр накопления будет гарантированно дергаться небольшими порциями, хотя длинный скролл будет с небольшими паузами. Поиск тормозить точно не будет).
А вот с отбором позиций с остатками - сложнее. В голову приходит только регистр сведений, обновляемый периодически или по событиям (каким - надо думать).
(13)Увы но ваша теория не увенчалась успехом. Я убрал остатки в запросе и оставил чистый запрос только из справочника номенклатуры, а погрузка все равно осталась. Попробовали базу на sql поставить и только в этом случае все быстро отрабатывает.
(15) Очень странно. А сортировки/отборы какие при этом стояли? Если несложно, попробуйте на автогенерируемой форме списка - чтобы исключить неправильную ее настройку.
(16)Вот сейчас у справочника номенклатура убрал форму списка. При запуске справочника выдалась стандартная форма. После старта пару поисков было долгих, а потом моментальные стали. Зашел в терминал и там открыл 1с под другим пользователем, внес новую номенклатуру, и вернулся на комп что по сети, и попробовал сделать поиск и он оказался таким же долгим как первый поиск после старта.
(18) Спасибо, очень интересно. Похоже на особенности работы полнотекстового поиска в файловой версии. Я могу только догадываться, как ППД работает на самом деле. По-идее, результат работы полнотекстового поиска возвращает набор ссылок, подходящих под отбор, и фильтр по этим ссылкам добавляется к запросу динамического списка. И тут бы понять - тормозит полнотекстовый поиск или запрос с применением его результатов. Я бы попробовал определить, как в (5) советовал.
ЗЫ. Может, сервер приложений использует какое-то дополнительное кэширование "для всех", которое позволяет избегать каких-то узких мест в этом процессе
Еще варианты:
- посмотреть не стоит ли галка очистки кэша при запуске у пользователя.
- посмотреть настройки антивирусов как на клиенте так и на сервере (убрать все проверки для файлов базы и испольняемого файла платформы)
- посмотреть планы запросов в технологическом журнале (не сочтите за рекламу, можно воспользоваться моей обработкой - https://infostart.ru/public/323477/). Возможно задействуется РЛС.
- выполнить реиндексацию.