0. _ASZ_ 57 05.12.18 23:04 Сейчас в теме

Многопоточное восстановление последовательностей

Универсальный алгоритм многопоточного фонового восстановления любой последовательности.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. ifal 248 06.12.18 10:40 Сейчас в теме
А есть какие-нибудь замеры по выигрышу производительности, хотя бы примерные, на вашей конфигурации?
2. _ASZ_ 57 06.12.18 12:09 Сейчас в теме
(1) Есть опыт увеличения в 7-8 раз скорости восстановления последовательности в одной из крупнейших энергосетевых организации сибирского федерального округа. Но это была не типовая конфигурация.

На типовых конфигурациях подобный алгоритм ускорял восстановление последовательности расчетов в 4-5 раз (УПП 1.2), но такой "не революционный" результат был больше обусловлен характером данных в учетной системе. Есть также опыт восстановления последовательности партионного учета в УПП с аналогичным результатом.
3. starik-2005 1446 06.12.18 14:40 Сейчас в теме
Правильная статья. Эффект от многопоточности пропорционален количеству потоков и обратно пропорционален количеству блокирующих факторов, заставляющих один поток ждать другой поток.

Реальным решением, позволяющим в достаточно большое количество раз увеличить скорость проведения документов, является механизм, позволяющий читать исторические данные одномоментно и хранить их изменения для последующих документов. Дальше полученные записи регистров передаются многопоточному механизму записи. В итоге так и в 100 раз можно скорость восстановления последовательности повысить, т.к. нет конфликтов чтения данных. Но такой подход может быть реализован лишь в монопольном режиме, когда разные пользователи не изменяют данные.
4. _ASZ_ 57 06.12.18 14:53 Сейчас в теме
(3) Поддержу.

Отмечу еще, что представленный механизм дает не только ускорение как таковое. Да и вообще ускорение не было целью создания алгоритма. Цель - "забыть" о последовательностях как таковых. Оперативная работа пользователя в любом периоде должна была через 2-3 минуты давать возможность увидеть актуальную учетную картину.

При реализации описанного подхода последовательность восстанавливается самостоятельно. В организациях где это было реализовано, граница последовательности продвигается до максимального уровня сразу после изменения данных без трудозатрат пользователя. В итоге "запущенная" ситуации когда нужно что-то долго восстанавливать не наступает практически никогда.
5. starik-2005 1446 06.12.18 15:32 Сейчас в теме
(4)
В итоге "запущенная" ситуации когда нужно что-то долго восстанавливать не наступает практически никогда.
Основная проблема - это изменение "древних" документов, результаты проведения которых могут влиять на будущие данные. Самое простое и правильное решение - запрет изменения данных в пределах дня (или, как это сделано в серьезных системах - вообще, а все изменения производятся корректирующими операциями). Но уж если политика компании в плане учета позволяет изменять данные в широком диапазоне периодов, то это решить каким-то простым методом, конечно, не получается.
6. bulpi 137 06.12.18 22:20 Сейчас в теме
Черезвычайно интересно.
Но я не понял, как Вы решаете следующую проблему :
Допустим, нужно восстановить последовательность за месяц по 1 товару. Но при перепроведении документов получается, что в ТЧ этих документов попадаются и другие товары. Что, в свою очередь, порождает новые "пакеты задач" на восстановление последовательности. И т.д, Для того , чтобы восстановить последовательность по 1 товару, в конечном счете придется перепровести целое дерево документов, которое может по размеру захватить и 100% документов за месяц (зависит от связности товаров в ТЧ)
Чтобы этого избежать, придется переписывать алгоритмы проведения так, чтобы перепроводился не полностью документ, а только 1 товар из документа. А это очень сложно, а иногда даже принципиально невозможно.
7. _ASZ_ 57 07.12.18 04:07 Сейчас в теме
(6) При выборе примера я намеренно взял ситуацию, когда один документ может проходить по нескольким ключам последовательности. Но такую ситуацию, как Вы описываете я не стал рассматривать в картинках, т.к. это значительно бы усложнило восприятие.

