|
1С:Предприятие
:: 1С:Предприятие 8 общая
|
|
| ||
San335 24.11.20 - 09:01 | Доброго дня!
Подскажите плиз, есть ли какие рекомендации, либо приемы на оптимизацию этапа загрузки данных по правилам КД? Переношу по типовому правилу данные из одной типовой конфигурации в другую, но времени уходит катастрофически много. Конечно и объем данных большой, но хотелось бы понять, как ускорить его загрузку. Загруженности оборудования нет! | ||
Фрэнки 1 - 24.11.20 - 09:51 | И откуда бы она взялась-то... это самая загруженность...
Дело не в самих правилах КД, а в режиме работы самой базы. Реальное ускорение можно получить только если база окажется в абсолютно монопольном доступе, т.е. не будет ни одного лишнего сеанса. Если это в файловом режиме, то это обеспечить просто - в одной базе один активный пользователь. А если необходимо выполнять загрузку данных в базу непосредственно в клиент-серверном режиме, то будет иметь сильное значение версия платформы и нужен монопольный доступ, чтоб ни одна зараза на рпхост с процессом загрузки не покушалась - другими словами, нужна полная изоляция процесса загрузки от потенциальных конкурентов на блокировки. з.ы. О наличии рассуждений, что блокировки возникают только в одной базе и т.д. и т.п. - я все эти рассуждения уже слышал. При малом числе пользователей на сервере нужно включать опцию "одна база на процесс" и заходить в базу только одним активным пользователем. з.з.ы. Кстати, о том, что только один активный пользователь в базе очень приоритетно, это можно видеть на типовом процессе обновления самых свежих конф, в котором любые иные сеансы автоматически блокируются, кроме админа. | ||
San335 2 - 24.11.20 - 10:01 | (1) В базе работаю только я.Пробовал загрузку как с блокировкой регламентных заданий, так и без. А вот то, что 1 rphost конкретно только на меня не учел. На серваке херова народ работает в других базах, на этом же процессе. | ||
Фрэнки 3 - 24.11.20 - 10:30 | (2) ну вот забери все себе на локаль, тогда и станет понятно, есть шансы как-то ускорить процесс, ну и само собой, что комп должен быть более-менее шустрый.
А многопользовательский сервак... ну то такое... | ||
Йохохо 4 - 24.11.20 - 10:32 | (3) свежие и3 несвежие ксеоны и в хвост и в гриву) | ||
VladZ 5 - 24.11.20 - 10:33 | (0) "Загруженности оборудования нет!" - по каким параметрам определяешь загруженность оборудования? | ||
VladZ 6 - 24.11.20 - 10:34 | +5 База файловая? Или клиент-сервер? | ||
Фрэнки 7 - 24.11.20 - 11:01 | |||
Garykom 8 - 24.11.20 - 11:06 | (0) В случае sql базы 1С только отказ от КД и переход на свой обмен, с использованием много потоков/фоновых на сервере. | ||
Garykom 9 - 24.11.20 - 11:08 | XML имхо тормозной и когда все данные (объекты) в одном файле это не позволяет распараллелить процесс выгрузки/загрузки.
JSON лучше для этого подходит и писать разные объекты (элементы справочников, документы и записи регистров) в разный файлы или сообщения. Сообщения это использование RabbitMQ или аналоги. | ||
Garykom 10 - 24.11.20 - 11:10 | (2) свежий rphost он многопоточный из коробки, там упирается в ядра/потоки сервера
несколько rphost есть смысл держать только для повышения надежности если часто падает с точки зрения экономии ram лучше один rphost ибо несколько для одной базы/конфы будут дублировать конфу и кушать лишнюю оперативку | ||
San335 11 - 24.11.20 - 12:09 | (9) Свой обмен не вариант, т.к. используются типовые правила для ЗУП(немного мной переделанные). | ||
RomanYS 12 - 24.11.20 - 12:12 | (0) Причин может быть две: реально большой объем данных или неоптимальный код в правилах | ||
San335 13 - 24.11.20 - 12:18 | (12) Данных объем большой.Но для примера если взять выгрузку "Начальная ШР". 3 организации выгружаются примерно 6-7 часов. А если сделать связку сотрудников не с филиальной организацией, а головной, но время увеличивается с 7 до 21 часа((( | ||
Вафель 14 - 24.11.20 - 12:20 | (9) жсон от хмл отличается только формой скобочек | ||
Вафель 15 - 24.11.20 - 12:21 | распараллелить можно, но нужно отказаться от выгрузки по ссылкам | ||
San335 16 - 24.11.20 - 12:36 | (15) Доводилось сталкиваться с переводом ЗУП на версию 3.1? | ||
VladZ 17 - 24.11.20 - 12:52 | (7) Да, уже увидел. | ||
Garykom 18 - 24.11.20 - 13:39 | |||
mistеr 19 - 24.11.20 - 13:48 | Все такие эксперты в исцелении по фотографии.
Я бы посоветовал сначала найти узкое место. | ||
Фрэнки 20 - 24.11.20 - 14:04 | (19) узкое место искали еще в прошлой ветке. У ТС это уже не первая об этом самом переносе данных из старого ЗУП в новый ЗУП | ||
Сияющий Асинхраль 21 - 24.11.20 - 14:58 | Вопрос в (0) конечно актуальный, сам так и не нашел на него ответа. На хорошей по размеру базе УПП загрузка цен шла порядка десяти дней :-( , это был конечно пробный вариант, но рабочий с такой скоростью запустить так и не решились :-( | ||
d4rkmesa 22 - 24.11.20 - 15:07 | (13) Насколько большой объем? | ||
Garykom 23 - 24.11.20 - 15:46 | (13) Проведи тест.
Всю выгрузку подели на 2-4 части и проверь сколько будет загрузка параллельно через "Универсальный обмен данными в формате XML" на одной базе если несколько сеансов | ||
Garykom 24 - 24.11.20 - 15:48 | И да обмен через json примерно в два раза шустрей чем xmlОсобенно самописный без правил а с прямым преобразованием кодом | ||
timurhv 25 - 24.11.20 - 16:25 | (13) Так выгрузка или загрузка?
Раньше при переходе на редакцию 3.1 нужно было изменить порядок измерений в регистре (параметры запроса не попадали в индекс), ускорялся перенос раз в 5-10. | ||
d4rkmesa 26 - 24.11.20 - 16:32 | (24) Ну самописный писать довольно долго, вряд ли это выход для ТС. | ||
Aswed 27 - 24.11.20 - 16:35 | (0) Легко. Но надо смотреть на сами правила.
Я оптимизировал правила, с увеличением скорости загрузки в 20 с копейками раз, тупо убирая перезапись объекта если он есть в базе. Тут универсального механизма нет. | ||
timurhv 28 - 24.11.20 - 16:41 | (27) + часто виды начислений анализируются\перезаписываются. Мы вызывали процедуру 1 раз после загрузки всех данных. | ||
Фрэнки 29 - 24.11.20 - 17:00 | (25) у него выгрузка, судя по его прошлым ответам, формируется примерно одинаковое время, вне зависимости от выбранных настроек.
А вот загрузка начинает дико тормозить, если выставляют перед выгрузкой привязку работников к филиальной структуре. ХЗ, почему они там у себя не хотят установить такие подробности данных уже после загрузки, зачем им прямо в загрузке нагружать все такими данными, которые превращают процесс загрузки в невыполнимый квест. | ||
Фрэнки 30 - 24.11.20 - 17:03 | По идее, в результате всех этих невероятных усилий, должна заполниться ТабЧасть документа Начальная Штатная Расстановка. Просто немного странная и путанная структура данных в каждой строке ТЧ.
Но все нужные данные в базе уже записаны и к моменту создания ТЧ у этого документа там возможна перезапись уже записанных ранее, но и то, не факт, что они в действительности должны быть перезаписаны. Рекламное место пустует | ||
San335 31 - 25.11.20 - 08:41 | (25) Загрузка в 3.1. Работаю с типовой обработкой по переносу(Помощник перехода с прежних программ). Можешь подробнее про манипуляции с измерениями написать, после которых ускорился перенос???
Мне сейчас любые средства хороши) | ||
San335 32 - 25.11.20 - 08:43 | (27) Можешь написать, как убрать эту перезапись? Что-то я туплю....как раз перезапись существующих, а не добавление новых элементов в ЖР пишется и забирает на себя львиную долю времени! | ||
San335 33 - 25.11.20 - 08:44 | (28) Эту же проблему по ЖР наблюдаю. Напиши, плиз, как реализовать то, что ты написал? | ||
San335 34 - 25.11.20 - 08:46 | (29) "ХЗ, почему они там у себя не хотят установить такие подробности данных уже после загрузки, зачем им прямо в загрузке нагружать все такими данными, которые превращают процесс загрузки в невыполнимый квест." - все очень просто. В 2.5 была не верная привязка данных по филиалам и головной организации, в 3.1. сказали это дело исправить. | ||
San335 35 - 25.11.20 - 08:49 | Тут вопрос в длительности загрузки даже не чисто штатки. Этап "Кадровые данные" - более 2-х дней, "Учет среднего заработка" - более 2-х дней, "Учет НДФЛ" - чуть более суток. | ||
Sиlьver 36 - 25.11.20 - 08:58 | (35)Замеры производительности что-то говорят?
Когда-то давным давно сталкивался с тормозами обмена на КД. Заметил, что при распухании регистра сведений СоответствиеОбъектовИнформационныхБаз происходит очень медленная запись в него. К счастью у меня данные по УУИДам соответствовали и я мог себе позволить отключить использование этого регистра. Как временное решение могу посоветовать перевести базу в файловый режим, положить ее на комп с хорошим процом (с высокой тактовой частотой, количество ядер не важно) и SSD и прокачать данные. Должно быть гораздо шустрее. | ||
Ёпрст 37 - 25.11.20 - 09:09 | (0) дык правила смотри, чтоб все объекты выгружались только по ссылке(точнее, чтоб точно гуид ссылки выгружался, а не сам объект со всеми реквизитами).
+ Галки там смотри, чтоб только новый объект записывался или модиффицированный. Если реквизиты не поменялись, не записывай | ||
San335 38 - 25.11.20 - 09:19 | (36) Замеры каких-то тормозов не показали. РС "СоответствиеОбъектовИнформационныхБаз" судя по ЖР тоже не участвовал в медленных загрузках. | ||
San335 39 - 25.11.20 - 09:20 | (37) Ты имеешь ввиду, что у правил, в которых предполагается не создание, а только перенос ссылки выставить галки "Не замещать существующие объекты в приемнике при загрузке, а только создавать новые" + "Не создавать новый объект, если он не найден"? | ||
Ёпрст 40 - 25.11.20 - 09:26 | Не..там есть еще галка, чтоб при выгрузке для реквизитов ссылочного типа выгружался только гуид мсылки. + Если загрузка идет через поделку универсальный обмен хмл, то в ней поправить, чтобы записать было только, если объект модифицированн. | ||
Фрэнки 41 - 25.11.20 - 09:57 | (35) На мое мнение (постороннего человека), тут проблема все-таки не совсем в правилах. То, что правила будут неоптимальными для производительности - этого никто и никогда не себе не представлял. В любом случае, все эти правила придуманы просто по максимуму корректной передачи самих данных. Да, вполне возможно, что где-то и когда-то будут излишние дублирования записывания уже существующих записей, но! Это же надо каждый раз не просто принимать решение, что уже существующую по ссылке запись перезаписывать не нужно, а нужно всякий раз проверять все поля перезаписываемой записи - новая там информация на момент обработки текущих данных или нет.
Мало того, для связи с наборами текущих данных в один момент времени может быть одно состояние в полях всех записей набора, а в другой момент уже другое. И оно каждый раз будет верным, но только в том текущем. Короче говоря, я бы свел к минимуму все чрезвычайно длительные процедуры переноса и вносил изменения в уже записанные данные, условно говоря, после основного переноса. Например, // В 2.5 была не верная привязка данных по филиалам и головной организации, в 3.1. сказали это дело исправить // Исправляй это не штатным переносом данных, а уже после него - внеси изменения в данные в новой базе, но до начала работы пользователей и ввода новых документов пользователями. Проблема только в том, что когда пользователи начнут вводить и проводить новые документы, то они потянут ссылки на кривые данные, причем, кривизна не в том, что перенесено что-то не то, а что фактическая инфа не соответствовала состоянию учета и до переноса. Переносить нужно не новое, а нужно переносить без искажений. Для новой базы новое и верное состояние данных устанавливать не путем исправления в старой, а исправления уже в новой. Ну я думаю, что смысл моих рассуждений уже понятен :-) | ||
San335 42 - 25.11.20 - 10:33 | (40) "там есть еще галка, чтоб при выгрузке для реквизитов ссылочного типа выгружался только гуид мсылки." это в самих Правилах? Просмотрел ПКО и ПКС, похожей галочки не нахожу. Я чисто помощником перехода пользуюсь. Универсальный обмен хмл напрямую не использую. | ||
San335 43 - 25.11.20 - 12:48 | (27) В самих ПКО выставлял галку "Не замещать существующие объекты в приемнике при загрузке...", но при загрузке все равно вижу, как этот объект перезаписывается.. | ||
Фрэнки 44 - 25.11.20 - 12:53 | (43) там нужно ходить отлдчиком. Часть как-бы правил не действительна, если отладчиком добраться до исполняемых действий. | ||
Фрэнки 45 - 25.11.20 - 13:00 | т.е. вроде и правила - а как особые условия, то и пофиг оказываются все эти правила. | ||
timurhv 46 - 25.11.20 - 15:07 | (31) Регистр сведений "Плановый ФОТ" выставлял в редакции 3.1.7:
Сотрудник, Начисление, ГоловнаяОрганизация, ДокументОснование, ФизическоеЛицо, ДатаОкончания, Год Посмотрел в 3.1.14 и 3.1.15 - уже поправили. (33) Общий модуль УправлениеШтатнымРасписанием.ПрименитьИзменениеНастроекШтатногоРасписания - закомментируйте код. После загрузки всех данных вернуть обратно, сделать экспортной и вызвать из обработки. В новой редакции может еще где тормозов добавили - надо смотреть. Грузил на i7 + SSD. | ||
Pro-tone 47 - 25.11.20 - 15:30 | (0) есть способ - записывать только измененные объедки, но в функционале КД (обработка обменXML) его нет, и что там есть галка в КД2 - это фуфел, она нерабочая, потрать время, напиши код сравнения значений свойств и пиши только измененные объедки, это дает до 25% выигрыш при загрузке | ||
Pro-tone 48 - 25.11.20 - 15:32 | |||
Mikhail Volkov 49 - 27.11.20 - 08:44 | Документы продажи имеют ссылки (являются основанием) в других документах: оплаты, СФ... Прописал для пробы:
Если Не Отказ И Параметры.ЗагруженныеДокументы.Найти(Источник) = Неопределено Тогда Параметры.ЗагруженныеДокументы.Добавить(Источник); ИначеЕсли Не Отказ Тогда Если Параметры.Комментировать Тогда Сообщить("Уже выгружен: " + СокрЛП(Источник), СтатусСообщения.Информация); КонецЕсли; Отказ = Истина; КонецЕсли; В результате: Начало выгрузки: 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 это контролирует. Может галочки какие-то забыл поставить? | ||
Mikhail Volkov 50 - 27.11.20 - 14:16 | А при загрузке ошибки... не, не годится. Годится для случаев, когда документ только пишется в файл выгрузки. Если не впервые, то можно не писать. А для получения ссылки в другом документе это не годится. | ||
Mikhail Volkov 51 - 27.11.20 - 18:36 | Обычно когда в документе присутствует ссылка другого документа в его ПКС пишутся в Источник ссылка этого другого документа, в Приемник - его ссылка в приемнике, и имя ПКО. Если этот другой документ уже выгружался, то вместо этого можно обратиться к массиву ЗагруженныеДокументы, и получить из него его ссылку в приемнике. Это было бы быстрее, чем его выгружать заново. Возможно ли такое? | ||
Mikhail Volkov 52 - 28.11.20 - 06:00 | + Есть возможность избежать многократную выгрузку одного и того же объекта? | ||
Cyberhawk 53 - 28.11.20 - 10:07 | (10) Что значит "свежий"? Абсолютно с самого начала 8.0 он всегда был многопоточным. | ||
Конструктор1С 54 - 28.11.20 - 10:34 | (0) ничего не сделаешь. КД редкостный тормозок. Гиговый файл XML стандартный обмен проглотит за несколько минут, а КД будет тупить до нескольких часов | ||
ДенисЧ 55 - 28.11.20 - 10:52 | |||
Mikhail Volkov 56 - 28.11.20 - 11:14 | (55) Время выгрузки не очень напрягает, а вот время загрузки... Вообще-то не смотрел файл выгрузки, есть ли в нем повторение выгрузки одного и того же объекта? Вроде КД2 должно само это контролировать, или в настройке что-то надо ставить... Что? | ||
ДенисЧ 57 - 28.11.20 - 11:16 | (56) ещё раз. Медленно (по слогам не буду, извини).
КД2. Повторно. Один и тот же объект. В один файл. Не. Выгружает. Так понятней? Или ещё медленней повторить? | ||
Mikhail Volkov 58 - 28.11.20 - 11:21 | (57) Всегда, или по настройкам? | ||
ДенисЧ 59 - 28.11.20 - 11:33 | (58) По настройкам. Есть галка "Не запоминать выгруженные объекты", вот она, вроде, приводит к повторной выгрузке, но это надо код смотреть, так не помню | ||
Mikhail Volkov 60 - 28.11.20 - 12:31 | (59) Да, есть... но она наверное влияет на запись объекта в файл выгрузки. А на формирование объекта в приемнике - нет, повторяется. Ну, это влияет только на время выгрузки - не критично. Рекламное место пустует |
|
Список тем форума |