Привет,
Пытаюсь заполнить новый ресурс регистра сведений (независимый, непериодческий) в котором 1.5 млн записей.
Генерирую 20 потоков которые обрабатывают по n-количество записей (1.5млн/20) в фоне в каждый поток. Примерно через ~10 минут все 20 фоновые задания завершаются аварийно.
Сама процедура заполнения и сохранения записи https://pastebin.com/VzL6GWfM
Сперва делал через транзакцию и блокировку управляему.
Потом убрал это их, вроде шестрее стало, но без блокировки по измерению боюсь в какой-то момент появится конкурирующий процесс и возможны коллизии если выполнить код в рабочее время?

Какие измерения есть у регистра?

для чего ты читаешь запись, если все ее данные у тебя есть до чтения?

Оставьте 1 поток на ночь

нахрена "ручная" транзакция там, где платформа и так транзакцию создает?

есть основания полагать, что регистр можно просто trancate table и просто начисто перезаполнить, раз данные его вычисляются из бизнес процесса. Нахрена он вообще нужен такой?

(1) https://prnt.sc/7RP_RP9coXwF
(2) Почему бы читать что есть и дополнительно заполнить новый ресурс?
(3) будет перерасход памяти и вырубится как всегда и до этого пытался в один поток это сделать.

(5) Это будет крайний метод, придется разобраться в логике заполнения из БП..
(4) А в каких примерах надо тогда явную транзакцию, со ссылкой на ИТС?

(6) чтоб небыло перерасхода памяти, не нужно все пихать в одну транзакцию...

(6) завершен - измерение?.. о_0 аднака
правильный ответ на 2 - потому, что есть еще 100500 ресурсов.

Итого, убери свою транзакцию и оставь на ночь в одном потоке. А память у тебя кончается потому, что утечка в коде, который вызывает твою ОбработатьПорциюЗаполненияШаблонаДанныеБизнесПроцессов()

(6) Не будет

(10) будет-будет. Раз падает, значит утечка есть, просто в том месте, которое он не показывает

(11) Ну тогда добавить ещё одно задание-менеджер, которое перезапускает рабочее, если оно упало.

(8) Транзакция в цикле, те для каждой записи (в закомментированном коде)

(9) Подготовка данных для запуска фз https://pastebin.com/0zQz8EjZ

(9) Убрать транзакцию и блокировку. Те в текущем варианте? https://pastebin.com/VzL6GWfM

ты в этих своих потоках один и те же бизнес-процессы обрабатываешь

понлы биздесь, конечно...

И НЕ ДанныеБизнесПроцессов.БизнесПроцесс.Шаблон ЕСТЬ NULL

это условие всегда истинно


а вот это может быть истинным только, если этот УК_Шаблон имеет составной тип
ДанныеБизнесПроцессов.УК_Шаблон = НЕОПРЕДЕЛЕНО

удали просто весь свой код полностью

в нем проблема

(17) почему?
(18) УК_Шаблон - имеет составной тип - поэтому и условие ДанныеБизнесПроцессов.УК_Шаблон = НЕОПРЕДЕЛЕНО

Наверное имелось в виду
И ДанныеБизнесПроцессов.БизнесПроцесс.Шаблон <> ЗНАЧЕНИЕ(Справочник.ШаблоныБП.ПустаяСсылка)

(21) я тебе говорю - это условие всегда истинно потому, что NULL 1С хранить не умеет, нул может только в соединении появиться

(0) сколько ядер на процессоре ?

если там несколько типов, то

И НЕ ДанныеБизнесПроцессов.БизнесПроцесс.Шаблон.Ссылка ЕСТЬ NULL


однако, исходя из того, что ты добавил ресурс и хочешь его заполнить, условие неправильное, оно как раз выбирает те записи, которые тебе не нужны, то есть, в которых всё заполнено

(23) Результат запроса этого поле говорит что там null https://prnt.sc/ijdDlFs-MKSS

(24) Нет такой инфы

(27) без этой цифры нет особого смысла параллелить вычисления.

(26) не правда. Там Неопределено

(25) Те ссылку надо сравнить с null, а не реквизит составной?

пойду убьюсь об стенку

(30) Гляньте (22)