По существу:
Алгоритм генерирует большой объем новых задач и проведение одного документа действительно может приводить к лавинообразному росту заданий и, как следствие, необходимости проведения других документов по другим ключам. Но это происходит ТОЛЬКО когда это следует из логики данных (избыточности нет). Механизм рассчитан на переваривание такой ситуации. Нет необходимости переписывать процедуры проведения документов для реализации возможности проведения только по 1 ключу из нескольких, задетых документом.
Хотя не спорю, если заморочиться и переписать - работать будет быстрее и "лавины" не будет. Но здесь возникает вопрос целесообразности такой работы. Практический опыт показал, что её нет. Если обработка заданий включена онлайн и есть адекватное движение даты запрета редактирования по отношению к точке ввода данных, то критические ситуации маловероятны.
А даже если они случаются - они обрабатываются в фоне практически без влияния на оперативную работу пользователей.
8. DarkAn 757 07.12.18 10:44 Сейчас в теме
Правильно ли я понял, что по одному картина получается примерно следующая: По каждому прибору учета запускается отдельное ФЗ?
Если да, тогда вопрос:
Предположим, для краткости мы запускаем восстановление в 5 потоков

ФЗ1: (Док1, ключ1) ->(Док2, ключ1)----->
ФЗ2: (Док3, ключ2) ->(Док4, ключ2)----->
ФЗ3: (Док5, ключ3) ->(Док6, ключ3)----->(Док12, Ключ1,Ключ2,Ключ3,Ключ4,Ключ5,Ключ6)
ФЗ4: (Док7, ключ4) ->(Док8, ключ4)----->
ФЗ5: (Док9, ключ5) ->(Док10, ключ5)--->
(Док11, ключ6)----------------------->

Поясню, Каждое ФЗ восстанавливает свой ключ, но у нас ограничение в 5 ФЗ, и дойдя до документа 12 с 6 ключами, все наши ФЗ встали, т.к. ждут восстановления ключа 6, а на него ФЗ не хватило?

Так же вопрос, не понял где происходит сдвиг границы последовательности?
9. _ASZ_ 57 07.12.18 10:51 Сейчас в теме
(8) 1. Не верно поняли. Когда ФЗ натыкается на ситуацию ожидания - обработка пакета завершается. ФЗ заканчивает свою работу, освобождая "слот" для других ФЗ. В следующий раз по этому ключу ФЗ стартует только при следующем старте управляющего потока. До этого момента - будут обрабатываться другие ключи.
2. В приведенном примере граница сдвигается автоматически при проведении документа.
10. DarkAn 757 07.12.18 13:26 Сейчас в теме
(9)
В приведенном примере граница сдвигается автоматически при проведении документа.

Есть ли смысл двигать границу каждым документом?

Как быть в типовых решениях, где нет измерений? Двигать каждым документом? Но тогда не будет параллельности. Или встраивать измерение и править типовые механизмы?
11. _ASZ_ 57 07.12.18 15:19 Сейчас в теме
(10) Тестовом примере двигать границу каждым документом, как мне кажется, вполне уместно :) Да и не в тестовом - тоже можно (зачастую, так и происходит в типовых конфигурациях от 1С).

По второму вопросу - мне кажется Вам стоит прочитать главу Ограничения в самом конце статьи. Там четко обозначено, что:
2. Последовательность должна корректно разделять данные на независимые ветви., также приведен соответствующий пример.
Ситуация, когда в типовой конфигурации от фирмы 1С последовательность не содержала бы измерений, мне не встречалась.
12. DarkAn 757 07.12.18 16:17 Сейчас в теме
(11)
Ситуация, когда в типовой конфигурации от фирмы 1С последовательность не содержала бы измерений, мне не встречалась

Да - в типовой УПП при восстановлении партий БУ есть измерение, но это только Организация, а ни как не Организация + Склад + Номенклатура.

Отсюда вопрос, что еще необходимо будет доработать в типовой УПП 1.3 для восстановления последовательности партий?
Что добавить - ясно:
* подсистема "Универсальные механизмы: пакеты данных";
* РС для блокировок;
* Общий модуль с вышеизложенными модулями;

Последовательность должна корректно разделять данные на независимые ветви


А вот что придется изменить в типовых метаданных?
* последовательность - добавить в нее измерения, да еще и не одно, а несколько (Организация - есть, + Склад + Номенклатура)?
* а так же закомментировать весь код типового движения по этой последовательности?
* еще что-то?

