Добрый День 1С77 ТИС база SQL тормозит при записи элемента справочника Номенклатура, при создании нового элемента или при редактировании старого. Раньше все работало нормально  в чем может быть проблема?

Отладчик?

(0) Вставили при записи контроль на уникальность наименования или реквизита?

Что меняли в типом по номенклатуре? Если есть возможность - перенумеровать штнтно все карточки.

что говорит замер производительности?

Ни каких изменений не было
Отладчиком не получается найти функцию которая тормозит

Не может сработать автонумерация как вариант

А что можно сделать с авто нумерацией? Кроме префикса по дате?

Фоновым заданием максимальный номер в константу записали, а дальше что?

(8): в семерке нет фоновых заданий
(5): ещё раз, по слогам: (4)

В 7ке может быть постоянно запущен один сеанс и по расписанию запускаться обработка. Или расписание может быть в виндоус, открывается 7ка, что то выполняется при начале работы системы и закрывается. В эти минуты тоже может тормозить.

(7)не, при проблемах с автонумерацией - там симптомы - не открывается форма элемента при вводе нового элемента

Присоединюсь к (4)

(12) Простите за глупый вопрос как сделать замер производительности?

(13)в отладчике запустить отладку

Глобальный модуль                            1018    Пока ЦеныТовара.ПолучитьЭлемент()  = 1 Цикл                         501987    87.613492    96.92
Справочник.Номенклатура.ФормаСписка.ФормаСписка    64    Цена = глВернутьЦену(ТекущийЭлемент(), ТипыЦен.ПолучитьЗначение(2));    20    36.643302    40.54
Справочник.Номенклатура.ФормаСписка.ФормаСписка    66    Цена = глВернутьЦену(ТекущийЭлемент(), ТипыЦен.ПолучитьЗначение(4));    20    35.400506    39.16
Справочник.Номенклатура.ФормаСписка.ФормаСписка    119    Цена = глВернутьЦену(ТекущийЭлемент(), ТипЦены);                    4    17.700777    19.58

Вот как то так

Четыре колонки с разными видами цен в форме списка? Мечта менеджера..

(15) вот это непотребность перепиши по-человечьи и будет мгновенное открытие

Так проблема не в открытии формы списка Номенклатуры, а в записи элемента
вот процедура  вернуть цену

Функция глВернутьЦену(Товар, КатегорияЦены) Экспорт
    Перем ЦеныТовара;
    Перем Результат;
    
    ЦеныТовара = СоздатьОбъект("Справочник.Цены");
    ЦеныТовара.ИспользоватьВладельца(Товар);
    ЦеныТовара.ВыбратьЭлементы();
    Пока ЦеныТовара.ПолучитьЭлемент()  = 1 Цикл
        Если ЦеныТовара.ПометкаУдаления() = 1 Тогда
            Продолжить;
        КонецЕсли;
        
        Если ЦеныТовара.КатегорияЦены = КатегорияЦены Тогда
            Результат = ЦеныТовара.ТекущийЭлемент();
            Прервать;
        КонецЕсли;
    КонецЦикла;
    
    Возврат Результат;
КонецФункции

(18) гениальный ход, особенно для вызова из общего списка... кто делал?

(18) в типовой такого кода нет. Накорябали кривыми ручками вот и тормозит.

Хотя, сорян...
Судя по коду глВернутьЦену это редакция 8.7
И что там делается при записи карточки - надо глядеть отдельно в связи с древностью конфиги.
Хотя вот сейчас клиента делаю няшки как раз на такую конфигу - тормозов не замечал

ГлВернутьЦену можно ускорить. Исползовав Спр.ВыбратьЭлементыПоРеквизиту и сразу спозицион роваться вместо перебора. Но для единичной карточки номенклатуры это некритично будет.
Это так... Попутно

Для этого требуется галочка отбор по реквизиту, в типовой не было.

(20) код то типовой, просто он не вызывается из списка справочника 4 раза на строку.....

База УРБД  на SQL, на ней рабтает 5 лет сеть магазинов 10 торговых точек.  тормозов не было, началось буквально месяц назад. изменений в конфигурации ни кто не делал. Размер базы около 30Гб

