|
v8: Ускорение восстановления последовательности документов в УПП. | ☑ | ||
---|---|---|---|---|
0
МуМу
29.03.11
✎
13:27
|
Дано: Есть УПП с партионкой. Нужно восстановить последовательность документов(путем перепроведения) с партионным учетом с целью перерасчета правильной себестоимости.
Предположим серверные настройки оптимальные, сервер очень мощный. Линейное ускорение проведения документов, за счет оптимизации запросов, возможно не более чем на 15%. Стоит цель ускорить время проведения в 3-5 раз. Каким образом можно это сделать и от чего это зависит? |
|||
1
shuhard
29.03.11
✎
13:29
|
(0)[сервер очень мощный.]
дисковая подсистема очень быстрая ? |
|||
2
asp
29.03.11
✎
13:31
|
путем апгрейда железа
|
|||
3
МуМу
29.03.11
✎
13:32
|
(1) Ага,очень быстрая дисковая подсистема и многопроцессорный сервак(предположим 8-16 процессоров). Ну и сервер приложений такой же.
|
|||
4
МуМу
29.03.11
✎
13:33
|
(2) Не верно. При доп. вложении равной стоимость существующего сервера удастся ускорить только на 15-20 процентов.
|
|||
5
asp
29.03.11
✎
13:33
|
в данном конкретном случае рулит скорость одного ядра, а не количество процессоров
|
|||
6
asp
29.03.11
✎
13:34
|
(4) а теперь моя практика: вместо стоечного сервака HP куплен десктоп за 40% цены сервера. последовательность на нем восстанавливается в три раза быстрее.
|
|||
7
МуМу
29.03.11
✎
13:35
|
Данный вопрос родился в контексте последней дискуссии с коллегами. Выяснилось что подавляющее большинство ничего не знает на тему параллельных вычислений, об архитектуре современных серверов.
(5) Это верно. |
|||
8
asp
29.03.11
✎
13:36
|
(6) не, даже не 40%. сервер стоил 300 где-то, десктоп 50.
|
|||
9
МихаилМ
29.03.11
✎
13:36
|
фоновые задания + отложенный расчет итогов.
+ изменение алгоритмов (выборочное перепроведение, запись движений отклонений ...) |
|||
10
shuhard
29.03.11
✎
13:38
|
(3)[очень быстрая дисковая подсистема]
RAM диски |
|||
11
МуМу
29.03.11
✎
13:38
|
(6) Для каждой конкретной задачи хорошо свое железо. В любом случае для данной задачи будет максимальное ускорение 50 % , либо это будет означать что предыдущий сервак был совсем стареньким. Для современных серваков замена как я уже писал раньше будет 15% и расти потом нелинейно в соответсвии к затратам.
Напомню , я говорю о ускорении в 3-5 раз. |
|||
12
shuhard
29.03.11
✎
13:39
|
(7)[Данный вопрос родился в контексте последней дискуссии с коллегами. Выяснилось что подавляющее большинство ничего не знает на тему параллельных вычислений, об архитектуре современных серверов. ]
ужо.с срочно всех на семинары http://softpoint.ru/ |
|||
13
МуМу
29.03.11
✎
13:40
|
(9) Данную задачу рассматриваем как регламентную которую нужно выполнить в конце месяца. То есть надо перепровести все документы.
|
|||
14
МихаилМ
29.03.11
✎
13:40
|
не описаны условия задачи,
можно менять алгоритмы проведения. можно использовать, прямые запросы, можно ли проводить расчеты в отдельной копии, не в разделенном режиме и результаты загружать . |
|||
15
МуМу
29.03.11
✎
13:42
|
(12) Этого я не говорил и рекламы семинара в этой ветке не будет. Мне интересно предложит ли кто нибудь более менее точную концепцию реализации. Задача достаточно актуальная. В конце ветки я обязательно отвечу на этот вопрос.
|
|||
16
shuhard
29.03.11
✎
13:44
|
(15)[В конце ветки я обязательно отвечу на этот вопрос.]
ждём-с |
|||
17
МуМу
29.03.11
✎
13:44
|
(14).
Алгоритм проведения менять нельзя. Прямые запросы использовать можно(даст эффект минимальный 10-15%) Расчеты в отдельной копии можно делать.Только что это даст? Важна же хронология документов, один документ влияет на другой.(на себестоимость) |
|||
18
Aleksey
29.03.11
✎
13:59
|
(17) Ну почему расчет в файловой версии плюс выгрузка/загрузка в скуль иногда быстрее на порядок, чем просто расчет на скуле
|
|||
19
Господин ПЖ
29.03.11
✎
14:02
|
(18) базы которые влезают в 1cd я думаю МуМу не интересуют...
|
|||
20
Aleksey
29.03.11
✎
14:08
|
(19) А зачем пихать всю базу, если мы проводим 1 месяц. Конечно если даже и месяц туда не влазит...
|
|||
21
shuhard
29.03.11
✎
14:17
|
(20) партии и взаиморасчеты ты умеешь урезать до месяца ?
|
|||
22
Aleksey
29.03.11
✎
14:18
|
(21) Да, ввод начальных остатков. Зачем тебе движения за старые месяца, если по сути тебе нужны только итоги?
|
|||
23
shuhard
29.03.11
✎
14:21
|
(22) блеск, полный отказ от ФИФО в партионном учете
|
|||
24
Aleksey
29.03.11
✎
14:22
|
МуМу не думаю, что кроме тебя кто-то активно здесь занимался этим вопросом, поэтому рассказывай очень интересно послушать
|
|||
25
Ёпрст
29.03.11
✎
14:23
|
отключить итоги, весь пересчет итогов делать в своих временных табличках во время перепроведения.
Разве что. |
|||
26
Aleksey
29.03.11
✎
14:23
|
(23) Э а каким боком тут ФИФО? По твоему когда программа перепроводит документы за март она берет движения за прошлый год? Или все таки остатки на документ?
|
|||
27
Ёпрст
29.03.11
✎
14:24
|
+25 т.е сделать аналог с семёрошным толканием ТА вперёд.
|
|||
28
Aleksey
29.03.11
✎
14:27
|
(25) По сути не перерасчет итогов, а весь расчет движения и писать движения уже самостоятельно. Плюс добавим сюда запись только измененных движений (обычно расчет происходит быстрее чем запись). Т.е. движения не поменялись, значит не переписываем их, а оставляем старые
В теории ускорения должно быть достигнуто за счет отказа перерасчета итогов на каждый измененый документ (итоги в конце считаются) ну и меньше количеств записей документов (чем меньше изменений, тем быстрее перепроводка) |
|||
29
iamnub
29.03.11
✎
14:28
|
(0)
Автор - ламо. |
|||
30
Aleksey
29.03.11
✎
14:28
|
(27) Там немного по дурацки сделано. По сути как такового ТА нет, а программа смотрит, есть движения после этого документа, значит нужно рассчитывать итоги - нет движения - берем на ТА. Т.е. ТА нельзя двинуть взад, можно только очистить движения впереди, тогда будет расчет на ТА
|
|||
31
Ёпрст
29.03.11
✎
14:29
|
(28) ну да..
Вот еслиб ешще и период хранения останков был бы короче, 5 дней к примеру, а не месяц - еще быстрее было бы проведение, в разы. |
|||
32
Ленинград
29.03.11
✎
14:30
|
зачетный вброс
|
|||
33
Aleksey
29.03.11
✎
14:30
|
(29) Я бы не стал так говорить на автора, просто ему интересно послушать мнения других, но поверь знаний его в этом вопросе (особенно по 7-ке) поболее чем у многих вместе взятых
|
|||
34
iamnub
29.03.11
✎
14:30
|
(0)
Пока ты там концепции изобретаешь - у людей уже все давно работает. Ускорение - 12Х. |
|||
35
azernot
29.03.11
✎
14:31
|
(26) Возврат с указанным документом партии никогда не проводил? Там-то как раз нужны движения изначального документа...
|
|||
36
shuhard
29.03.11
✎
14:32
|
(33) компетенция ТС сомнений не вызывает,
формат топик прикольный, ответ знаю, но не скажу. в итоге флюд про сферического коня в вакууме |
|||
37
iamnub
29.03.11
✎
14:32
|
v8: Проведение расходного документа по партиям за 0.045 секунд?
В 21-ом посте все расписано. |
|||
38
iamnub
29.03.11
✎
14:34
|
(38)
Можно еще быстрее - ХРАНИМКОЙ на СЕРВЕРЕ!! |
|||
39
iamnub
29.03.11
✎
14:39
|
(15)
"Мне интересно предложит ли кто нибудь более менее точную концепцию реализации." Приз-то будет? |
|||
40
asp
29.03.11
✎
14:40
|
не хватает условия, что все это нужно делать на типовой конфе.
|
|||
41
azernot
29.03.11
✎
14:40
|
Как показывает практика 80% необходимости восстановления последовательности связано с изменением сумм (без изменения собсвтенно количества и момента времени документов), соответсвенно в большинстве случаев достаточно пересчитать суммы, без полного перепроведения документов.
Убыстрял восстановление последовательности методом отдельного пересчёта запросами и прямой записи. По сути метода сводилось к следующему: 1. Проверяем корректность распределения по партиям (упрощённо - в случае ФИФО если есть остаток по более ренней парти с учётом всех допустимых статусов, отборов и т.п. - значит распределение некорректно и документ нуждается в перепроведении). На этом этапе полностью забиваем на себестоимость, нас интересует только корректность списания количества по партиям. Повторяем п.1 до тех пор пока в интересуемом периоде все партии корректно не распределятся. 2. Восстанавливаем прямой записью суммы партий и связанных движений. Прирост скорости колоссальный. Во-первых я в п.1 перепровожу только документы с реально некорректными партиями, во-вторых в п.2 я восстанавливаю суммы реально только там, где это необходимо. В идеале бы конечно ещё и в п.1 менять партии без перепровдения, но у меня как-то руки не дошли. |
|||
42
wPa
29.03.11
✎
15:29
|
(41) Это не панацея, поскольку не дает гарантии, что будут исправлены оставшиеся 20%, связанные с переносом докумнтов со пересписанием списанных партий, вводом новых партий без их списания по методике. Это лиш метод исправления заранее известной ошибки - операция над больным - конечное решение, а не полное лечение.
Убыстрение восстановления партий должно быть связано только с восстановлением партий, но к сожалению движения по другим регистрам по методике 1С завязано на партиях. Развязать их, вытащить из одной транзакции - вот имхо путь к решению проблемы. |
|||
43
azernot
29.03.11
✎
15:53
|
(42) Ты не прав, 20% - лечится пунктом 1, когда восстанавливается корректность списания по партиям (в т.ч. и наличие отрицательного остатка после регистратора по партиям - симптом некорректности).
Двжиения других регистров (я их называю связанные движения) я также корректирую в п.2. Развязать их нельзя, информация в связанных регистрах как раз и берётся из партий. Развязать их - значит организовать некие регламентные процедуры (типа сформировать проводки только в конце месяца).. |
|||
44
МуМу
29.03.11
✎
16:34
|
Отходил пообедать. Сейчас буду отвечать.
|
|||
45
МуМу
29.03.11
✎
16:40
|
(38)В контексте этого подхода не хочу спорить потому как долго разбираться чего там скоряется в 12-ть раз. Предположим для простоты что запросы по партионке реализованы хранимкой на сервере. Как в этом случае можно реализовать данную задачу?
|
|||
46
iamnub
29.03.11
✎
16:43
|
(45)
Я твоего поста вообще не понял. Ты просил "более менее точную концепцию реализации." Я показал решение - работает сейчас. Ты говоришь - что тебе долго разбираться - чего там ускоряется. Вводишь какие-то новые условия, запросы, хранимки... Лучше я тебе вопрос задам - когда коту делать нечего - он чем занимается? |
|||
47
МуМу
29.03.11
✎
16:43
|
(41)Это немного другой подход. Для реализации минимальной задержки актуальной себестоимости применялся подход в котором логировались изменения задним числом. Затем пересчитывались только те документы и только те движения документов на которые они влияли. В данной концепции будем считать что поменялось все и надо все перепровести.
|
|||
48
Reaper_1c
29.03.11
✎
16:45
|
отказаться от ПУ в пользу РАУЗ.
|
|||
49
Нуф-Нуф
29.03.11
✎
16:46
|
переходите на рауз
|
|||
50
МуМу
29.03.11
✎
16:46
|
(46) Ладно , почитаю.
Условие основное следующее. Изменение кода не допускается, точнее допускается добавить 10 строк кода в существующий код. Это важно с точки зрения того что данное решение не должно привести к изменению логики существующей системы. |
|||
51
МуМу
29.03.11
✎
16:47
|
(50)+Под кодом я подразумевал код модуля проведения документов.
|
|||
52
Mikeware
29.03.11
✎
16:47
|
(49) моим уточненная себестоимость бывает нужна каждый день. а иногда и не по разу...
|
|||
53
MaxS
29.03.11
✎
16:48
|
(0) Подходит ли вариант с распределенной базой? Полный обмен. В соседней базе никому не мешая, в монопольном режиме перепроводится всё, что нужно, потом обменом попадает в рабочую базу.
Именно под эту отдельную базу можно подобрать соответствующее железо. А для рабочей базы, где работают много пользователей подобрано другое железо под соответствующие задачи... |
|||
54
МуМу
29.03.11
✎
16:54
|
(53) Данное решение имеет право на существование но имеет ряд минусов.
В текущей базе нужно закрывать определенный период. Потому как только с даты предыдущего закрытого периода по дату текущего закрытого периода имеет смысл перепроводить документы.(иначе любое изменение задним числом приводит к возникновению подобной задачи повторно) Затем необходимо реализовывать механизмы обмена. С другой стороны если есть возможность период закрывать, тогда лучше ночью делать пересчет по дату закрытого периода и не парится с обменами. |
|||
55
Ёпрст
29.03.11
✎
16:57
|
(54) это, а сколько сейчас по времени занимает примерно проведение одного документа в "заднем" числе ?
ну, строк на 100 в табличной части.. ? Так, для справки. |
|||
56
vis_tmp
29.03.11
✎
17:02
|
(55) Смотря насколько оно "заднее"...
|
|||
57
Нуф-Нуф
29.03.11
✎
17:10
|
(52) хз. да каких целей может понадобится себестоимость текущего дня?
|
|||
58
iamnub
29.03.11
✎
17:12
|
Дурью маетесь, господа.
|
|||
59
Ёпрст
29.03.11
✎
17:13
|
(57) профит глядеть..
у нас после проведения накладной смотрят профит в самом документе.. от этого прикидывают скидку/наценку.. Профитная система оплаты, понимашь. |
|||
60
Mikeware
29.03.11
✎
17:14
|
(57) Не текущего - вчерашнего, позавчерашнего. Но в течение дня могут править и "месяц взад", и даже глубже...
"оказалось, что вот это нам привезли дороже, это- дешевле, а вот это как бонус. а насчет этого согласовали с клиентом скидку (наценку за доставку на север)... " |
|||
61
shuhard
29.03.11
✎
17:15
|
(59) бывает и прикольней,
у меня каждую ночь в УПП документы перепроводятся за открытый период |
|||
62
Mikeware
29.03.11
✎
17:16
|
(59) нет, этого нет. более того, менеджеры не с реализациями работают. И реализации массово появляются начиная с 19 часов..
|
|||
63
Aleksey
29.03.11
✎
17:20
|
(59) мои профит видят уже в сделки, а руководство вообще периодически хочет видеть предварительный анализ продаж, который работает не по реализациям, а по заявкам, т.е. по резервам :(
|
|||
64
Ёпрст
29.03.11
✎
17:22
|
ну так, у кого сколько проводится реализация ?
Закинул демку упп в скуль 2008, на серваке 24 ядра, 24 гига оперативы, всё на 10 рейде Время проведения одного документа в среднем 18 секунд. Это нормально ? |
|||
65
Aleksey
29.03.11
✎
17:22
|
(53) нет не подходит. Я тут давеча за два года перепровел почку бухии, так потом 2 дня ждал когда она в центр загрузиться, так и не дождался. Пришлось убить регистрацию. Такие большие объемы потом хрен куда загрузишь, так что теперь стараюсь больше одного квартала за раз не перепроводить
|
|||
66
ДенисЧ
29.03.11
✎
17:23
|
(64) типовая - 100 позиций РТиУ, 4 месяца назад, всего четыре месяца в базе - 50 секунд. После моих шаловливых - та же накладная 7-9 секунд...
|
|||
67
Ёпрст
29.03.11
✎
17:24
|
(66) да уж.. переходите на снеговик - там всё реализовано ?
:)) |
|||
68
Новиков
29.03.11
✎
17:24
|
(63) это реализовано - ну профит по резервам?
|
|||
69
Aleksey
29.03.11
✎
17:25
|
Вот если бы типовой интерактивный обмен мог грузить порциями, тогда да. А так ...
p.s. хотя вроде бы фоновый так может, но типовой фоновый только с УТ |
|||
70
ДенисЧ
29.03.11
✎
17:25
|
(67) угу. Расчёт себестоимости за месяц (30 000 ОПзС) - 17 часов. После шаловливых - около 8. Тех же часов...
|
|||
71
ptiz
29.03.11
✎
17:26
|
(0) Не томи! Рассказывай!
|
|||
72
Aleksey
29.03.11
✎
17:26
|
(68) в заявке да (тупо скопировл из механизма проведения механизм расчета партий, т.е. делаю "виртуально проведение")
|
|||
73
Mikeware
29.03.11
✎
17:28
|
(65) В снеговике?
|
|||
74
Aleksey
29.03.11
✎
17:29
|
(73) Угу в типовом непереписанном снеговике, в БП 2.0
|
|||
75
Новиков
29.03.11
✎
17:31
|
(72) а обычные рту, потом используют списывают те партии из резерва?
|
|||
76
Aleksey
29.03.11
✎
17:31
|
(73) Там просто все это делается в одной транзакции, плюс в УРИБ обмене если изменились движения, то программа регистрирует эти изменения для ВСЕХ почек.
|
|||
77
Mikeware
29.03.11
✎
17:35
|
В принципе, обмен можно и переписать слегка....
|
|||
78
Aleksey
29.03.11
✎
17:35
|
(75) Нет партии не хранятся. Просто показывает результат, который был бы если бы сейчас провели реализацию из этой заявки. Т.е. понятно, что когда появиться реализация партия может быть другой (могут, но не обязаны быть другими), но оценит примерный профит это позволяет.
Впрочем аналогичное может произойти и с проведенной реализацией (изменили время, изменили приход). Так что даже если мы зафиксируем партии, то это не гарантирует нам аналогичный профит в реализации, а раз так, то трудозатраты по фиксации, себя не окупают, и поэтому смысла фиксировать их нет |
|||
79
Новиков
29.03.11
✎
17:36
|
(78) а списание автоматическое ГТД в РТУ у вас есть?
|
|||
80
Aleksey
29.03.11
✎
17:37
|
(79) ГТД в партиях сидит, при проведении, они фиксируються в ТЧ и потом не меняються
|
|||
81
Новиков
29.03.11
✎
17:40
|
(80) А как же вы счет-фактуру с непроведенного рту печатаете? Проводок же не будет по ГТД?
|
|||
82
МуМу
29.03.11
✎
17:51
|
Подсказка. Все это сводится к задаче параллельных вычислений.
|
|||
83
Mikeware
29.03.11
✎
17:53
|
(82) тут разницу между строковыми и числовыми переменными осилить не могут, а ты про "параллельные вычисления" задвигаешь... :-)
|
|||
84
ptiz
29.03.11
✎
18:33
|
(82) Распараллелить вычисления по разным товарам?
|
|||
85
Aleksey
29.03.11
✎
18:34
|
(81) Мы счет-фактуру по заявки не печатаем
|
|||
86
Mikeware
29.03.11
✎
18:36
|
(84) ну в принципе, почему бы и нет. а после - пересчет по взаиморасчетам. Только будет ли быстрее?
|
|||
87
Aleksey
29.03.11
✎
18:36
|
(82) Была идея засунуть в последовательность измерение товар, и перепроводить конкретно по кривому товару, а не все документы
|
|||
88
Mikeware
29.03.11
✎
18:38
|
(87) в условии задачи - перепроводить всё.
|
|||
89
Aleksey
29.03.11
✎
18:39
|
(88) В условиях ускорения, а не полное перепровдение.
|
|||
90
МуМу
29.03.11
✎
18:46
|
Провести нужно все.
(84) Ну если уж совсем вообщем - да. Нужно заставить работать все процессора сервера.Заставить проводить параллельно максимальное количество документов в единицу времени и при этом не нарушать последовательность. Вопрос теперь, как концептуально это реализовать? |
|||
91
МуМу
29.03.11
✎
18:48
|
(89) Если изменились несколько позиций задним числом то действительно существуют другие более эффективные способы. В данном случае это не тот вариант. Считаем что поменялось все.
|
|||
92
zaki
29.03.11
✎
18:55
|
Закладка
|
|||
93
Ёпрст
30.03.11
✎
08:19
|
(91) ты спрашиваешь готовое решение или своё хочешь предложить ?
|
|||
94
МуМу
30.03.11
✎
10:09
|
(93)Мне интересно, есть ли вообще понимание как подобное может быть возможным.(эта ветка мне интересна для анализа статей, которые я сейчас дописываю) Концепцию я здесь в любом случае расскажу чуть позже.
|
|||
95
Ёпрст
30.03.11
✎
10:19
|
(94) дык это будет просто концепция, или готовое рабочее решение ?
|
|||
96
Ёпрст
30.03.11
✎
10:20
|
+95 просто сейчас, упп из "коробки" - это просто мусор.
|
|||
97
МихаилМ
30.03.11
✎
10:26
|
(94)
окончание статьи я могу угадать " У автора имеется готовое решение...." |
|||
98
МуМу
30.03.11
✎
10:27
|
(95)Это будет описание технологии. Никто не мешает ее реализовать самому. Но как показывает практика(древние статьи на тему производительности 7-ки) от описания до практической реализации очень далеко. Большитнство просто не хотят заморачиваться(как правило если с наскока не получилось то дальше лень) над этим, впрочем в этом есть тоже свои плюсы.
|
|||
99
Mikeware
30.03.11
✎
10:30
|
(97) сочинение "если б я стал президентом..." ты тоже писал?
|
|||
100
Ёпрст
30.03.11
✎
11:43
|
(98) ждёмс.
|
|||
101
shuhard
30.03.11
✎
11:46
|
(90)[.Заставить проводить параллельно максимальное количество документов в единицу времени и при этом не нарушать последовательность.]
примитивный фокус с 10 Организациями в одной базе и параллельным запуском в 10 1с.exe восстановления по одной организации мистой зачтен не будет |
|||
102
МуМу
30.03.11
✎
19:32
|
(101) Обижаете, подобная задача недостойна обсуждения:)
|
|||
103
shuhard
30.03.11
✎
20:39
|
(102) и я о том же,
такой примитив мисту не интересует |
|||
104
John83
30.03.11
✎
21:30
|
(6) извиняюсь за глупый вопрос, но что такое "стоечный десктоп"?
|
|||
105
serffer
30.03.11
✎
21:37
|
Очень интересная тема.
|
|||
106
Ferz
30.03.11
✎
23:32
|
есть идеи но настолько невероятные что их нужно пробовать.
общая концепция примерно такая n -процессов подготовительные 1 -замыкающий, который и выстраивает последовательность. Задача подготовительных процессов сохранить откомпилированные запросы и обновить статистику. Это единственный вариант последовательного!!! (увы с последовательностью ничего не придумаешь) проведения без оптимизации запросов и изменения логики |
|||
107
cathode
31.03.11
✎
08:50
|
(106) Если мыслить в рамках одного потока исполнения, действительно кажется, что с последовательностью ничего не поделаешь, так как она кажется набором отметок на временной оси. Но это всегл лишь умственная проекция - удаление одного из измерений. Если у нас, к примеру, есть набор документов, в которых списывается всегда один товар А, а есть набор документов, содержащих только товар Б, то при параллельном проведении этих двух линеек документов важен будет только их порядок друг относительно друга, но не проекция на глобальную временную ось. И в результате такого проведения мы получим то же самое, что и при стандартном подходе "в очередь, сукины деты, в очередь". Таким образом, задача ускорения проведения документов заключается в построении графа зависимостей вхождения номенклатурных позиций в документы от их дат и обработке этого параллельными вычислениями.
Как "наивную", но теоретически верную реализацию, можно предложить следующий подход: на каждую номенклатурную позицию, которая списывалась в данном периоде, создаем один поток исполнения; на всех документах, содержащих более одной строки, на входе ставим джойн всех потоков номенклатур, входящих в этот документ, на выходе - соответственно сплит. На сервере как-то организуем пул исполнителей всех этих потоков с количеством исполнителей, достаточным для загрузки всех процессоров сервера. В результате имеем профит в виде в среднем процессор-кратного ускорения проведения документов и это еще до оптимизации кода проведения. Я не спец в параллельном программировании, идея мне самому кажется слегка бредовой, просто в этой ветке большинство предлагают стереотипные подходы, а я решил предложить фантастический. |
|||
108
Ferz
31.03.11
✎
09:23
|
(107) весь смысл задачи в не неизменности логики ПУ
|
|||
109
МуМу
31.03.11
✎
09:40
|
(107) Вообще то подход не фантастический а уже реально используемый. Для некоторых задач подходы проще для некоторых сложнее. Описанный вариант с разделением па потоки в разрезе одной номенклатуры тоже можно применять. Проблема в том что тогда нужно было бы реализовывать бизнеслогику.Пришлось бы реализовывать отдельную обработку которая расчитывала партионку по одной номенклатуре в разрезе N документов. А затем можно было бы запускать эти обработки из нужного количества потоков(сессий) 1С полностью параллельно. Данный подход имеет более высокие накладные расходы, однако в специфических случаях его можно и нужно применять.(например отдельно для номенклатуры которая с высокой вероятностью встречается в каждом документе и тем самым существенно снижает уровень параллельности)
Итак, идея концептуально правильная. Формируется пул потоков(сессий 1С), этому пулу потоков необходимо параллельно и правильно распределять документы. С одной стороны должна соблюдаться хронология а с другой все документы должны насколько это возможно проводится параллельно. Вопрос теперь каким образом это реализовать? |
|||
110
Nikulin
31.03.11
✎
09:41
|
Свои 5 копеек.
а почему бы не поделить номенклатурный справочник скажем на 10 групп. далее каждая сессия 1с обрабатывает движения партий по своей номенклотурной групе. вуаля. |
|||
111
МуМу
31.03.11
✎
09:41
|
(108) В общем верно, в (107) действительно пришлось бы реализовывать отдельно бизнес логику, поэтому его не рассматриваем.Хотя вообщем идея правильная.
|
|||
112
МуМу
31.03.11
✎
09:43
|
(110) Вопрос в статистике. Если у вас в компании товар четко разделен в разрезе менеджеров и это легко доказать. То тогда да. Вы можете разделить этот товар в разрезе этих групп, зная что они полностью независимые. В этом случае можно добиться некоторого паралеллизма.(группы скорее всего не одинаковые по объему инф. потоков) Но такое на практике бывает редко.
|
|||
113
МуМу
31.03.11
✎
09:45
|
Если же просто разбить справочник номенклатуры на Н частей и попытаться на основании этих групп разбить документы на независимые группы. Выяснится что этого не получится, кроме тех исключительных случаев когда в табличной части документа находится одна-две номенклатурынх позиции.
|
|||
114
Nikulin
31.03.11
✎
09:46
|
(112) можно предварительно провести обработку и сбалансировать группы например по количеству операций над данным товаром. Чтобы в каждую группу попало одинаковое количество операций. т.е. в одной группе может быть 2 товара а в другой 100.
|
|||
115
МуМу
31.03.11
✎
09:48
|
(114) При среднем количестве строк в документе более 10-и данная задача становится практически нереальной. Не верите? Проведите эксперимент у себя на БД.
|
|||
116
Reaper_1c
31.03.11
✎
09:48
|
Не надо на документах циклиться - надо восстанавливать последовательности по минимальному кванту. Т.е. по связке серии и характеристики и перезаписывать движения документов извне. Вариантов может быть много - составление уравнений, сопоставление всего прихода со всем расходом на периоде и даже банальный алгоритм подокументного расчета но с обязательно с очисткой движений позже ГП по связке, чтобы запросы обращались к записи с актуальным итогом. Собиаем все связки, пилим их на количество камней и раздаем разным процессам для обработки
|
|||
117
Mikeware
31.03.11
✎
09:49
|
(113) Не перепроводить-то нам надо не документы, а партии. Поэтому достаточно первого параллельного прохода по партиям, а затем - по результатам продаж/по документам (в зависимости от того, на что влияет себестоимость партий.)
|
|||
118
МуМу
31.03.11
✎
09:49
|
+(114)То есть выяснится что в большинстве документов находятся одновременно несколько номенклатурных позиций относящихся к нескольким группам что не позволит обрабатывать их паралллено.
|
|||
119
Vladal
31.03.11
✎
09:50
|
А за какой период провести? У нас внедрюки с прошлого февраля последовательность гонят-гонят, никак не выгонят.
|
|||
120
Mikeware
31.03.11
✎
09:51
|
(118) обрабатывать нужно не документ, а движение документа по номенклатуре
|
|||
121
Mikeware
31.03.11
✎
09:52
|
(118) так у тебя таки есть решение, или ты тут чисто идеи собираешь? :-)
|
|||
122
Nikulin
31.03.11
✎
09:53
|
(117) я об этом и говорю. Например.
1. организуем стэк занятых документов. 2. разбиваем товар на квантовые составляющие (например товар + серия). 3. запускаем процессы, присваеваем им группы. 4. при изменении движения помещаем документ в стэк (чтобы никакой другой процесс не менял его. 5. меняем движения по париям в рамках кванта+документа. 6. удаляем документ из стэка. .... ну можно не стэк использовать а блокировки и ожидания. помоему взлетит. и минуем необходимость организовывать управляющий процесс. |
|||
123
МуМу
31.03.11
✎
09:53
|
(116) Пока что рассматриваем варианты с неизменной бизнеслогикой.(т.е. мы ее не выносим в отдельные обработки). В (107),(109) описан вполне работающий вариант, только у него есть несколько недостатков.
|
|||
124
Mikeware
31.03.11
✎
09:56
|
(122) а зачем стэк занятых? у тебя расщепление по номенклатуре, этого достаточно...
|
|||
125
Nikulin
31.03.11
✎
09:59
|
(124) на случай если пересечется момент изменения квант+документ в разных потоках.
|
|||
126
Nikulin
31.03.11
✎
09:59
|
т.е. пересечется документ =)
|
|||
127
Mikeware
31.03.11
✎
10:00
|
(125) измерения у тебя не пересекутся, а на документы пофиг.
|
|||
128
МуМу
31.03.11
✎
10:01
|
(121) У меня есть решение:) Концептуальное описание я потом здесь выложу.
(122) Не понятен пункт 3. Предлагаю пример. Есть последовательность документов. На сколько можно разбить параллельных потоков провдение этих документов? Приходная накладная 1 (Товар1,Товар2,Товар3) Расходная накладная 1 (Товар11,Товар12,Товар13) Расходная накладная 2 (Товар1,Товар22,Товар23) Расходная накладная 3 (Товар21,Товар22,Товар23) Расходная накладная 4 (Товар31,Товар32,Товар33) Расходная накладная 5 (Товар41,Товар32,Товар43) Расходная накладная 6 (Товар51,Товар52,Товар53) |
|||
129
Nikulin
31.03.11
✎
10:01
|
(127) ну вобщем да. если обработка наткнется на блокировку дстаточно предусмотреть ожидание освобождения...
|
|||
130
Nikulin
31.03.11
✎
10:05
|
(128) ну мне лень считать кол-во товаров там
общая формула: товар1 1 измененй товар2 5 товар3 3 хтим разбить на 2 потока получаем что всего 8 зменений . раскидываем пропорционально получаем в 1 потое товар 1 и 3 во втором потоке товар 5 Примерно так. Идеального распределения тут не достич, но на большом массиве данных будет примерно равное распределение |
|||
131
МуМу
31.03.11
✎
10:05
|
Еще один пример. На сколько потоков можно разбить данную последовательность?
Приходная накладная 1 (Пакет,Товар2,Товар3) Расходная накладная 1 (Пакет,Товар12,Товар13) Расходная накладная 2 (Пакет,Товар22,Товар23) Расходная накладная 3 (Пакет,Товар22,Товар23) Расходная накладная 4 (Пакет,Товар32,Товар33) Расходная накладная 5 (Пакет,Товар32,Товар43) Расходная накладная 6 (Пакет,Товар52,Товар53) Я это к тому что уровень параллелизма и соответсвенно ускорения для каждой системы свой. Хотя для приведенного примера есть свои пути обхода. |
|||
132
Nikulin
31.03.11
✎
10:08
|
(131) вобщем конечно да, можно стремиться к идеалу и преодолевать опеделенные трудности. а можно ограничиться определенной достаточностью
|
|||
133
МуМу
31.03.11
✎
10:12
|
(130) Попытка разделить заранее товары на группы а затем на основании этого разделить на потоки заранее обречена на провал. Дело в статистике. Убедиться проще всего написав несложную обработку.Практически гуппы такие возможны но они будут не сбалансированны. Задача их балансировки практически на вашей системе может вообще не иметь решения. Потому как товары из нескольких групп будут присутсвовать в табличной части большинсва документов одновременно.
|
|||
134
Nikulin
31.03.11
✎
10:18
|
(133) Да я и говорю что не идеально но при оценке затрат на разработку для многих случаев достаточное решение.
|
|||
135
trad
31.03.11
✎
10:42
|
(133) а если каждый поток при проведении документа будет рассчитывать только товары своей группы
|
|||
136
trad
31.03.11
✎
10:44
|
а товары распределить по потокам след. образом:
|select Номенклатура |from СтрокиДокументов |group by Номенклатура |order by count(*) - эту выборку посеять в несколько корзин-потоков |
|||
137
cathode
31.03.11
✎
11:14
|
(109) Не совсем так. В решении предлагается не многопоточный расчет себестоимости, гранулой которого является позиция номенклатуры, а синхронизация потоков на входе в документ. Наши потоки бегут сначала свободно. Как только они натыкаются на очередной "свой" документ, т.е. содержащий данную номенклатуру, они останавливаются и ждут все остальные потоки, номенклатура которых входит в этот же документ. При синхронизации документ проводится и выпускает потоки своей номенклатуры в свободное выполнение. Как-то так.
|
|||
138
Alsh
01.04.11
✎
08:09
|
Заглохла ветка... А было интересно...
|
|||
139
MM
02.04.11
✎
17:18
|
МуМу, где методика, пока ветка совсем не потонула?
|
|||
140
МуМу
02.04.11
✎
18:13
|
Дел много было. Выложу в понедельник.
|
|||
141
azernot
03.04.11
✎
12:20
|
Любое разделение на группы номенклатуры и попытка их параллельной обработки по сути всё равно приведёт к методике описанной в мной в (41). Т.е. не стандартное проведение, а пересчёт прямой записью нужных регистров (всех, с условием на неправильность, с условием по группе и т.п.). Поскольку та методика была отвергнута как "немного не та", имхается многоуважаемый МуМу хочет предложить нашему вниманию что-то совсем революционное. Ждём-с!
|
|||
142
ДенисЧ
03.04.11
✎
12:23
|
отправил большой заказ на попкорн. жду.
|
|||
143
Mikeware
03.04.11
✎
12:37
|
(142) ты столько не съешь :-)
Кстати, предложенная в (137) мысль о синхронизации потоков имеет некий смычл. Но в условиях большой связности потоков ожидание будет занимать значительное время, что сведет на нет параллельность. Вчера попробовал рассчитать потоки для параллельного проведения (автокорелляцией товаров) - на первый взгляд, получилась изрядная чушь. |
|||
144
skeptik_m
03.04.11
✎
13:00
|
А производственные операции в базе есть? Если цена партии одного ТМЦ может влиять на цену партии другого ТМЦ, то все попытки считать по отдельным ТМЦ (группам) в отдельных потоках заведомо не годны. Нужно строить полный граф зависимостей (желательно еще в момент проведения документа дописывать информацию в этот граф, который хранить в в виде таблицы БД), но тут уже минимальными изменениями конфигурации (10 строк) не обойдешься.
|
|||
145
Mikeware
03.04.11
✎
13:02
|
(144) теоретичски этот граф (полный) известен до перепроведения - мы ведь сейчас (по условиям задачи) оперируем не партиями, а документами...
|
|||
146
skeptik_m
03.04.11
✎
13:48
|
(145) В том-то и дело что в стандартной конфигурации граф неизвестен до проведения. Нам же для организации работы паралельных потоков проведения нужно понять, какие документы можно проводить независимо друг от друга, а какие должны "подождать", пока не будут проведены определенные предыдущие поскольку они от них зависят. Если заранее построенный граф есть - все просто: есть поток-диспечер, которая обходит граф и "раздает" задания на перепроведение конкретных документов потокам-исполнителям, которые их собственно их перепроводят.
Степень достигаемой параллельности зависит от того "как фишка легла" при построении графа. Теретически возможна и такая ситуация, когда обрабатывать прийдется все строго последовательно, она в общем случае маловероятна (но на каком-нибудь специфическом производстве все может быть). |
|||
147
skeptik_m
03.04.11
✎
14:09
|
Впрочем, если заранее известнол у нас чистое купи-продай, без преобразований одних ТМЦ в другие, в качестве графа зависмостей вполне можно использовать саму последовательность. Имеем список "заблокированных товаров" (ведется процессом-диспечером), когда отдаем документ в "пул паралельного проведения", помещаем туда товары из этого документа. Когда документ будет обработан одним из паралельных процессов-обработчиков - убираем товары из этого списка. В пул на обработку документ можно добавлять только в том случае если ни один товар из него "не заблокирован". В противном случае нужно с эти документом ждать, а пока обрабатывать следующие в последовательности.
|
|||
148
МуМу
03.04.11
✎
14:37
|
(147) Ну концептуально так.
Создается отдельный пул соединений 1С. Координатор задач выбирает из общей последовательности очередной документ. Далее координатор блокировок накладывает блокировки и проверяет нет ли пересечений по блокировкам с проводящимися или стоящими в очереди документами.(в данном примере по табличной части товара)Если блокировки не пересекаются то документ выдается свободной сессии на проведение. Если блокировки пересекаются то тогда документ ставиться в очередь за связанным с ним документом. Если документ зависит от нескольких документов – ставится в очередь за последним по времени. |
|||
149
МуМу
03.04.11
✎
14:40
|
То есть заранее разделить документы на группы, на графы ни к чему хорошему не приведет.
В данном механизме эмулируется своего рода работа пользователей. Ведь они же могут и проводили(если правильно настроены блокировочные механизмы) эти документы параллельно. И от того что они проводили параллельно последовательность не нарушилась(опять таки если блокировки правильно настроены). Изменилась последовательность из за изменений задним числом. |
|||
150
МуМу
03.04.11
✎
14:42
|
Фактически координатор задач(и блокировок) для каждого нового документа который берет из общей последовательности проверяет есть зависимость или нет. Если нет то в свободную сессию на проведение , иначе в определенную сессию в очередь. При завершении проведения документа срабатывает событие по которому можно все очереди перестроить или же не перестраивать а брать из последовательности новый документ и выполнять описанную ранее процедуру.
|
|||
151
МуМу
03.04.11
✎
14:43
|
Для данной технологии нельзя применять ни координатор блокировок от 1С 8. Ни координатор блокировок от MSSQL.
Это происходит по тому, что необходимо проверять все множество товаров на вхождение хотя бы одного элемента не просто для последнего в очереди. Необходимо смотреть пересечение по всему множеству товара документов стоящих в очереди. Приведу на примере блокировок MSSQL. Есть следующие документы: Расходная накладная №1 (Товар1,Товар2,Товар3,Товар4) Расходная накладная №2 (Товар4,Товар5,Товар6,Товар7) Расходная накладная №3 (Товар7) Блокировки пускай накладываются слева на право. В этом примере Расходная накладная №2 станет в очередь за Расходной накладной №1 по пересечению на Товар4. При этом она не наложит ни одной блокировки потому как сразу повиснет на позиции Товар4. При этом Расходная накладная №3 может успеть провестись ранее Расходная накладная №2 что конечно будет не верно, ведь у них есть пересечение по Товар7. А провестись она может ранее потому как по размеру меньше и потому как блокировка на Товар7 не была наложена. Координатор от 1С тоже не подходит потому, как в момент ожидания на блокировке не накладываются блокировки намерением от ожидающей сессии ну и потому что очередь работает по LIFO. |
|||
152
МуМу
03.04.11
✎
14:45
|
Но еще раз повторюсь, логику документов переписывать не нужно.(разве что пару строк кода).
Блокировки известно откуда брать - по товару из табличной части документа. Их можно брать независимо координатором блокировок. |
|||
153
МуМу
03.04.11
✎
14:46
|
Там много еще всяких ньюансов, но это я подробнее выложу в понедельник в статье.
|
|||
154
МуМу
03.04.11
✎
14:48
|
Уровень параллелизма зависящий от данных разумеется влияет на максимальное ускорение. Рассчитать его без реализации координатора задача достаточно непростая. Потому как это зависит как от пересечения множеств товаров, так и от времени проведения документов.
|
|||
155
skeptik_m
03.04.11
✎
14:48
|
Надо помнить, что это будет работать в таком виде только в случае, если нет взаимозвисимости между разными товарами, т.е. производство полностью отсутствует.
|
|||
156
МуМу
03.04.11
✎
14:49
|
При правильной реализации координатор должен отнимать не более 3 процентов ресурсов.
|
|||
157
skeptik_m
03.04.11
✎
14:51
|
Думается мне, что более-менее правильная реализация координатора (то есть не идеальная, но удовлетворительная) особо большой проблемы не представляет.
|
|||
158
МуМу
03.04.11
✎
14:52
|
Ну самый распространенный пример если у вас в каждом втором документе будет "пакет полиэтиленовый" то уровень параллелизма будет очень маленьким. С другой стороны этот товар можно исключить из расчета и блокировок в силу нескольких причин. Товар с большой вероятностью присутствует на складе. Колебания по абсолютному значению маржинальности крайне малы и ими можно принебречь.
|
|||
159
МуМу
03.04.11
✎
14:55
|
(158)+Хотя если финансовый упрется для данного примера есть обходные пути. Только тогда придется отдельно логику реализовывать. Рассчитывать отдельно без пакета по поисанному алгоритму а для пакета делать отдельный пересчет на уровне записей движения только по пакету.
|
|||
160
bazvan
03.04.11
✎
14:56
|
(148) Поготь а разве не так же работают интеловские процесоры (выполняют инструкции) которые Коре2Дуба (Конрой или как прально ядро называется)? Или я чето путаю
|
|||
161
МуМу
03.04.11
✎
14:59
|
(160) Они то рады работать-только кто им даст:) Если мы все действие выполняем в одной сессии то для процессора это четкое указание - выполнять на одном процессоре(ну или менять их но задействован будет только один). Ведь сервер не догадывается о внутренних процессах и особенностях. Он не знает что можно параллелить а чего нельзя. Это и есть особенность параллельных вычислений. Мы должны его написать так что бы сервер мог его параллелить на уровне процессоров.
|
|||
162
МуМу
03.04.11
✎
15:00
|
В понедельник с утра будет выложена статья в которой все это более подробно будет освещено. А затем до 12-го числа будет опубликован большой набор статей посвященный параллельным вычислениям и технологии "гибких блокировок"(по сути это просто бренд).
|
|||
163
bazvan
03.04.11
✎
15:02
|
(161) Я имел ввиду что как она микропрограмма самого чипа так и выполняет инструкции. не относительно приложений а именно внутри чипа.
Чето такое как раз читал в Апгрейде в 2005 что ли году или когда там появился этот Конрой |
|||
164
bazvan
03.04.11
✎
15:06
|
+(163) могу ошибатся. Сори если фигню спорол
|
|||
165
skeptik_m
03.04.11
✎
15:07
|
(158) Ну если лезть в частности, то есть случаи когда можно паралельно проводить документы по одному и тому-же товару. Это ели расчет ведется по орагнизациям и/или складам отдельно.
"Разделителем проведения" может быть не только товар. |
|||
166
МуМу
03.04.11
✎
15:13
|
(165) Разумеется зависит от специфики и от данных. Для партионки если в регистре партионного учета склад не предусмотрен добавлять нельзя. В этом случае блокировки будут по ЮРЛИЦО+ТОВАР. Если есть склад то тогда ЮРЛИЦО+СКЛАД+ТОВАР.Во втором случае конечно уровень параллелизма выше.
|
|||
167
finik
03.04.11
✎
15:53
|
закладка
|
|||
168
ptiz
04.04.11
✎
11:57
|
Где статья?
|
|||
169
МуМу
04.04.11
✎
12:12
|
Статья еще редактируется, поэтому прошу на формат и синтаксис внимания большого не обращать.
http://softpoint.ru/article_id375.htm |
|||
170
МуМу
04.04.11
✎
15:00
|
Завтра выложу другую, посвященную параллельным вычислениям.
|
|||
171
Kraft
04.04.11
✎
15:06
|
кайфовая ветка... Очень нестандартная для нынешней OFF-ной мисты.
|
|||
172
DailyLookingOn Sunset
05.04.11
✎
07:26
|
Просмотрел концептуальный пресс-релиз.
бууээээ |
|||
173
smaharbA
05.04.11
✎
07:46
|
а что вы будете делать с измененными техкартами, торгаши
|
|||
174
disk-2008
05.04.11
✎
07:50
|
Да, в УПП не только торговля.
|
|||
175
shuhard
05.04.11
✎
08:06
|
(169) как и ожидалось,
статья оказалась голимой рекламой Гибких блокировок СофтПоинта |
|||
176
Mikeware
05.04.11
✎
08:43
|
(175) не без этого. Хотя тема навела на некоторые размышления
|
|||
177
МуМу
05.04.11
✎
08:44
|
(173). Принцип абсолютно тот же для производства. Было бы наивно расчитывать на то что будет выложено готовое решение. К тому же как вы уже заметили это всего лишь технология(извините что мы ее называем "гибкие блокировки"). Данная технология требует адаптации для конкретной специфики.
|
|||
178
МуМу
05.04.11
✎
08:47
|
(175) Не нужно принимать все так близко к сердцу;) Чего же вы ожидали? Что я буду пиарить лично себя(как делают многие)? - мне это не нужно. Обещание я свое выполнил. Решение уверяю вас абсолютно рабочее. Любой одинэсник может при желании его реализовать, только на это нужно время и упосртво. Конечно же есть подводные камни, ну а где без них не бывает.
|
|||
179
МуМу
05.04.11
✎
08:49
|
Еще раз повторю, что торговля выбранна лишь как тематика которая проще всего для понимания. Все таки с производством знакома гораздо меньшая аудитория. Для производства принципы абсолютно те же.
|
|||
180
МуМу
05.04.11
✎
08:53
|
Вот еще одна статья , вообще на тему параллельных вычислений.
http://www.softpoint.ru/article_id376.htm Написан большой пул статей, будет выкладываться в среднем две в неделю. Да, там будет скрытый пиар но будет и много чего полезного. В частности технологии которые можно применять независимо и реализовать самостоятельно. |
|||
181
МуМу
05.04.11
✎
08:55
|
Следующая статья будет посвящена ускорения обмена в 1С путем применения тех же параллельных вычислений.
|
|||
182
shuhard
05.04.11
✎
09:01
|
(180)[Да, там будет скрытый пиар ]
что, РАУЗ в УПП, выход КА и УТ 11 прихлопнули сегмент ? |
|||
183
МуМу
05.04.11
✎
09:04
|
(182) Нет, работы хватит на всех:) Просто давно статьи не выкладывали.
|
|||
184
Mikeware
05.04.11
✎
09:05
|
(182) РАУЗ - не панацея.
|
|||
185
smaharbA
05.04.11
✎
09:07
|
всегда хочется на халяву (не меняя кода) и что бы считало правильно
|
|||
186
Jolly Roger
05.04.11
✎
09:51
|
да уж... гора родила мышь...
|
|||
187
Scooter
05.04.11
✎
10:03
|
дочитал до виртуальной биржи, дальше не стал
|
|||
188
AlexNV
05.04.11
✎
10:20
|
Как вариант распаралеливания:
1. Поднимаем еще один сервер и пихаем его в кластер 2. На основном отрубаем регл задания 3. Делаем кол-во процессов нового сервера = кол-во ядер - 1 4. Делаем фоновые задания, кол-во = кол-ву процессов 5. Ими проводим по партиям 6. и не забываем про упр болкировки |
|||
189
МуМу
05.04.11
✎
10:47
|
(186) Я лишь обещал то что обещал. Возможно вы ожидали или поняли задачу как то по другому. Задача реализуема, концепция объяснена.
(187) Тем кто понимает этого достаточно. (пример приведен для большего понимания) (188) Так не взлетит. Последовательность будет нарушена, потому как процессы будут брать документы по очереди а вот проводится они будут не в хронологической последовательности. Либо если выбирать такой вариант необходимо изменять время документов(в некоторых случаях это не верно). |
|||
190
МуМу
05.04.11
✎
10:49
|
(188) Там пример в статье приводится почему координатор блокировок 1С и MSSQL не подходит.
|
|||
191
AlexNV
05.04.11
✎
10:49
|
(189) смотря как определять какую номенклатуру проводить
Вариант: есть таблица, в ней позиции для проведения, процессы выбирают что они будут проводить. Если все процессы завершились корректно, то двигаем ГП. |
|||
192
МуМу
05.04.11
✎
10:53
|
191. Корректность проведения(откаты транзакций по логике или на физическом уровне) это вообще отдельная тема.(это один из подводных камней которые нужно решать) В статье про это не расписано. В данном случае дело не в этом. Вот расскажите каким образом процессы будут выбирать документы из очереди документов? т.е. есть 8-м сессий 1С , каким образом они будут получать порцию сових документов(этом может быть и один документ)? Как вы в этом случае обеспечите ровно такую же хронологию как была изначально?(учитывая что время документов может существенно отличаться а также то что некоторые документы могут висеть на управляемых блокировках)
|
|||
193
MM
12.04.11
✎
16:44
|
Жаль затихла тема.
На чём стоит писать координатор блокировок для распараллеливания? На 1С его получится его написать или нужен настоящий язык программирования? |
|||
194
МуМу
12.04.11
✎
18:07
|
Зависит от объема информацинных потоков. Мы реализовывали на C++. На 1С реализовать можно но накладные расходы будут больше.
|
|||
195
iamnub
14.04.11
✎
00:20
|
(194)
O_O На С++ Называется - горе от ума. Задача решается намного проще - без картинок и умных слов. Работает у меня, работает у MIKEWIRE. А вы, муму, постарайтесь отойти от "надо перепровести все документы!", ей богу - как за программиста - так просто стыдно. |
|||
196
МуМу
14.04.11
✎
21:00
|
(195) В частном случае решается гораздо проще. А в общем почетайте на тему параллельных вычислений - что это такое и зачем нужно. Может так не будет за меня стыдно.
|
|||
197
МуМу
14.04.11
✎
21:02
|
(196) извиняюсь за опечатки-за них действительно стыдно;)
|
|||
198
Fragster
гуру
14.04.11
✎
21:02
|
купить мать, в которую можно воткнуть 64 гига оперативы, и сделать рамдрайв на 60 с базой. перепроводить в файловом режиме
|
|||
199
Fragster
гуру
14.04.11
✎
21:03
|
(198)+ ну это правда если база меньше 60 гб
|
|||
200
_Demos_
14.04.11
✎
21:27
|
(15) конец ветки. выкладывай что там у тебя
|
|||
201
shuhard
14.04.11
✎
21:33
|
(198) сие очевидное решение, предложено ещё в (10)
цена на порядок ниже варианта софтпоинта, ускоряет всё, а не только восстановление последовательности |
|||
202
МуМу
15.04.11
✎
01:43
|
(201) Читаем отзывы на http://softpoint.ru/feedback.php
Внимательно думаем... Предложи им свое решение которое "ускоряет все"(цитата из (201)) и думаю наступит счастье и может быть даже и комунизм. |
|||
203
Злопчинский
15.04.11
✎
04:45
|
> Для данного примера все будет зависеть от того насколько пересекаются между собой номенклатурные составы документов. Если пересечения небольшие, то уровень высокий и ускорение потенциально высокое.
. это значит что оптимальным будет не документ из 100 строк, а сто маленьких отдельненьких документов по 1 строке, которые можно получить "разложив" исходную базу - перепровести - собрать исходную базу.. |
|||
204
Mikeware
15.04.11
✎
08:11
|
(195) это разные решения.
теоретически - у Владимира получаются меньшие вмешательства в конфигурацию. И один проход. (203) теоретически - да. |
|||
205
guevara74
15.04.11
✎
08:29
|
Согласен со всеми, кто сказал слово РАУЗ
|
|||
206
iamnub
15.04.11
✎
11:52
|
(202)
А ты часто "внимательно думаешь"? |
|||
207
iamnub
15.04.11
✎
11:53
|
(204)
Я имел ввиду - у нас с тобой одинаковые решения. Ускорение до x10 без гибких блокировок и C++-сной зайуми. |
|||
208
iamnub
15.04.11
✎
11:54
|
Вообще у меня мечта - вынести вообще восстановление партий в .NET логику. Это первая итерация.
Вторая - заюзать CUDA. )))))) |
|||
209
Scooter
15.04.11
✎
11:59
|
(195)а где ваше решение почитать
ЗЫЖ если в этой ветке было ткните плиз в номер сообщения |
|||
210
iamnub
15.04.11
✎
12:06
|
(37)
|
|||
211
Злопчинский
15.04.11
✎
15:18
|
стопудово ясно, что на перепроведение доков навешано куча всего сопустствующего. если просто выбдрать расчет провести его "в стороне" и вложить обратно в данные - все должно получиться просто офигенно быстро... ?
|
|||
212
МуМу
15.04.11
✎
15:40
|
(207) Решения разные принципиально. У нас например есть отдельно решение "интеллектуальное востановление последовательности"(выборочное востановление), есть решение с кешированием расчета остатков для однопоточного расчета(ускорение линейного расчета- на него больше похоже).
Каждое решение лучше подходит для своего случая. Описанное решение в ветке подходит для большинства случаев. Это подтверждается практикой. В конце концов все решает рынок. Если ты уверен в решении (37) - предлагай его. Получай заслуженную выгоду. (211) Не покатит, есть понятие транзакции. Иногда то что кажется лишним вовсе таким не является. |
|||
213
iamnub
15.04.11
✎
15:49
|
(212)
"Решения разные принципиально" Я не пойму. Ты - Mikeware? "Описанное решение в ветке подходит для большинства случаев." Мое решение - простая внешняя обработка, которая будет работать без каких-либо допиливаний. Плюс (по желанию) - можно отключить механизм расчета себестоимости при самом проведении документа - это себя изжило. Так что проще - внешняя обработка или "гибкие нейросети на С++"? |
|||
214
iamnub
15.04.11
✎
15:52
|
И знаешь, Муму, к твоим "нейросетям" претензий-то как бы и нет.
Просто ты создал тему (как оказалось для пиара) - бросил замануху, народ повелся, начал что-то предлагать - а ты тут с видом "все в г_овне - один я в белом" - вывалил свой ИИ в картинках. Как-то по жлобски. |
|||
215
МуМу
15.04.11
✎
16:21
|
(214) Здесь не пиар, пиар на сньюсах, рбк и т.п.:) Вопрос - если твое решение такое простое и стандартное то почему его до сих пор нет в УПП?
Хочешь пиар? Если оно такое простое и универсальное-реализуй его для УПП. Выложим его бесплатно на мисте и на сайте софтпоинта. Если будет хотя бы 10-ть благодарностей(с примерами использования) - я выплачу тебе 1500 у.е. за потраченное время. Всем будет только хорошо. |
|||
216
МуМу
15.04.11
✎
16:23
|
(214)Уверяю тебя и всех остальных - я не хочу чего либо заработать на посетителях этого сайта. Это принципиально другая аудитория. Мне здесь нужно только лишь обратная связь. За это я готов заплатить сам(как информацией так и деньгами):)
|
|||
217
Ёпрст
15.04.11
✎
16:28
|
(213) т.е во время проведения вообще не толкать партии, а потом фоном твоей обработкой ?
|
|||
218
iamnub
15.04.11
✎
16:45
|
(217)
Да. Во время проведения движения по регистру партий делаются, но с пустой партией и ценой последнего прихода. |
|||
219
iamnub
15.04.11
✎
16:51
|
(215)
А ты в софтпоинте главный? |
|||
220
iamnub
15.04.11
✎
16:56
|
(215)
У меня и взаиморасчеты также считаются - моргнуть не успеешь - еще быстрее. Я разделяю первичные данные и данные рассчитанные на основании первичных данных (расчетные). И я понимаю, что незачем пихать расчет косвенных данных в обработку проведения, а лучше рассчитать их скопом и в фоне. Пока разработчики УПП этого не поймут - в УПП много чего не будет. P.S. Насколько я знаю - что-то подобное в УПП есть (фоновое проведение (???),РАУЗ). Мы замутили свою приладу раньше. ))) |
|||
221
luns
15.04.11
✎
17:00
|
(215) как пример ответа на вопрос "если твое решение такое простое и стандартное то почему его до сих пор нет в УПП?".
отчет "Финансовый расчет" в УПП, часто выдает ошибку 256 таблиц вот ссылка: http://1c-pro.ru/index.php?showtopic=5416 ошибка датирована 2007 годом в 2008 я написал свой отчет, так как 1с не отвечала на вопрос когда пофиксят. вот мой: http://luns-it.ru/2010/02/отчет-финансовый-расчет-для-упп-подс/ сейчас 2011 и ошибка в типовом так и осталась. |
|||
222
iamnub
15.04.11
✎
17:19
|
(221)
Ну, сейчас тебе зашлют "1500 у.е. за потраченное время"!! |
|||
223
МуМу
15.04.11
✎
20:49
|
(222) Меня многие здесь знают. Обманывать не буду. Напиши, выложи методику+обработку. Выложим бесплатно. Будет больше 10-и положительных отзывов - отправлю(им) тебе 1500 у.е. (любыми вариантами по желанию)
|
|||
224
Snovy
15.04.11
✎
20:56
|
В свое время в институте (я заканчивал по специальности оборудование сварочного производства) меня учили, что самое лучшее сварное соединение - это отсутствие сварного соединения. Так и здесь - самое лучшее решение по восстановлению последовательности - это отсутствие необходимости восстанавливать последовательность. А все остальное - ересь...
|
|||
225
МуМу
15.04.11
✎
22:50
|
А еще ересь - бюрократия,взятки и т.п. Реальная жизнь - штука многогранная.
|
|||
226
Snovy
15.04.11
✎
22:59
|
(225) Еще раз - нормальная учетная система не подразумевает шаманства с восстановлением последовательностей чего бы там ни было - либо все это автоматизировано другими способами, либо регламентировано (жестоко, жестко, мягко) и т.д. Т.е. на поверхности лежит другая архитектура учетной системы, только обычно глаз замылен чем то, называемым "типовым". Мы живем в трехмерном мире, а проблемы учета рещаем в стиле 2D - вместо того, что бы перепрыгнуть проблему, мы ее обходим...
ПС. Термины навеяны недавним окном ИТРП и их нравоучениями (с коими я не совсем согласен), но лично я давно партионный учет (НКС, МПЗ, расчеты с контрагентами, ЦБ) решил полным отказом от каких-либо последовательностей, а перепроведение документов - это вообще грех, за который во времена инквизиции сжигали на кострах :) |
|||
227
МуМу
15.04.11
✎
23:02
|
Мы живем не в идеальном мире. У многих эта проблема актуальна. Перевоспитать всех слищком сложная задача.
|
|||
228
Snovy
15.04.11
✎
23:15
|
(227) Вообще решение лежит на поверхности, причем с объединением (использую термины 1С) ордерного склада, партионки в классическом стиле и партионки в стиле 1С, финансового учета и оперативного учета - это использование учетных цен и счетов 15 и 16. 1С дернулась в этом направлении и заглохла на 1/10 пути. А ведь данная методология (даже не побоюсь этого слова - технология) абсолютно легальна с точки зрения всех видов регламентированного учета (РСБУ, НК, МСФО) и поддерживает любые прихоти управленческого учета. Применение методики учета в БУ счетов 15 и 16 разводит реальный складской учет и финансовый учет на две составляющие (приход/использование и расчеты с поставщиком/оценка себестоимости).
|
|||
229
МегаБум
15.04.11
✎
23:16
|
(0) зачем тебе последовательность?
А где пит? |
|||
230
Snovy
15.04.11
✎
23:19
|
(229) Так вот пита и нет... а то бы сейчас!!! Кстати, кто-нибудь что-нибудь о нем знает (о Пите)?
|
|||
231
azernot
16.04.11
✎
00:06
|
Как только вы захотите анализировать реальную валовую прибыль по сделкам, вам понадобится последовательность (партии, средняя и т.п.). Все разговоры про "волшебный" РАУЗ или про учётные цены только в первом приближении кажутся легким решением, на самом деле не отвечающее требованиям оперативности и точности. Решение не редактировать документы задним числом тоже имеет кучу минусов. В итоге по-любому встанет проблема востановления последовательности и, соответсвенно, её оптимизации. Самым лучшим решением будет в любом случае восстановление только реально нарушенной последовательности (а не всей подряд как это делает типовое решение). В случае если у вас есть механизм восстановления последовательности точечно (по конкретной номенклатуре/организации/складу и т.п.), распараллеливание процессов уже не становится некой сверхзадачей (хотя бузусловно ускорит процесс).
Если же последовательность нарушается глобально, по всем измерениям и всегда, как это требует автор, то тут уже стоит задуматься об организации бизнесс-процессов как таковых, а возможно и отказа от партий в принципе. |
|||
232
azernot
16.04.11
✎
00:19
|
+(231) Мудрёно получилось... Основная мысль в том, что всё-таки не стоит ставить задачу параллельной обработки данных во главу угла, в первую очередь стоит научиться универсально обрабатывать последовательность точечно, только там где это реально требуется. А там уже и параллельность организовать по предлагаемой автором методике гораздо проще (т.к. минимальная единица уже не документ, а конкретный набор записей). Ну и необходимость последовательности для меня очевидный факт, поскольку никакие другие методики не отвечают моим требованиям к оперативному и точному учёту.
|
|||
233
D_o_t_e_r
16.04.11
✎
00:27
|
(232) - собственно что в этом то сложного? У меня на работе холдинг в 9 конторок упрощенки, упп, месяц проводится монопольно за 20 часов. При исправлении данных месяцом ранее (стабильно бывает и не раз в месяц) - последствия понятны... Так вот, всего то пару часов допиливал групповую обработку справочников и документов, и там сделал то по сабжу всего ничего - отбор по вохождению "Организация" и "номенклатура из списка в документе" + проведение с паузами - чтобы если край как надо днем восстановить - работе не мешать. Как бы вот и вс1/ зачем огород городить в этом случае?
|
|||
234
D_o_t_e_r
16.04.11
✎
00:29
|
А сабж тоже бред собственно. Если такое "надо" каждый день - так это что то в "датском королевстве" не аллё.
|
|||
235
МегаБум
16.04.11
✎
01:23
|
средневзвешенную уже предлагали?
|
|||
236
Злопчинский
16.04.11
✎
05:18
|
> Не покатит, есть понятие транзакции. Иногда то что кажется лишним вовсе таким не является.
. - непонятно! сторонней обработкой решаем логически законченный блок/алгоритм востановления/расчета псоледовательности... при чем здесь транзакции? или речь идет о фоновом восстановлении последовательности при работающих юзверях..? . вообщем особо непонятно зачем восстанавливать последовательность... получается что последовательность восстанавливать нужно только для правильного исчисления себестоимости/партионки... - ну и нахрена? была кривая партионка, по ней принимались решения, выполнялись.. теперь хреняк! выясняется, что "партионка" кривая - надо бы подкорректировать... - ну и фигли - корректируем в текущем моменте! нахрена ее сзади корректировать...??? отсается вопрос - как узнать, как именно корректировать в ТА...? какие данные - ПРАВИЛЬНЫЕ..??? . вопрос идет о чем? о том как быстро восстановить последовательность...? может все-таки более продуктивно - не давать ее нарушать..? по крайней мере нарушение количественной последовательности - отлвливается практически мгновенно (спасибо питу, селенат и иже)... нарушение суммовых последовательностей последовательностей - см. выше - нака их восстанавливать..? кидаем добавку (на сумму исправления) в ТА - и все...???? |
|||
237
МуМу
16.04.11
✎
15:15
|
Я смотрю на этом форуме сплошные идеалисты. У нас есть отдельное направление которое занимается консалтингом. Что такое сторнирование и т.п. я прекрасно представляю. Я понимаю что важно для управленческого учета не допускать коррекции задним числом. Но жизнь такова что все не идеально. Есть статистика в виде обращений клиентов. Одна из проблем - вышеозвученна.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |