Доброго дня!
Подскажите плиз, есть ли какие рекомендации, либо приемы на оптимизацию этапа загрузки данных по правилам КД?
Переношу по типовому правилу данные из одной типовой конфигурации в другую, но времени уходит катастрофически много. Конечно и объем данных большой, но хотелось бы понять, как ускорить его загрузку.
Загруженности оборудования нет!

И откуда бы она взялась-то... это самая загруженность...

Дело не в самих правилах КД, а в режиме работы самой базы. Реальное ускорение можно получить только если база окажется в абсолютно монопольном доступе, т.е. не будет ни одного лишнего сеанса.
Если это в файловом режиме, то это обеспечить просто - в одной базе один активный пользователь.
А если необходимо выполнять загрузку данных в базу непосредственно в клиент-серверном режиме, то будет иметь сильное значение версия платформы и нужен монопольный доступ, чтоб ни одна зараза на рпхост с процессом загрузки не покушалась - другими словами, нужна полная изоляция процесса загрузки от потенциальных конкурентов на блокировки.

з.ы. О наличии рассуждений, что блокировки возникают только в одной базе и т.д. и т.п. - я все эти рассуждения уже слышал. При малом числе пользователей на сервере нужно включать опцию "одна база на процесс" и заходить в базу только одним активным пользователем.
з.з.ы. Кстати, о том, что только один активный пользователь в базе очень приоритетно, это можно видеть на типовом процессе обновления самых свежих конф, в котором любые иные сеансы автоматически блокируются, кроме админа.

(1) В базе работаю только я.Пробовал загрузку как с блокировкой регламентных заданий, так и без. А вот то, что 1 rphost конкретно только на меня не учел. На серваке херова народ работает в других базах, на этом же процессе.

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

(3) свежие и3 несвежие ксеоны и в хвост и в гриву)

(0) "Загруженности оборудования нет!" - по каким параметрам определяешь загруженность оборудования?

+5 База файловая? Или клиент-сервер?

(6) он ответил в (2)

(0) В случае sql базы 1С только отказ от КД и переход на свой обмен, с использованием много потоков/фоновых на сервере.

XML имхо тормозной и когда все данные (объекты) в одном файле это не позволяет распараллелить процесс выгрузки/загрузки.
JSON лучше для этого подходит и писать разные объекты (элементы справочников, документы и записи регистров) в разный файлы или сообщения.
Сообщения это использование RabbitMQ или аналоги.

(2) свежий rphost он многопоточный из коробки, там упирается в ядра/потоки сервера
несколько rphost есть смысл держать только для повышения надежности если часто падает
с точки зрения экономии ram лучше один rphost ибо несколько для одной базы/конфы будут дублировать конфу и кушать лишнюю оперативку

(9) Свой обмен не вариант, т.к. используются типовые правила для ЗУП(немного мной переделанные).

(0) Причин может быть две: реально большой объем данных или неоптимальный код в правилах