Или я все не так понял?

А как быть с последовательностями, если мы отдаем материалы в производств стороннему контрагенту и на выходе получаем готовую продукцию, которую списываем в производство? Ведь те документы кроме как "Заказом" ни как не связаны?

Т.е. Передача:
Склад1 + Затрата1
Склад1 + Затрата2
Заказ1

Поступление:
Склад5 + Продукция1
Заказ1

Как с учетом и обычного списания материалов со склада и с таким производство доработать последовательность???
EMelihoff; +1 Ответить
13. _ASZ_ 57 07.12.18 16:47 Сейчас в теме
(12) Если последовательность не разделяет данные на независимые ветви, то такую последовательность нужно дорабатывать. В противном случае о многопоточной обработке можно забыть.

С решением прикладной задачи я думаю Вы сможете справится самостоятельно.

P.s.: про поблемы в УПП я знаю. И если вы посмотрите внимательно, на ситуацию, которой я демонстрирую ограничение №2, возможно вы узнаете свою проблему :).
P.p.s.: эту проблему я решал на УПП 1.2 путем доработки последовательности, но приводить описание своих действий здесь не считаю целесообразным.
14. DarkAn 757 07.12.18 17:01 Сейчас в теме
(13)
С решением прикладной задачи я думаю Вы сможете справится самостоятельно.

Так в этом и вопрос, что на простом примере, где четко можно разделить по "приборам учета" - все просто и даже понятно, но в реальной задаче уже сложности. Получается как с картинкой про "Сову"


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

Зачем забывать?
Многопоточность. Универсальный «Менеджер потоков» 2.0 - позволяет решить вопрос восстановления без доработок последовательности, без добавления "фиктивных" объектов метаданных.
15. _ASZ_ 57 07.12.18 17:30 Сейчас в теме
(14) Ясно откуда ноги растут :) сразу не догадался.

Ваше решение также заслуживает внимания. Я рад, что Вы нашли место для его продвижения здесь.
16. DarkAn 757 07.12.18 17:52 Сейчас в теме
(15)
Я рад, что Вы нашли место для его продвижения здесь.

Вопрос не только в продвижении.
Мне действительно интересны статьи и разработки связанные с многопоточностью.
В предложном Вами решении я так же нашел массу интересных направлений натолкнувших меня на ряд идей :).
17. logarifm 1020 08.12.18 14:28 Сейчас в теме
Ну все это хорошо. Вот тут вопрос к 1С скажите, а почему зная о колосальной проблеме в типовых решениях не сделать многопоточность в качестве инструментария типовых решений, почему люди пилят вот такие собственные "костыли" ?...

К сожалению 1С этот вопрос никогда не увидит и точно ответа не дадут. Но из ряда вон у меня есть масса претензий к этим умным людям. Вместо того чтобы разрабатывать действительно требовательные механизмы затрагивающие область оптимизации (это не только многопоточность), а вообще маштабированность кластеров и стабильность их. Вот вместо этого мы на зазеркалье читаем (мы вот тут добавляем чат в 1С назвав это крутым словом ВЗАИМОДЕЙСТВИЕ).

А потом через некоторое время еще: мы тут такую крутую штуку придумали к этому чату, теперь вы можете через нее файлы передевать.
18. acanta 45 08.12.18 14:30 Сейчас в теме
Потому что для файловой базы это работать не должно, а конфигурация та же. Тот кто покупает серверную версию должен понимать, что конфигурация у него все равно для файловой базы с некоторыми встренными готовыми костылями.
19. logarifm 1020 08.12.18 14:31 Сейчас в теме
(18) это элементарно отбивается двумя строчками кода Если ФайловыйРежим Тогда по обычной схеме!
20. logarifm 1020 08.12.18 14:33 Сейчас в теме
(18) Вообще покажите мне хоть одно предприятие где людей в базе от 50 человек, что они работают в файловой базе - это как минимум кощунство или банально ЖЛОБСТВО я бы точно там никогда бы не работал программистом!
21. acanta 45 08.12.18 14:35 Сейчас в теме
Причем здесь предприятие мы говорим об архитектуре тиражных решений. Либо все предприятия до 10 пользователей будут работать на системе для серверных версий, либо всем серверным придется мириться с принципами работы небольших баз. Как по вашему, чьими интересами пожертвуют?
22. logarifm 1020 08.12.18 14:36 Сейчас в теме
23. acanta 45 08.12.18 14:49 Сейчас в теме
Предприятия в принципе растут или в кризис сокращаются и если сегодня на нем 10, то завтра может быть 70,и наоборот. 1с этого не предусматривает.
24. spock 581 08.12.18 22:45 Сейчас в теме
Саша, вы продолжаете развиваться КЭО? Смотрю, Учет приборов учета прижился )
25. _ASZ_ 57 09.12.18 06:58 Сейчас в теме
(24) В КЭО практически нет нового функционала. Последний год мы только переписываем/рефакторим КЭО. В частности переписали полностью пофидерный анализ. Старые документы и всю подсистему приборов учета выкорчевали, т.к. она оказалась нежизнеспособной. Создали новые объекты/регистры и пр.

