КД. Как ускорить загрузку?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Особенно самописный без правил а с прямым преобразованием кодом

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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