(12) Данных объем большой.Но для примера если взять выгрузку "Начальная ШР". 3 организации выгружаются примерно 6-7 часов. А если сделать связку сотрудников не с филиальной организацией, а головной, но время увеличивается с 7 до 21 часа(((

(9) жсон от хмл отличается только формой скобочек

распараллелить можно, но нужно отказаться от выгрузки по ссылкам

(15) Доводилось сталкиваться с переводом ЗУП на версию 3.1?

(7) Да, уже увидел.

(14) нет это не так
совершенно другой принцип и устройство сериализаторов/парсеров

Все такие эксперты в исцелении по фотографии.

Я бы посоветовал сначала найти узкое место.

(19) узкое место искали еще в прошлой ветке. У ТС это уже не первая об этом самом переносе данных из старого ЗУП в новый ЗУП

Вопрос в (0) конечно актуальный, сам так и не нашел на него ответа. На хорошей по размеру базе УПП загрузка цен шла порядка десяти дней :-( , это был конечно пробный вариант, но рабочий с такой скоростью запустить так и не решились :-(

(13) Насколько большой объем?

(13) Проведи тест.

Всю выгрузку подели на 2-4 части и проверь сколько будет загрузка параллельно через "Универсальный обмен данными в формате XML" на одной базе если несколько сеансов

И да обмен через json примерно в два раза шустрей чем xml
Особенно самописный без правил а с прямым преобразованием кодом

(13) Так выгрузка или загрузка?
Раньше при переходе на редакцию 3.1 нужно было изменить порядок измерений в регистре (параметры запроса не попадали в индекс), ускорялся перенос раз в 5-10.

(24) Ну самописный писать довольно долго, вряд ли это выход для ТС.

(0) Легко. Но надо смотреть на сами правила.
Я оптимизировал правила, с увеличением скорости загрузки в 20 с копейками раз, тупо убирая перезапись объекта если он есть в базе.
Тут универсального механизма нет.

(27) + часто виды начислений анализируются\перезаписываются. Мы вызывали процедуру 1 раз после загрузки всех данных.

(25) у него выгрузка, судя по его прошлым ответам, формируется примерно одинаковое время, вне зависимости от выбранных настроек.
А вот загрузка начинает дико тормозить, если выставляют перед выгрузкой привязку работников к филиальной структуре.

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

По идее, в результате всех этих невероятных усилий, должна заполниться ТабЧасть документа Начальная Штатная Расстановка. Просто немного странная и путанная структура данных в каждой строке ТЧ.
Но все нужные данные в базе уже записаны и к моменту создания ТЧ у этого документа там возможна перезапись уже записанных ранее, но и то, не факт, что они в действительности должны быть перезаписаны.

(25) Загрузка в 3.1. Работаю с типовой обработкой по переносу(Помощник перехода с прежних программ). Можешь подробнее про манипуляции с измерениями написать, после которых ускорился перенос???
Мне сейчас любые средства хороши)

(27) Можешь написать, как убрать эту перезапись? Что-то я туплю....как раз перезапись существующих, а не добавление новых элементов в ЖР пишется и забирает на себя львиную долю времени!

(28) Эту же проблему по ЖР наблюдаю. Напиши, плиз, как реализовать то, что ты написал?

(29) "ХЗ, почему они там у себя не хотят установить такие подробности данных уже после загрузки, зачем им прямо в загрузке нагружать все такими данными, которые превращают процесс загрузки в невыполнимый квест." - все очень просто. В 2.5 была не верная привязка данных по филиалам и головной организации, в 3.1. сказали это дело исправить.

Тут вопрос в длительности загрузки даже не чисто штатки. Этап "Кадровые данные" - более 2-х дней, "Учет среднего заработка" - более 2-х дней, "Учет НДФЛ" - чуть более суток.

(35)Замеры производительности что-то говорят?
Когда-то давным давно сталкивался с тормозами обмена на КД. Заметил, что при распухании регистра сведений СоответствиеОбъектовИнформационныхБаз происходит очень медленная запись в него. К счастью у меня данные по УУИДам соответствовали и я мог себе позволить отключить использование этого регистра.

Как временное решение могу посоветовать перевести базу в файловый режим, положить ее на комп с хорошим процом (с высокой тактовой частотой, количество ядер не важно) и SSD и прокачать данные. Должно быть гораздо шустрее.

(0) дык правила смотри, чтоб все объекты выгружались только по ссылке(точнее, чтоб точно гуид ссылки выгружался, а не сам объект со всеми реквизитами).
+ Галки там смотри, чтоб только новый объект записывался или модиффицированный. Если реквизиты не поменялись, не записывай

(36) Замеры каких-то тормозов не показали. РС "СоответствиеОбъектовИнформационныхБаз" судя по ЖР тоже не участвовал в медленных загрузках.

(37) Ты имеешь ввиду, что у правил, в которых предполагается не создание, а только перенос ссылки выставить галки "Не замещать существующие объекты в приемнике при загрузке, а только создавать новые" + "Не создавать новый объект, если он не найден"?

Не..там есть еще галка, чтоб при выгрузке для реквизитов ссылочного типа выгружался только гуид мсылки. + Если загрузка идет через поделку универсальный обмен хмл, то в ней поправить, чтобы записать было только, если объект модифицированн.

(35) На мое мнение (постороннего человека), тут проблема все-таки не совсем в правилах. То, что правила будут неоптимальными для производительности - этого никто и никогда не себе не представлял. В любом случае, все эти правила придуманы просто по максимуму корректной передачи самих данных. Да, вполне возможно, что где-то и когда-то будут излишние дублирования записывания уже существующих записей, но! Это же надо каждый раз не просто принимать решение, что уже существующую по ссылке запись перезаписывать не нужно, а нужно всякий раз проверять все поля перезаписываемой записи - новая там информация на момент обработки текущих данных или нет.
Мало того, для связи с наборами текущих данных в один момент времени может быть одно состояние в полях всех записей набора, а в другой момент уже другое. И оно каждый раз будет верным, но только в том текущем.

Короче говоря, я бы свел к минимуму все чрезвычайно длительные процедуры переноса и вносил изменения в уже записанные данные, условно говоря, после основного переноса.
Например, // В 2.5 была не верная привязка данных по филиалам и головной организации, в 3.1. сказали это дело исправить //

Исправляй это не штатным переносом данных, а уже после него - внеси изменения в данные в новой базе, но до начала работы пользователей и ввода новых документов пользователями. Проблема только в том, что когда пользователи начнут вводить и проводить новые документы, то они потянут ссылки на кривые данные, причем, кривизна не в том, что перенесено что-то не то, а что фактическая инфа не соответствовала состоянию учета и до переноса.
Переносить нужно не новое, а нужно переносить без искажений. Для новой базы новое и верное состояние данных устанавливать не путем исправления в старой, а исправления уже в новой.
Ну я думаю, что смысл моих рассуждений уже понятен :-)

(40) "там есть еще галка, чтоб при выгрузке для реквизитов ссылочного типа выгружался только гуид мсылки." это в самих Правилах? Просмотрел ПКО и ПКС, похожей галочки не нахожу. Я чисто помощником перехода пользуюсь. Универсальный обмен хмл напрямую не использую.

(27) В самих ПКО выставлял галку "Не замещать существующие объекты в приемнике при загрузке...", но при загрузке все равно вижу, как этот объект перезаписывается..

(43) там нужно ходить отлдчиком. Часть как-бы правил не действительна, если отладчиком добраться до исполняемых действий.

т.е. вроде и правила - а как особые условия, то и пофиг оказываются все эти правила.

(31) Регистр сведений "Плановый ФОТ" выставлял в редакции 3.1.7:
Сотрудник, Начисление, ГоловнаяОрганизация, ДокументОснование, ФизическоеЛицо, ДатаОкончания, Год
Посмотрел в 3.1.14 и 3.1.15 - уже поправили.
(33) Общий модуль УправлениеШтатнымРасписанием.ПрименитьИзменениеНастроекШтатногоРасписания - закомментируйте код. После загрузки всех данных вернуть обратно, сделать экспортной и вызвать из обработки.

В новой редакции может еще где тормозов добавили - надо смотреть. Грузил на i7 + SSD.

(0) есть способ - записывать только измененные объедки, но в функционале КД (обработка обменXML) его нет, и что там есть галка в КД2 - это фуфел, она нерабочая, потрать время, напиши код сравнения значений свойств и пиши только измененные объедки, это дает до 25% выигрыш при загрузке

+ (47) я в своей нетленке http://catalog.mista.ru/public/461158/ так и сделал

Документы продажи имеют ссылки (являются основанием) в других документах: оплаты, СФ... Прописал для пробы:
Если Не Отказ И Параметры.ЗагруженныеДокументы.Найти(Источник) = Неопределено Тогда
    Параметры.ЗагруженныеДокументы.Добавить(Источник);
ИначеЕсли Не Отказ Тогда
    Если Параметры.Комментировать Тогда
        Сообщить("Уже выгружен: " + СокрЛП(Источник), СтатусСообщения.Информация);
    КонецЕсли;
    Отказ = Истина;
КонецЕсли;
В результате:
Начало выгрузки:   27.11.2020 9:47:49
Окончание выгрузки: 27.11.2020 9:52:33
Время выгрузки: 4:44
Начало выгрузки:   27.11.2020 10:03:01
Окончание выгрузки: 27.11.2020 10:06:15
Время выгрузки: 3:14 - значительно ускорилась выгрузка на 30%. Раньше думал, что объекты выгружаются только раз, сама КД2 это контролирует. Может галочки какие-то забыл поставить?

А при загрузке ошибки... не, не годится. Годится для случаев, когда документ только пишется в файл выгрузки. Если не впервые, то можно не писать. А для получения ссылки в другом документе это не годится.

Обычно когда в документе присутствует ссылка другого документа в его ПКС пишутся в Источник ссылка этого другого документа, в Приемник - его ссылка в приемнике, и имя ПКО. Если этот другой документ уже выгружался, то вместо этого можно обратиться к массиву ЗагруженныеДокументы, и получить из него его ссылку в приемнике. Это было бы быстрее, чем его выгружать заново. Возможно ли такое?

+ Есть возможность избежать многократную выгрузку одного и того же объекта?

(10) Что значит "свежий"? Абсолютно с самого начала 8.0 он всегда был многопоточным.

(0) ничего не сделаешь. КД редкостный тормозок. Гиговый файл XML стандартный обмен проглотит за несколько минут, а КД будет тупить до нескольких часов

(51) (52) Вообще-то это штатно так и работает...

(55) Время выгрузки не очень напрягает, а вот время загрузки... Вообще-то не смотрел файл выгрузки, есть ли в нем повторение выгрузки одного и того же объекта? Вроде КД2 должно само это контролировать, или в настройке что-то надо ставить... Что?

(56) ещё раз. Медленно (по слогам не буду, извини).
КД2. Повторно. Один и тот же объект. В один файл. Не. Выгружает.

Так понятней? Или ещё медленней повторить?

(57) Всегда, или по настройкам?

(58) По настройкам. Есть галка "Не запоминать выгруженные объекты", вот она, вроде, приводит к повторной выгрузке, но это надо код смотреть, так не помню

(59) Да, есть... но она наверное влияет на запись объекта в файл выгрузки. А на формирование объекта в приемнике - нет, повторяется. Ну, это влияет только на время выгрузки - не критично.