Сейчас занимаемся внедрением 1С:ТОиР. Уже введено более 1 млн объектов ремонта, формируются полностью заполненные паспорта ВЛ. Запустили геоинформационную систему, которая позволяет визуализировать сеть и топологию на Яндекс картах.
26. spock 581 09.12.18 17:39 Сейчас в теме
(25)Молодцы, неплохо. По ПУ зря - шикарное и быстрое решение могло получиться. Здорово, что смогли реализовать мои предложения.
27. Anchoret 32 10.12.18 09:53 Сейчас в теме
Сейчас как раз пытаюсь реализовать подобное у бухгалтерии 3.0, за пример взял статью с ИТС (https://its.1c.ru/db/metod8dev/content/5843/hdoc), то есть добавил в последовательности "ДокументыОрганизаций" измерение "ДоговорКонтрагента". Казалось, что всё довольно просто, но как оказалось проблема не в том, как распараллелить, а в том, что далеко не во всех документам последовательности есть такой реквизит и не каждый документ можно отнести к конкретному договору (требования-накладные, операция, перемещение товаров, передача ОС и т. п.). В итоге оказалось, что документов с договорами совсем немного больше, чем документов без договоров. Результат получился следующий:
Формируется таблица документов из последовательности, документы без договора проводятся последовательно, когда доходит до документов с договорами, такие документы разбиваются на 5 потоков и проводятся параллельно

Количество документов: 32585
Время проведения: 8:32:57 (6:31:52)

Количество документов: 38958 (документов с договорами стало гораздо больше)
Время проведения: 11:06:13 (8:27:17)

Как видно, выгода по времени есть, но нельзя сказать, что у меня она получилась особо впечатляющей
28. _ASZ_ 57 10.12.18 10:17 Сейчас в теме
(27) Вашу ситуацию можно также можно попробовать решить с помощью предложенного алгоритма. Вы вводите в последовательность измерение Договор. Те документы, которые не имеют договора - также должны в эту последовательность попадать (Договор = ПустаяСсылка).

Нужно будет запрос в обработчике пакета доработать следующим образом: если в текущем ключе договор - пустая ссылка, то мы не ищем корреспондирующие ключи, а смотрим есть ли в последовательности документы (вообще без отбора по измерениям) , которые нужно проводить ранее нашего. В этом случае текущее задание будет ждать пока все документы, ранее текущего будут проведены в нужной последовательности.
29. Manoshkin 339 11.12.18 10:18 Сейчас в теме
Насколько я понял задания создаются по документам проведенным "задним числом". Мы использовали иной подход: выявляли ошибки в партиях (это можно сделать одним запросом и достаточно быстро) за период и перепроводили только документы с ошибками. Далее проверяли следующий период. И чем меньше ошибок, тем быстрее восстановление. Штатно на УПП 1.3 тратили несколько дней, теперь для предварительной оценки месяца достаточно полчаса-час. На чистовую побольше. https://infostart.ru/public/805321/
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Старший Программист 1С НОВОСИБИРСК
Новосибирск
зарплата до 130 000 руб.
Полный день

Программист 1С
Новосибирск
зарплата от 75 000 руб.
Полный день

Ведущий программист 1С
Воронеж
зарплата от 90 000 руб. до 120 000 руб.
Полный день

Программист 1С
Воронеж
зарплата от 65 000 руб. до 90 000 руб.
Полный день