Элементарно, была база с пятью позициями номенклатуры и максимум тремя типами цен и еще одной себестоимости. Документооборот может быть даже очень большой и магазинов много. И вот добавили что либо, как у всех..

(23) неправильно. Упомянутая галка требуется для интерактивной установки отбора. А так достаточно только галки сортировка.

(24) еще раз говорю в списке проблем нет

(25) проведи полный цикл обмена и пр нудительно почисть таблицу 1сапдейтс

(28) ещё раз п.4

(28) так если ты все знаешь, зачем тему создал?))

If there's something strange,
In your neighborhood
Who you gonna call?
Ghostbusters!

(29) А что это даст проблема не только в периферийной базе но и в центральной.

(31) наверное потому что я не смог найти ответ на свой вопрс

"тормозов не было, началось буквально месяц назад"

А не пробовали индексы перестроить, статистику обновить?

(34) запускал хранимую прцедуру 1sp_DBReindex

Ну открой наконец, жуколов, создай элемент, нажми на замер, запиши элемент, нажми на замер ышо раз.
Сымотри стек вызовов
Хотя бы

Ну и профайлер можно натравить, хотя.. это лишнее

(36)
Глобальный модуль    1018    Пока ЦеныТовара.ПолучитьЭлемент()  = 1 Цикл    501981    85.191610    51.78
Справочник.Номенклатура.Форма    1328    глЗаписьПериодическихРеквизитов(Контекст);    // добавляем небходимые закладки    1    76.893254    46.74
Глобальный модуль    952    ОткрытьФормуМодально("Обработка.ЗаписьПериодическихРеквизитов", Параметр);    1    76.893231    46.74
Справочник.Номенклатура.ФормаСписка.ФормаСписка    66    Цена = глВернутьЦену(ТекущийЭлемент(), ТипыЦен.ПолучитьЗначение(4));    20    35.653820    21.67
Справочник.Номенклатура.ФормаСписка.ФормаСписка    64    Цена = глВернутьЦену(ТекущийЭлемент(), ТипыЦен.ПолучитьЗначение(2));    20    34.497887    20.97
Справочник.Номенклатура.ФормаСписка.ФормаСписка    119    Цена = глВернутьЦену(ТекущийЭлемент(), ТипЦены);    4    17.144227    10.42
Глобальный модуль    1019    Если ЦеныТовара.ПометкаУдаления() = 1 Тогда    501967    1.525526    0.93

Надо в процедуре глВернутьЦену - поставить условие на пустое значение Товар

Сейчас похоже при поиске цен - весь справочник перебирается и так 4 раза

(38) понятно. У тебя не запись тормозит, а пересчетв форме списка справочника, в котором 500к элементов перебираются каждый раз, еще и мегатормоз периодика.
Заремь в форме списка строки получения цены  Цена = глВернутьЦену и проверб, что всё полетело.

+(40) который выполняется после записи элемента...
------------
раз базы SQL - я б посоветовал переписать на прямой запрос, и не трахать мозг. Это быстрее всего.

(18), (38) Отстой. Если нет возможности использовать прямые запросы, через 1C++ или ToySQL, то хотя бы вместо выборки элементов надо использовать стандартный (черный) запрос - это в разы должно ускорить получение цены. Ну и конечно использование индексов. Владелец - это уже индексированное поле.

(42) он по владельцу и отбирает.

(43) Кроме владельца нужен еще отбор по категории цены. Читай внимательно. Ты не выспался что ли?

(44) индекс по владельцу и другому реквизиту - создается, если галку "сортировка" поставят. Если бы поставили - тогда и отбирали бы ВыбратьЭлементыПоРеквизиту. Раз выбирают просто так - значит, и отборы не стоят, значит и индексов нет.

(45) ВыбратьЭлементы и ВыбратьЭлементыПоРеквизиту - зло. Нужно использовать черный запрос. Я это уже сказал выше. А чтобы запрос ускорился, тогда и надо включать сортировку. Так что не понимаю причину дискуссии.

