Версия для печати темы (https://pro1c.org.ua/index.php?s=2bfe98c38d57eebdc6a0342b1019f53b&showtopic=50358)

Автор: Vidocq05 08.02.19, 16:20

УТП 1.2.49.1

Предыстория.
Где-то полгода назад обновил платформу с 8.2.19.130 на 8.3.8.2442. Сразу же на следующий день во многих пользователей и очень часто посыпались ошибки на превышение времени ожидания блокировки. Тогда я причину не выявил, т.к. не особо располагал временем, а пользователи очень сильно жаловались. Я даже здесь тему создавал, но и это не помогло. В общем, откатил платформу обратно на 8.2 и проблема исчезла.

Теперь же опять обновил платформу, но уже на 8.3.10.2650 и проблема опять возникла.
Что я выяснил.

В 4 утра запускается регламентное задание, которое запускает обработку, которая формирует и проводит в цыкле документы "Отчет о розничных продажах". Документов всегда должно быть 37 (равно количеству складов), строк в документе в среднем 250. После перехода на 8.3 регламентное задание стало зависать, а точнее после проведения нескольких документов следующий зависает. Это мог быть по счету 5 или 7 или 10 - какой-то закономерности не выявил. Если потом запустить его проведение - проводится без проблем. При выполнении этого регламентного задания ни пользователи ни другие регламентные задания в базе не работают.

Еще точнее выяснил, что зависает выполнение запроса к регистру сведений. Запрос базовый. Вот код:

Функция СформироватьЗапросПоПродажнымЦенам(ДатаЦен, СписокСкладов, СписокНоменклатуры) Экспорт

    Запрос = Новый Запрос;
    Запрос.УстановитьПараметр("Дата", ДатаЦен);
    Запрос.УстановитьПараметр("СписокСкладов", СписокСкладов);
    Запрос.УстановитьПараметр("СписокНоменклатуры", СписокНоменклатуры);

    ТекстЗапроса = "
    |ВЫБРАТЬ
    |    ЦеныПродажные.Склад КАК Склад,
    |    ЦеныПродажные.Номенклатура КАК Номенклатура,
    |    ЦеныПродажные.ХарактеристикаНоменклатуры КАК ХарактеристикаНоменклатуры,
    |    ЦеныПродажные.Цена КАК Цена
    |ИЗ
    |    РегистрСведений.ЦеныАТТ.СрезПоследних(&Дата, Склад В (&СписокСкладов)
    |       И Номенклатура В (&СписокНоменклатуры)) КАК ЦеныПродажные
    |";

    Запрос.Текст = ТекстЗапроса;

    Возврат Запрос.Выполнить();

КонецФункции // СформироватьЗапросПоПродажнымЦенам()

Обычно запрос выполняется в течении 10 сек. Но бывает что выполнение запроса зависает и может висеть бесконечно, пока не удалишь сеанс. Мало того, что регламентное задание не завершается, так из-за того что зависло выполнение запроса то записи регистра сведений заблокированы (возможно что даже все) и другие пользователи становятся жертвами блокировки и практически не могут работать.
Запускал обработку вручную от имени других пользователей - результат тот же.

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

Проблема вроде как ушла, во всяком случае несколько дней "полет нормальный".
Но мне может кто-то объяснить, что это было?
Я понимаю,что в регистре записей довольно много, и складов довольно много (37), и в массиве один и тот же склад повторялся 250 раз потом передавался в запрос как параметр. Но все же...?
Причем на 8.2 все работало без проблем.

Автор: andr_andrey 11.02.19, 9:42

Vidocq05 @ 08.02.19, 16:20 ,
По-разному отрабатывает преобразование запроса из текста запроса на 1С. Надо смотреть в профайлере и план запроса.

П.С. Помню MySQL в молодые годы тормозил при встрече с конструкцией "IN", но MSSQL нормально отрабатывал. Странное что-то.

Автор: Vofka 11.02.19, 10:03

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

Автор: Vidocq05 11.02.19, 12:26

К сожалению в этом я не специалист.