короче, у тебя код и запрос - хрень. Ты разным потокам выдаешь пакеты с одними и теми же ссылками и выполняешь повторную обработку сотни тысяч раз.

Многопоточная обработка делается не так. Ты сначала должен выбрать всё из БД, потом побить на окна и отправить все куски на обработку. Твой же код не учитывает, что между твоими запросами еще не все записи из предыдущих окон успели обработаться.

(32) нет. Раз тип составной, значит там могут быть и еще справочники, а значит такой запрос соберет и заполненные ссылки тоже, которые заполнены, но ссылкой на другой справочни

(32) В моем случае неправильно будет указать .ПустаяСсылка() тк ДанныеБизнесПроцессов.БизнесПроцесс.Шаблон - СправочникСсылка.ШаблоныИсполнения, СправочникСсылка.ШаблоныСогласования, и тд..

(33) Твой же код не учитывает, что между твоими запросами еще не все записи из предыдущих окон успели обработаться -- Зачем ждать обработку предыдущих окон, если я разбил все записи по определенной Дате?

(32) значит так должно быть И ДанныеБизнесПроцессов.БизнесПроцесс.Шаблон <> НЕОПРЕДЕЛЕНО

.ПустаяСсылка() в запросе отсутствует.

Друг, а чем ты занимался последние 13 лет? Это ж чертова база.

В общем, удали свои фоновые задания и обрабатывай одним потоком.

(36) подумай. Просто прими факт, что вдруг я прав и подумай, при каких условиях так может быть с учетом твоего кода.

(38) >> обрабатывай одним потоком

Я так и сказал в (3)

(29) если ДанныеБизнесПроцессов.БизнесПроцесс пустая ссылка, то там нулл.
нул может только в соединении появиться
БизнесПроцесс.Шаблон - и есть соединение, которое вы не увидели
откуда такое недоверие к ТС? он же проверил запрос в консоли перед тем как совать его в обработку данных

(0)
Мудрено как то.

Спешишь куда то?
Если не спешишь, выбирай порциями хоть по 100 штук, ночами.
Заполняй набор и пиши.

(41) хмм.. да, точно, пропустил
ТС не в курсе, как хранятся составные типы, откуда мне знать, отличает ли он нул от неопределено в выборке.

Да. Условие "И НЕ ДанныеБизнесПроцессов.БизнесПроцесс.Шаблон ЕСТЬ NULL" действительно не является всегда истинным.

Только в (33) это ничего не меняет

(42)
И пока не кончаться не заполненные.

(42) Набор по 100 штук не сработает. Тут вам не там

(45)
Возьми 1 000. Надо писать. Если упадет, заполнение то останется.

(46)
Если конечно нужно просто заполнить.
Писать порциями. Выбирать не заполненные.
Пусть падает.

(43) Твой же код не учитывает, что между твоими запросами еще не все записи из предыдущих окон успели обработаться. -- ты тут описываешь последовательная обработка данных.
Я же запускаю паралельную обработку порций данных, которых я ранее разбил по дате.

(0) В твоем узком случае проще создать несколько записей тестовых из 1С
А затем напрямую прямыми запросами фигачить в субд

(47) В продуктивах то надо одним ходом заполнить, а не растягивать по времени..

(45)
Мощность множества не более чем счетно.
Кончится быстро.

(49)+ Тебе же надо просто https://learn.microsoft.com/ru-ru/sql/t-sql/queries/update-transact-sql?view=sql-server-ver16

(50)
И что? запускай хоть раз в 10 секунд и долби.

(49) Да вроде получается и потоками в ФЗ это сделать. Просто хочется чтобы код 1С был безопастным и корректным

(50)
+ все трудности от большого объема записываемых данных.
Нужно уменьшить.

(54)
Ну раз нет желания обойти, то удачи.

Нормальные герои всегда идут в обход.

(54) У тебя "УК_Шаблон = КлючЗнч.Шаблон" всегда разное или повторяется для разных записей?

(57) Шаблонов от силы 5-7. Хочешь предложить разбить порцию по шаблонам? Можно но зачем, всего лишь другой критерий разделения.

(0)
Вариант для крутых.
Пиши в СКЛ_Сервер прямым запросом ночью.