(46) Вот! ключевые слова "я не понимаю". Что и требовалось доказать

(47): ну человек не понимает - как это черный запрос может работать медленнее... ну бывает...

зачем полмиллиона цен лопатятся? я тоже не понимаю.

(49) Во-во.
(48) Ты докажешь, что полмиллионная выборка будет работать быстрее черного запроса? Черный запрос при трансляции вообще-то WHERE накладывает, а выборка в каких случаях накаладывает?.

(52) Если это выборка по реквизиту, то быстрее

(56) Если включена сортировка, то черный запрос с отбором по этой сортировке все равно будет также работать или быстрее, чем объектная выборка.

(57) не быстрее.

(57) У меня на 150 тысячах записей работало быстрее. Так что слово против слова. Да и спецы 1С на ИТС в рекомендациях не советовали использовать объектную выборку там, где можно использовать черный запрос. Хотя и то, и другое прямым запросам проигрывают в разы.

(59) Ну вот сразу видно, что ты их не писал.
ВыбратьЭлементыПоРеквизиту, как и НайтиПоРеквизиту делает запрос по индексированному полю, и никак ты это не ускоришь, даже переписав на прямой запрос.
Ну разве что, использовав свой самодельный покрывающий индекс.

не быстрее.
так что два слова против слова.

Ну и всяко, чорный запрос проиграет этой конструкции

(33) так если ты сам не смог найти, имеет смысл послушать, что тебе другие говорят?
могу повторить: проблема не в записи, а в отображении списка...

(63) тогда пусть тс простестирует открытие редактирование и закрытие карточки не из списка а напрямую

(39) и на то что товар не группа?

(63)Ну автор же написал что проблема только при создании элемента - при чем тут список вообще

(66) не, перечитай

ОткрытьФормуМодально("Обработка.ЗаписьПериодическихРеквизитов", Параметр);    1    76.893231    46.74

тогда вот это надо смотреть еще

А я вот не помню - разве в типовых в списке для для всех строк функции отрабатывают. как минимум кэширование должно быть

Но функция показа остатков в форме списков вроде есть в ТиС - и включается галочкой

(68): никакого кэширования.
слева-направо сверху-вниз по всем видимым строкам

(кэширование каждый может сам-сам-сам сделать штатными средствами, не проблема - но тут не тот случай)

(69)если именно по ВИДИМЫМ - то ничего страшного

(71): на самом деле - страшно. ибо тормозит нещадно.

(72)это если работать со списком без групп, с группами не так страшно

(73) какая разница? Обсчитываются выводимые на экран.

(73)ну на экран весь справочник не влезет

Пока ЦеныТовара.ПолучитьЭлемент()  = 1 Цикл    501981    85.191610    51.78

вот здесь 501981 - это же количество итераций? явно оно не при выводе на экран отрабатывает - это и заметили бы сразу

Что там может происходить того при записи существующего элемента справочника - непонятно

(75): и у тебя даже не закрадывается подозрение, что 501981 штука - это тупое перелопачивание всего справочника при ошибочном указании владельца и/или без явной установки работы в режиме иерархии?..

(76)так я сразу написал это в (39)

Непонятно как такое может быть для уже созданного элемента?

(77) да хз, когда-то полного не приведено

(0) Поздравляю, переходите на прямые запросы :)

(61) Два так два. Мой опыт 8 лет назад на комплексной клюшке на сиквеле в 15 гектар показал, что функция, показывающая текущую среднюю себестоимость в списке номенклатуры из несколько десятков тысяч элементов, после переписывания с выборки на черный запрос ускорилась в 2,5 раза. Заказ был разовый, поэтому клиент отказался от внедрения прямых запросов.

В MSSQL на чтение возникает блокировка на строку, но когда данных много, то это может увеличивать стоимость запроса в MSSQL. В PostgreSQL другая проблема - несмотря на отсутствие блокировок на чтение, там при каждом обращении в цикле может возникать новая временная таблица. И так и так плохо.

https://infostart.ru/1c/articles/76287/
Может пригодится

(80) а что ты там переписал в списке "из выборки на чорный запрос"?