Ну и зачем по одной записи?
Когда общепринято (в типовых например) использовать ТЗ
и СоздатьНаборЗаписей ... Загрузить(ТЗ) ... Записать()

(0)
И зачем каждый раз заполнять уже заполненное?
Есть такая необходимость?

Ты же каждый раз с начала начинаешь?

(59) Да нет у меня доступа к инфраструктуре)

(58) Да. Выгрузить из РС в ТЗ по фильтру.
Заполнить колонку УК_Шаблон, Загрузить и Записать

(60) А как мне Набор поможет если в каждой записи измерение разное?

(62)
36 лет. Вроде большой мальчик?
Не пускают? Договорись.

(64) кто мешает в (63) фильтру составную?

(64)
Иногда желание решить задачу как задумал сильнее здравого смысла.

Удачи.

(66)+ В несколько потоков раздельное чтение (только чтение, без записи) блокировки таблиц не происходит

(68)+ Вот подобрать размер ТЗ (количество записей) для записи в РС это уже на практике, чтобы в несколько потоков блокировки были минимальны

Кстати у метода "Записать" есть параметр.
Отбор можно и не ставить.

Не важно. Возможно путаю ))))

Сами разберетесь.

Групповые методы (НаборЗаписей) обычно всегда шустрей чем одиночные (МенеджерЗаписи) в цикле

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

(72) Надо проверять
В какие запросы sql это будет транслироваться и как сервером 1С

(70) Сейчас Вы насоветуете до уничтожения регистра. Идите уже

(73) я проверял :)

(74) Это уже советовали, сохранить данные из РС, грохнуть таблицу и заново создать с заполнением ))

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

(75) Т.е. там нет на низком уровне потерь от цикла на ЯП 1С?
Когда вместо него передается ТЗ сразу?

(76) первым делом

(78) на низком уновне запись большого набора независимого регистра с заменой транслируется в построчное delete from + insert into

(78) Эти потери меркнут на фоне транзакции на запись в БД.

(74)
Оно просто не запишется. Если запись есть уже.

А может вообще данные этого регистра во внешний источник данных вынести? и там средствами языка SQL делать что то с данными? а из 1с уже обращаться к ним?

(82) Остыньте. Ваша идея с наборами уже отвергнута.

(74)
Он просто работать не хочет.
Хочет на Мисте общаться. Цените.

1 500 000 записей на наборы по 1 000 записей =
1 500 наборов.
Если запускать один набор в минуту это чуть больше суток работы.

Отбирать не заполненные.
При записи набора из 1 000 записей упасть не должно.

Можно писать поштучно, тогда даже в случае падения останется меньше.

А какой смысл делать несколько потоков на записи с идентичными измерениями? Только упадет скорость.
В один поток, транзакциями 10-100 или сколько удобно штук записей и все ок будет. 1.5млн не особо серьезно.

(85) Здесь набор не прокатит, потому что измерения разные, см. (64)
Даже 2 записи в набор не запихнёте

(87)
Менеджер.
Выбирать запросом первые 1 000 не заполненные. И по одной.
Блокировка ему не нужна.

за 25 часов обработка перелопатит при запуске раз в минуту.

Если брать по 2 000 за 12,5 часов.

Можно индекс для скорости на реквизит поставить.
После заполнения убить.

Как ИМХО так ТС тупит страшно.
Каждый раз сначала начинает.

Но я старый с маразмом. )))
Молодежи виднее.

(29)
Потому что тип не выбран.

Спасибо,
Код по ссылке в самом начале за ~30 мин заполнил все мои интересующие записи.

(29)
NULL это когда "Использование" у реквизита справочника только для родителя, например, а обращаешься не к группе.
(87) Но это только новисы знают ))). Так же как и про параметр у метода.
Насипова про то "за что увольняют" все слышали, а в хелп не все смотрели.

Не важно. Пойду посплю. Всем хорошего и успехов в работе.

(89) https://i.imgur.com/pU82cRU.jpg

(94)
Да сомнительно. Выигрыш в скорости запроса.
Проигрыш при записи. Потому что пишем большой объем данных построчно, и индекс тоже перезаписывается.

Все не интересно.

(95) Сдавайтесь. Вам не победить этот сабж.