Дано: Есть УПП с партионкой. Нужно восстановить последовательность документов(путем перепроведения) с партионным учетом с целью перерасчета правильной себестоимости.

Предположим серверные настройки оптимальные, сервер очень мощный.  Линейное ускорение  проведения документов, за счет оптимизации запросов,  возможно не более чем на 15%.

Стоит цель ускорить время проведения в 3-5 раз. Каким образом можно это сделать и от чего это зависит?

(0)[сервер очень мощный.]
дисковая подсистема очень быстрая ?

путем апгрейда железа

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

(2) Не верно. При доп. вложении равной стоимость существующего сервера удастся ускорить только на 15-20 процентов.

в данном конкретном случае рулит скорость одного ядра, а не количество процессоров

(4) а теперь моя практика: вместо стоечного сервака HP куплен десктоп за 40% цены сервера. последовательность на нем восстанавливается в три раза быстрее.

Данный вопрос родился в контексте последней дискуссии с коллегами. Выяснилось что подавляющее большинство ничего не знает на тему параллельных вычислений, об архитектуре современных серверов.
(5) Это верно.

(6) не, даже не 40%. сервер стоил 300 где-то, десктоп 50.

фоновые задания + отложенный расчет итогов.

+ изменение алгоритмов (выборочное перепроведение, запись движений отклонений ...)

(3)[очень быстрая дисковая подсистема]
RAM диски

(6) Для каждой конкретной задачи хорошо свое железо. В любом случае для данной задачи будет максимальное ускорение 50 % , либо это будет означать что предыдущий сервак был совсем стареньким. Для современных серваков замена как я уже писал раньше будет 15% и расти потом нелинейно в соответсвии к затратам.
Напомню , я говорю о ускорении в 3-5 раз.

(7)[Данный вопрос родился в контексте последней дискуссии с коллегами. Выяснилось что подавляющее большинство ничего не знает на тему параллельных вычислений, об архитектуре современных серверов. ]
ужо.с
срочно всех на семинары http://softpoint.ru/

(9) Данную задачу рассматриваем как регламентную которую нужно выполнить в конце месяца. То есть надо перепровести все документы.

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

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

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

(12) Этого я не говорил и рекламы семинара в этой ветке не будет.  Мне интересно предложит ли кто нибудь более менее точную концепцию реализации. Задача достаточно актуальная. В конце ветки я обязательно отвечу на этот вопрос.

(15)[В конце ветки я обязательно отвечу на этот вопрос.]
ждём-с

(14).
Алгоритм проведения менять нельзя. Прямые запросы использовать можно(даст эффект минимальный 10-15%) Расчеты в отдельной копии можно делать.Только что это даст? Важна же хронология документов, один документ влияет на другой.(на себестоимость)

(17) Ну почему расчет в файловой версии плюс выгрузка/загрузка в скуль иногда быстрее на порядок, чем просто расчет на скуле

(18) базы которые влезают в 1cd я думаю МуМу не интересуют...

(19) А зачем пихать всю базу, если мы проводим 1 месяц. Конечно если даже и месяц туда не влазит...

(20) партии и взаиморасчеты ты умеешь урезать до месяца  ?

(21) Да, ввод начальных остатков. Зачем тебе движения за старые месяца, если по сути тебе нужны только итоги?

(22) блеск, полный отказ от ФИФО в партионном учете

МуМу не думаю, что кроме тебя кто-то активно здесь занимался этим вопросом, поэтому рассказывай очень интересно послушать

отключить итоги, весь пересчет итогов делать в своих временных табличках во время перепроведения.
Разве что.

(23) Э а каким боком тут ФИФО? По твоему когда программа перепроводит документы за март она берет движения за прошлый год? Или все таки остатки на документ?

+25 т.е сделать аналог с семёрошным толканием ТА вперёд.

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

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

(0)
Автор - ламо.

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

(28) ну да..
Вот еслиб ешще и период хранения останков был бы короче, 5 дней к примеру, а не месяц - еще быстрее было бы проведение, в разы.

зачетный вброс

(29) Я бы не стал так говорить на автора, просто ему интересно послушать мнения других, но поверь знаний его в этом вопросе (особенно по 7-ке) поболее чем у многих вместе взятых

(0)
Пока ты там концепции изобретаешь - у людей уже все давно работает. Ускорение - 12Х.

(26) Возврат с указанным документом партии никогда не проводил? Там-то как раз нужны движения изначального документа...

(33) компетенция ТС сомнений не вызывает,
формат топик прикольный,
ответ знаю, но не скажу.

в итоге флюд про сферического коня в вакууме

v8: Проведение расходного документа по партиям за 0.045 секунд?
В 21-ом посте все расписано.

(38)
Можно еще быстрее - ХРАНИМКОЙ на СЕРВЕРЕ!!

(15)
"Мне интересно предложит ли кто нибудь более менее точную концепцию реализации."

Приз-то будет?

не хватает условия, что все это нужно делать на типовой конфе.

Как показывает практика 80% необходимости восстановления последовательности связано с изменением сумм (без изменения собсвтенно количества и момента времени документов), соответсвенно в большинстве случаев достаточно пересчитать суммы, без полного перепроведения документов.

Убыстрял восстановление последовательности методом отдельного пересчёта запросами и прямой записи.
По сути метода сводилось к следующему:
1. Проверяем корректность распределения по партиям (упрощённо - в случае ФИФО если есть остаток по более ренней парти с учётом всех допустимых статусов, отборов и т.п. - значит распределение некорректно и документ нуждается в перепроведении). На этом этапе полностью забиваем на себестоимость, нас интересует только корректность списания количества по партиям.
Повторяем п.1 до тех пор пока в интересуемом периоде все партии корректно не распределятся.
2. Восстанавливаем прямой записью суммы партий и связанных движений.

Прирост скорости колоссальный. Во-первых я в п.1 перепровожу только документы с реально некорректными партиями, во-вторых в п.2 я восстанавливаю суммы реально только там, где это необходимо. В идеале бы конечно ещё и в п.1 менять партии без перепровдения, но у меня как-то руки не дошли.

(41) Это не панацея, поскольку не дает гарантии, что будут исправлены оставшиеся 20%, связанные с переносом докумнтов со пересписанием списанных партий, вводом новых партий без их списания по методике. Это лиш метод исправления заранее известной ошибки -  операция над больным - конечное решение, а не полное лечение.
Убыстрение восстановления партий должно быть связано только с восстановлением партий, но к сожалению движения по другим регистрам по методике 1С завязано на партиях. Развязать их,  вытащить из одной транзакции - вот имхо путь к решению проблемы.

(42) Ты не прав, 20% - лечится пунктом 1, когда восстанавливается корректность списания по партиям (в т.ч. и наличие отрицательного остатка после регистратора по партиям - симптом некорректности).
Двжиения других регистров (я их называю связанные движения) я также корректирую в п.2.
Развязать их нельзя, информация в связанных регистрах как раз и берётся из партий. Развязать их - значит организовать некие регламентные процедуры (типа сформировать проводки только в конце месяца)..

Отходил пообедать. Сейчас буду отвечать.

(38)В контексте этого подхода не хочу спорить потому как долго разбираться чего там скоряется в 12-ть раз.  Предположим для простоты что запросы по партионке реализованы хранимкой на сервере.  Как в этом случае можно реализовать данную задачу?

(45)
Я твоего поста вообще не понял.

Ты просил "более менее точную концепцию реализации."

Я показал решение - работает сейчас.

Ты говоришь - что тебе долго разбираться - чего там ускоряется.

Вводишь какие-то новые условия, запросы, хранимки...

Лучше я тебе вопрос задам - когда коту делать нечего - он чем занимается?

(41)Это немного другой подход. Для реализации минимальной задержки актуальной себестоимости применялся подход в котором логировались изменения задним числом. Затем пересчитывались только те документы и только те движения документов на которые они влияли. В данной концепции будем считать что поменялось все и надо все перепровести.

отказаться от ПУ в пользу РАУЗ.

переходите на рауз

(46) Ладно , почитаю.  
Условие основное следующее. Изменение кода не допускается, точнее допускается добавить 10 строк кода в существующий код. Это важно с точки зрения того что данное решение не должно привести к изменению логики существующей системы.

(50)+Под кодом я подразумевал код модуля проведения документов.

(49) моим уточненная себестоимость бывает нужна каждый день. а иногда и не по разу...

(0) Подходит ли вариант с распределенной базой? Полный обмен.  В соседней базе никому не мешая, в монопольном режиме перепроводится всё, что нужно, потом обменом попадает в рабочую базу.

Именно под эту отдельную базу можно подобрать соответствующее железо.
А для  рабочей базы, где работают много пользователей подобрано другое железо под соответствующие задачи...

(53) Данное решение имеет право на существование но имеет ряд минусов.
В текущей базе нужно закрывать определенный период.  Потому как только с даты предыдущего закрытого периода по дату текущего закрытого периода имеет смысл перепроводить документы.(иначе любое изменение задним числом приводит к возникновению подобной задачи повторно)  Затем необходимо  реализовывать механизмы обмена.  С другой стороны если есть возможность период закрывать, тогда лучше ночью делать пересчет по дату закрытого периода и не парится с обменами.

(54) это, а сколько сейчас по времени занимает примерно проведение одного документа в "заднем" числе ?
ну, строк на 100 в табличной части..
?
Так, для справки.

(55) Смотря насколько оно "заднее"...

(52) хз. да каких целей может понадобится себестоимость текущего дня?

Дурью маетесь, господа.

(57) профит глядеть..
у нас после проведения накладной смотрят профит в самом документе..
от этого прикидывают скидку/наценку..
Профитная система оплаты, понимашь.

(57) Не текущего - вчерашнего, позавчерашнего. Но в течение  дня могут править и "месяц взад", и даже глубже...
"оказалось, что вот это нам привезли дороже, это- дешевле, а вот это как бонус. а насчет этого согласовали с клиентом скидку (наценку за доставку на север)... "

(59) бывает и прикольней,
у меня каждую ночь в УПП документы перепроводятся за открытый период

(59) нет, этого нет. более того, менеджеры не с реализациями работают. И реализации массово появляются начиная с 19 часов..

(59) мои профит видят уже в сделки, а руководство вообще периодически хочет видеть предварительный анализ продаж, который работает не по реализациям, а по заявкам, т.е. по резервам :(

ну так, у кого сколько проводится реализация ?

Закинул демку упп в скуль 2008, на серваке 24 ядра, 24 гига оперативы, всё на 10 рейде
Время проведения одного документа в среднем 18 секунд.
Это нормально ?

(53) нет не подходит. Я тут давеча за два года перепровел почку бухии, так потом 2 дня ждал когда она в центр загрузиться, так и не дождался. Пришлось убить регистрацию. Такие большие объемы потом хрен куда загрузишь, так что теперь стараюсь больше одного квартала за раз не перепроводить

(64) типовая - 100 позиций РТиУ, 4 месяца назад, всего четыре месяца в базе - 50 секунд. После моих шаловливых - та же накладная 7-9 секунд...

(66) да уж.. переходите на снеговик - там всё реализовано ?
:))

(63) это реализовано - ну профит по резервам?

Вот если бы типовой интерактивный обмен мог грузить порциями, тогда да. А так ...

p.s. хотя вроде бы фоновый так может, но типовой фоновый только с УТ

(67) угу. Расчёт себестоимости за месяц (30 000 ОПзС) - 17 часов. После шаловливых - около 8. Тех же часов...

(0) Не томи! Рассказывай!

(68) в заявке да (тупо скопировл из механизма проведения механизм расчета партий, т.е. делаю "виртуально проведение")

(65) В снеговике?

(73) Угу в типовом непереписанном снеговике, в БП 2.0

(72) а обычные рту, потом используют списывают те партии из резерва?

(73) Там просто все это делается в одной транзакции, плюс в УРИБ обмене если изменились движения, то программа регистрирует эти изменения для ВСЕХ почек.

В принципе, обмен можно и переписать слегка....

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

(78) а списание автоматическое ГТД в РТУ у вас есть?

(79) ГТД в партиях сидит, при проведении, они фиксируються в ТЧ и потом не меняються

(80) А как же вы счет-фактуру с непроведенного рту печатаете? Проводок же не будет по ГТД?

Подсказка. Все это сводится к задаче параллельных вычислений.

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

(82) Распараллелить вычисления по разным товарам?

(81) Мы счет-фактуру по заявки не печатаем

(84) ну в принципе, почему бы и нет. а после - пересчет по взаиморасчетам. Только будет ли быстрее?

(82) Была идея засунуть в последовательность измерение товар, и перепроводить конкретно по кривому товару, а не все документы

(87) в условии задачи - перепроводить всё.

(88) В условиях ускорения, а не полное перепровдение.

Провести нужно все.
(84) Ну если уж совсем вообщем - да. Нужно заставить работать все процессора сервера.Заставить проводить параллельно максимальное количество документов в единицу времени и при этом не нарушать последовательность.
Вопрос теперь, как концептуально это реализовать?

(89) Если изменились несколько позиций задним числом то действительно существуют другие более эффективные способы. В данном случае это не тот вариант. Считаем что поменялось все.

Закладка

(91) ты спрашиваешь готовое решение или своё хочешь предложить ?

(93)Мне интересно, есть ли вообще понимание как подобное может быть возможным.(эта ветка мне интересна для анализа статей, которые я сейчас дописываю) Концепцию я здесь в любом случае расскажу чуть позже.

(94) дык это будет просто концепция, или готовое рабочее решение ?

+95 просто сейчас, упп из "коробки" - это просто мусор.

(94)
окончание статьи я могу угадать

" У автора имеется готовое решение...."

(95)Это будет описание технологии. Никто не мешает ее реализовать самому. Но как показывает практика(древние статьи на тему производительности 7-ки) от описания до практической реализации очень далеко. Большитнство просто не хотят заморачиваться(как правило если с наскока не получилось то дальше лень) над этим, впрочем в этом есть тоже свои плюсы.

(97) сочинение "если б я стал президентом..." ты тоже писал?

(98) ждёмс.

(90)[.Заставить проводить параллельно максимальное количество документов в единицу времени и при этом не нарушать последовательность.]

примитивный фокус с 10 Организациями в одной базе и
параллельным запуском в 10 1с.exe восстановления по одной организации

мистой зачтен не будет

(101) Обижаете, подобная задача недостойна обсуждения:)

(102) и я о том же,
такой примитив мисту не интересует

(6) извиняюсь за глупый вопрос, но что такое "стоечный десктоп"?

Очень интересная тема.

есть идеи но настолько невероятные что их нужно пробовать.

общая концепция примерно такая
n -процессов подготовительные
1 -замыкающий, который и выстраивает последовательность.

Задача подготовительных процессов сохранить откомпилированные запросы и обновить статистику.

Это единственный вариант последовательного!!! (увы с последовательностью ничего не придумаешь) проведения без оптимизации запросов и изменения логики

(106) Если мыслить в рамках одного потока исполнения, действительно кажется, что с последовательностью ничего не поделаешь, так как она кажется набором отметок на временной оси. Но это всегл лишь умственная проекция - удаление одного из измерений. Если у нас, к примеру, есть набор документов, в которых списывается всегда один товар А, а есть набор документов, содержащих только товар Б, то при параллельном проведении этих двух линеек документов важен будет только их порядок друг относительно друга, но не проекция на глобальную временную ось. И в результате такого проведения мы получим то же самое, что и при стандартном подходе "в очередь, сукины деты, в очередь". Таким образом, задача ускорения проведения документов заключается в построении графа зависимостей вхождения номенклатурных позиций в документы от их дат и обработке этого параллельными вычислениями.
Как "наивную", но теоретически верную реализацию, можно предложить следующий подход: на каждую номенклатурную позицию, которая списывалась в данном периоде, создаем один поток исполнения; на всех документах, содержащих более одной строки, на входе ставим джойн всех потоков номенклатур, входящих в этот документ, на выходе - соответственно сплит. На сервере как-то организуем пул исполнителей всех этих потоков с количеством исполнителей, достаточным для загрузки всех процессоров сервера. В результате имеем профит в виде в среднем процессор-кратного ускорения проведения документов и это еще до оптимизации кода проведения.
Я не спец в параллельном программировании, идея мне самому кажется слегка бредовой, просто в этой ветке большинство предлагают стереотипные подходы, а я решил предложить фантастический.

(107) весь смысл задачи в не неизменности логики ПУ

(107) Вообще то подход не фантастический а уже реально используемый. Для некоторых задач подходы проще для некоторых сложнее. Описанный вариант с разделением па потоки в разрезе одной номенклатуры тоже можно применять. Проблема в том что тогда нужно было бы реализовывать бизнеслогику.Пришлось бы реализовывать отдельную обработку которая расчитывала партионку по одной номенклатуре в разрезе N документов. А затем можно было бы запускать эти обработки из нужного количества потоков(сессий) 1С полностью параллельно.  Данный подход имеет более высокие накладные расходы, однако в специфических случаях его можно и нужно применять.(например отдельно для номенклатуры которая с высокой вероятностью встречается в каждом документе и тем самым существенно снижает уровень параллельности)
Итак, идея концептуально правильная. Формируется пул потоков(сессий 1С), этому пулу потоков необходимо параллельно и правильно распределять документы. С одной стороны должна соблюдаться хронология а с другой все документы должны насколько это возможно проводится параллельно.
Вопрос теперь каким образом это реализовать?

Свои 5 копеек.
а почему бы не поделить номенклатурный справочник скажем на 10 групп. далее каждая сессия 1с обрабатывает движения партий по своей номенклотурной групе.
вуаля.

(108) В общем верно, в (107) действительно пришлось бы реализовывать отдельно бизнес логику, поэтому его не рассматриваем.Хотя вообщем идея правильная.

(110) Вопрос в статистике. Если у вас в компании товар четко разделен в разрезе менеджеров и это легко доказать. То тогда да. Вы можете разделить этот товар в разрезе этих групп, зная что они полностью независимые. В этом случае можно добиться некоторого паралеллизма.(группы скорее всего не одинаковые по объему инф. потоков) Но такое на практике бывает редко.

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

(112) можно предварительно провести обработку и сбалансировать группы например по количеству операций над данным товаром. Чтобы в каждую группу попало одинаковое количество операций. т.е. в одной группе может быть 2 товара а в другой 100.

(114) При среднем количестве строк в документе более 10-и данная задача становится практически нереальной. Не верите? Проведите эксперимент у себя на БД.

Не надо на документах циклиться - надо восстанавливать последовательности по минимальному кванту. Т.е. по связке серии и характеристики и перезаписывать движения документов извне. Вариантов может быть много - составление уравнений, сопоставление всего прихода со всем расходом на периоде и даже банальный алгоритм подокументного расчета но с обязательно с очисткой движений позже ГП по связке, чтобы запросы обращались к записи с актуальным итогом. Собиаем все связки, пилим их на количество камней и раздаем разным процессам для обработки

(113) Не перепроводить-то нам надо не документы, а партии. Поэтому достаточно первого параллельного прохода по партиям, а затем - по результатам продаж/по документам (в зависимости от того, на что влияет себестоимость партий.)

+(114)То есть выяснится что в большинстве документов находятся одновременно несколько номенклатурных позиций относящихся к нескольким группам что не позволит обрабатывать их паралллено.

А за какой период провести? У нас внедрюки с прошлого февраля последовательность гонят-гонят, никак не выгонят.

(118) обрабатывать нужно не документ, а движение документа по номенклатуре

(118) так у тебя таки есть решение, или ты тут чисто идеи собираешь? :-)

(117) я об этом и говорю. Например.
1. организуем стэк занятых документов.
2. разбиваем товар на квантовые составляющие (например товар + серия).
3. запускаем процессы, присваеваем им группы.
4. при изменении движения помещаем документ в стэк (чтобы никакой другой процесс не менял его.
5. меняем движения по париям в рамках кванта+документа.
6. удаляем документ из стэка.
.... ну можно не стэк использовать а блокировки и ожидания.
помоему взлетит. и минуем необходимость организовывать управляющий процесс.

(116) Пока что рассматриваем варианты с неизменной бизнеслогикой.(т.е. мы ее не выносим в отдельные обработки). В (107),(109) описан вполне работающий вариант, только у него есть несколько недостатков.

(122) а зачем стэк занятых? у тебя расщепление по номенклатуре, этого достаточно...

(124) на случай если пересечется момент изменения квант+документ в разных потоках.

т.е. пересечется документ =)

(125) измерения у тебя не пересекутся, а на документы пофиг.

(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)

(127) ну вобщем да. если обработка наткнется на блокировку дстаточно предусмотреть ожидание освобождения...

(128) ну мне лень считать кол-во товаров там
общая формула:
товар1 1 измененй
товар2 5
товар3 3
хтим разбить на 2 потока
получаем что всего 8 зменений . раскидываем пропорционально получаем
в 1 потое товар 1 и 3
во втором потоке товар 5
Примерно так.
Идеального распределения тут не достич, но на большом массиве данных будет примерно равное распределение

Еще один пример. На сколько потоков можно разбить данную последовательность?
Приходная накладная 1 (Пакет,Товар2,Товар3)
Расходная накладная 1 (Пакет,Товар12,Товар13)
Расходная накладная 2 (Пакет,Товар22,Товар23)
Расходная накладная 3 (Пакет,Товар22,Товар23)
Расходная накладная 4 (Пакет,Товар32,Товар33)
Расходная накладная 5 (Пакет,Товар32,Товар43)
Расходная накладная 6 (Пакет,Товар52,Товар53)

Я это к тому что уровень параллелизма и соответсвенно ускорения для каждой системы свой. Хотя для приведенного примера есть свои пути обхода.

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

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

(133) Да я и говорю что не идеально но при оценке затрат на разработку для многих случаев достаточное решение.

(133) а если каждый поток при проведении документа будет рассчитывать только товары своей группы

а товары распределить по потокам след. образом:

|select Номенклатура
|from СтрокиДокументов
|group by Номенклатура
|order by count(*)

- эту выборку посеять в несколько корзин-потоков

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

Заглохла ветка... А было интересно...

МуМу, где методика, пока ветка совсем не потонула?

Дел много было. Выложу в понедельник.

Любое разделение на группы номенклатуры и попытка их параллельной обработки по сути всё равно приведёт к методике описанной в мной в (41). Т.е. не стандартное проведение, а пересчёт прямой записью нужных регистров (всех, с условием на неправильность, с условием по группе и т.п.). Поскольку та методика была отвергнута как "немного не та", имхается многоуважаемый МуМу хочет предложить нашему вниманию что-то совсем революционное. Ждём-с!

отправил большой заказ на попкорн. жду.

(142) ты столько не съешь :-)
Кстати, предложенная в (137) мысль о синхронизации потоков имеет некий смычл. Но в условиях большой связности потоков ожидание будет занимать значительное время, что сведет на нет параллельность. Вчера попробовал рассчитать потоки для параллельного проведения (автокорелляцией товаров) - на первый взгляд, получилась изрядная чушь.

А производственные операции в базе есть? Если цена партии одного ТМЦ может влиять на цену партии другого ТМЦ, то все попытки считать по отдельным ТМЦ (группам) в отдельных потоках заведомо не годны. Нужно строить полный граф зависимостей (желательно еще в момент проведения документа дописывать информацию в этот граф, который хранить в в виде таблицы БД), но тут уже минимальными изменениями конфигурации (10 строк) не обойдешься.

(144) теоретичски этот граф (полный) известен до перепроведения - мы ведь сейчас (по условиям задачи) оперируем не партиями, а документами...

(145) В том-то и дело что в стандартной конфигурации граф неизвестен до проведения. Нам же для организации работы паралельных потоков проведения нужно понять, какие документы можно проводить независимо друг от друга, а какие должны "подождать", пока не будут проведены определенные предыдущие поскольку они от них зависят. Если заранее построенный граф есть - все просто: есть поток-диспечер, которая обходит граф и "раздает" задания на перепроведение конкретных документов потокам-исполнителям, которые их собственно их перепроводят.
Степень достигаемой параллельности зависит от того "как фишка легла" при построении графа. Теретически возможна и такая ситуация, когда обрабатывать прийдется все строго последовательно, она в общем случае маловероятна (но на каком-нибудь специфическом производстве все может быть).

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

(147) Ну концептуально так.
Создается отдельный пул соединений 1С.  Координатор задач выбирает из общей последовательности очередной документ. Далее координатор блокировок накладывает блокировки и  проверяет нет ли пересечений по блокировкам с проводящимися или стоящими в очереди документами.(в данном примере по табличной части товара)Если блокировки не пересекаются  то документ выдается свободной сессии на проведение. Если блокировки пересекаются то тогда документ ставиться в очередь  за связанным с ним документом. Если документ зависит от нескольких документов – ставится в очередь за последним по времени.

То есть заранее разделить документы на группы, на графы ни к чему хорошему не приведет.
В данном механизме эмулируется своего рода работа пользователей. Ведь они же могут и проводили(если правильно настроены блокировочные механизмы) эти документы параллельно. И от того что они проводили параллельно последовательность не нарушилась(опять таки если блокировки правильно настроены). Изменилась последовательность из за изменений задним числом.

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

Для данной технологии нельзя применять ни координатор блокировок от 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.

Но еще раз повторюсь, логику документов переписывать не нужно.(разве что пару строк кода).
Блокировки известно откуда брать - по товару из  табличной части документа. Их можно брать независимо координатором блокировок.

Там много еще всяких ньюансов, но это я подробнее выложу в понедельник в статье.

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

Надо помнить, что это будет работать в таком виде только в случае, если нет взаимозвисимости между разными товарами, т.е. производство полностью отсутствует.

При правильной реализации координатор должен отнимать не более 3 процентов ресурсов.

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

Ну самый распространенный пример если у вас в каждом втором документе будет "пакет полиэтиленовый" то уровень параллелизма будет очень маленьким. С другой стороны этот товар можно исключить из расчета и блокировок в силу нескольких причин. Товар с большой вероятностью присутствует на складе. Колебания по абсолютному значению маржинальности крайне малы и ими можно принебречь.

(158)+Хотя если финансовый упрется для данного примера есть обходные пути.  Только тогда придется отдельно логику реализовывать. Рассчитывать отдельно без пакета по поисанному алгоритму а для пакета делать отдельный пересчет на уровне записей движения только по пакету.

(148) Поготь а разве не так же работают интеловские процесоры (выполняют инструкции) которые Коре2Дуба (Конрой или как прально ядро называется)? Или я чето путаю

(160) Они то рады работать-только кто им даст:) Если мы все действие выполняем в одной сессии то для процессора это четкое указание - выполнять на одном процессоре(ну или менять их но задействован будет только один).  Ведь сервер не догадывается о внутренних процессах и особенностях. Он не знает что можно параллелить а чего нельзя. Это и есть особенность параллельных вычислений. Мы должны его написать так что бы сервер мог его параллелить на уровне процессоров.

В понедельник с утра будет выложена статья в которой все это более подробно будет освещено. А затем до 12-го числа будет опубликован большой набор статей посвященный параллельным вычислениям и технологии "гибких блокировок"(по сути это просто бренд).

(161) Я имел ввиду что как она микропрограмма самого чипа так и выполняет инструкции. не относительно приложений а именно внутри чипа.
Чето такое как раз читал в Апгрейде в 2005 что ли году или когда там появился этот Конрой

+(163) могу ошибатся. Сори если фигню спорол

(158) Ну если лезть в частности, то есть случаи когда можно паралельно проводить документы по одному и тому-же товару. Это ели расчет ведется по орагнизациям и/или складам отдельно.
"Разделителем проведения" может быть не только товар.

(165) Разумеется зависит от специфики и от данных. Для партионки если в регистре партионного учета склад не предусмотрен добавлять нельзя. В этом случае блокировки будут по ЮРЛИЦО+ТОВАР. Если есть склад то тогда ЮРЛИЦО+СКЛАД+ТОВАР.Во втором случае конечно уровень параллелизма выше.

закладка

Где статья?

Статья еще редактируется, поэтому прошу на формат и синтаксис внимания большого не обращать.
http://softpoint.ru/article_id375.htm

Завтра выложу другую, посвященную параллельным вычислениям.

кайфовая ветка... Очень нестандартная для нынешней OFF-ной мисты.

Просмотрел концептуальный пресс-релиз.
бууээээ

а что вы будете делать с измененными техкартами, торгаши

Да, в УПП не только торговля.

(169) как и ожидалось,
статья оказалась голимой рекламой Гибких блокировок СофтПоинта

(175) не без этого. Хотя тема навела на некоторые размышления

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

(175) Не нужно принимать все так близко к сердцу;) Чего же вы ожидали? Что я буду пиарить лично себя(как делают многие)? - мне это не нужно. Обещание я свое выполнил. Решение уверяю вас абсолютно рабочее. Любой одинэсник может при желании его реализовать, только на это нужно время и упосртво. Конечно же есть подводные камни, ну а где без них не бывает.

Еще раз повторю, что торговля выбранна лишь как тематика которая проще всего для понимания. Все таки с производством знакома гораздо меньшая аудитория. Для производства принципы абсолютно те же.

Вот еще одна статья , вообще на тему параллельных вычислений.
http://www.softpoint.ru/article_id376.htm  
Написан большой пул статей, будет выкладываться в среднем две в неделю. Да, там будет скрытый пиар но будет и много чего полезного. В частности технологии которые можно применять независимо и реализовать самостоятельно.

Следующая статья будет посвящена ускорения обмена в 1С путем применения тех же параллельных вычислений.

(180)[Да, там будет скрытый пиар ]
что, РАУЗ в УПП, выход КА и УТ 11 прихлопнули сегмент ?

(182) Нет, работы хватит на всех:) Просто давно статьи не выкладывали.

(182) РАУЗ - не панацея.

всегда хочется на халяву (не меняя кода) и что бы считало правильно

да уж... гора родила мышь...

дочитал до виртуальной биржи, дальше не стал

Как вариант распаралеливания:
1. Поднимаем еще один сервер и пихаем его в кластер
2. На основном отрубаем регл задания
3. Делаем кол-во процессов нового сервера = кол-во ядер - 1
4. Делаем фоновые задания, кол-во = кол-ву процессов
5. Ими проводим по партиям
6. и не забываем про упр болкировки

(186) Я лишь обещал то что обещал. Возможно вы ожидали или поняли задачу как то по другому. Задача реализуема, концепция объяснена.
(187) Тем кто понимает этого достаточно. (пример приведен для большего понимания)
(188) Так не взлетит. Последовательность будет нарушена, потому как процессы будут брать документы по очереди а вот проводится они будут не в хронологической последовательности. Либо если выбирать такой вариант необходимо изменять время документов(в некоторых случаях это не верно).

(188) Там пример в статье приводится почему координатор блокировок 1С и MSSQL не подходит.

(189) смотря как определять какую номенклатуру проводить
Вариант: есть таблица, в ней позиции для проведения, процессы выбирают что они будут проводить. Если все процессы завершились корректно, то двигаем ГП.

191. Корректность проведения(откаты транзакций по логике или на физическом уровне) это вообще отдельная тема.(это один из подводных камней которые нужно решать) В статье про это не расписано. В данном случае дело не в этом. Вот расскажите каким образом процессы будут выбирать документы из очереди документов? т.е. есть 8-м сессий 1С , каким образом они будут получать порцию сових документов(этом может быть и один документ)? Как вы в этом случае обеспечите ровно такую же хронологию как была изначально?(учитывая что время документов может существенно отличаться а также то что некоторые документы могут висеть на управляемых блокировках)

Жаль затихла тема.
На чём стоит писать координатор блокировок для распараллеливания? На 1С его получится его написать или нужен настоящий язык программирования?

Зависит от объема информацинных потоков. Мы реализовывали на C++.  На 1С реализовать можно но накладные расходы будут больше.

(194)
O_O На С++

Называется - горе от ума. Задача решается намного проще - без картинок и умных слов.

Работает у меня, работает у MIKEWIRE.

А вы, муму, постарайтесь отойти от "надо перепровести все документы!", ей богу - как за программиста - так просто стыдно.

(195) В частном случае решается гораздо проще. А в общем почетайте на тему параллельных вычислений - что это такое и зачем нужно. Может так не будет за меня стыдно.

(196) извиняюсь за опечатки-за них действительно стыдно;)

купить мать, в которую можно воткнуть 64 гига оперативы, и сделать рамдрайв на 60 с базой. перепроводить в файловом режиме

(198)+ ну это правда если база меньше 60 гб

(15) конец ветки.  выкладывай что там у тебя

(198) сие очевидное решение, предложено ещё в (10)

цена на порядок ниже варианта софтпоинта,
ускоряет всё, а не только восстановление последовательности

(201) Читаем отзывы на http://softpoint.ru/feedback.php
Внимательно думаем...   Предложи им свое решение которое "ускоряет все"(цитата из (201)) и думаю наступит счастье и может быть даже и комунизм.

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

(195) это разные решения.
теоретически - у Владимира получаются меньшие вмешательства в конфигурацию. И один проход.
(203) теоретически - да.

Согласен со всеми, кто сказал слово РАУЗ

(202)
А ты часто "внимательно думаешь"?

(204)
Я имел ввиду - у нас с тобой одинаковые решения.
Ускорение до x10 без гибких блокировок и C++-сной зайуми.

Вообще у меня мечта - вынести вообще восстановление партий в .NET логику. Это первая итерация.

Вторая - заюзать CUDA. ))))))

(195)а где ваше решение почитать

ЗЫЖ если в этой ветке было ткните плиз в номер сообщения

(37)

стопудово ясно, что на перепроведение доков навешано куча всего сопустствующего. если просто выбдрать расчет провести его "в стороне" и вложить обратно в данные - все должно получиться просто офигенно быстро...  ?

(207) Решения разные принципиально. У нас например есть отдельно решение "интеллектуальное востановление последовательности"(выборочное востановление), есть решение с кешированием расчета остатков для однопоточного расчета(ускорение линейного расчета- на него больше похоже).  
Каждое решение лучше подходит для своего случая. Описанное решение в ветке подходит для большинства случаев. Это подтверждается практикой. В конце концов все решает рынок. Если ты уверен в решении (37) - предлагай его. Получай заслуженную выгоду.
(211) Не покатит, есть понятие транзакции. Иногда то что кажется лишним вовсе таким не является.

(212)
"Решения разные принципиально"
Я не пойму. Ты - Mikeware?

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

Так что проще - внешняя обработка или "гибкие нейросети на С++"?

И знаешь, Муму, к твоим "нейросетям" претензий-то как бы и нет.

Просто ты создал тему (как оказалось для пиара) - бросил замануху, народ повелся, начал что-то предлагать - а ты тут с видом "все в г_овне - один я в белом" - вывалил свой ИИ в картинках. Как-то по жлобски.

(214) Здесь не пиар, пиар на сньюсах, рбк и т.п.:)   Вопрос - если твое решение такое простое и стандартное то почему его до сих пор нет в УПП?
Хочешь пиар? Если оно такое простое и универсальное-реализуй его для УПП. Выложим его бесплатно на мисте и на сайте софтпоинта. Если будет хотя бы 10-ть благодарностей(с примерами использования) - я выплачу тебе 1500 у.е. за потраченное время. Всем будет только хорошо.

(214)Уверяю тебя и всех остальных - я не хочу чего либо заработать на посетителях этого сайта. Это принципиально другая аудитория. Мне здесь нужно только лишь обратная связь. За это я готов заплатить сам(как информацией так и деньгами):)

(213) т.е во время проведения вообще не толкать партии, а потом фоном твоей обработкой ?

(217)
Да. Во время проведения движения по регистру партий делаются, но с пустой партией и ценой последнего прихода.

(215)
А ты в софтпоинте главный?

(215)
У меня и взаиморасчеты также считаются - моргнуть не успеешь - еще быстрее.

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

Пока разработчики УПП этого не поймут - в УПП много чего не будет.

P.S. Насколько я знаю - что-то подобное в УПП есть (фоновое проведение (???),РАУЗ). Мы замутили свою приладу раньше. )))

(215) как пример ответа на вопрос "если твое решение такое простое и стандартное то почему его до сих пор нет в УПП?".

отчет "Финансовый расчет" в УПП, часто выдает ошибку 256 таблиц
вот ссылка: http://1c-pro.ru/index.php?showtopic=5416
ошибка датирована 2007 годом
в 2008 я написал свой отчет, так как 1с не отвечала на вопрос когда пофиксят.
вот мой: http://luns-it.ru/2010/02/отчет-финансовый-расчет-для-упп-подс/

сейчас 2011 и ошибка в типовом так и осталась.

(221)
Ну, сейчас тебе зашлют "1500 у.е. за потраченное время"!!

(222) Меня многие здесь знают. Обманывать не буду. Напиши, выложи методику+обработку. Выложим бесплатно. Будет больше 10-и положительных отзывов - отправлю(им) тебе 1500 у.е. (любыми вариантами по желанию)

В свое время в институте (я заканчивал по специальности оборудование сварочного производства) меня учили, что самое лучшее сварное соединение - это отсутствие сварного соединения. Так и здесь - самое лучшее решение по восстановлению последовательности - это отсутствие необходимости восстанавливать последовательность. А все остальное - ересь...

А еще ересь - бюрократия,взятки и т.п. Реальная жизнь - штука многогранная.

(225) Еще раз - нормальная учетная система не подразумевает шаманства с восстановлением последовательностей чего бы там ни было - либо все это автоматизировано другими способами, либо регламентировано (жестоко, жестко, мягко) и т.д. Т.е. на поверхности лежит другая архитектура учетной системы, только обычно глаз замылен чем то, называемым "типовым". Мы живем в трехмерном мире, а проблемы учета рещаем в стиле 2D - вместо того, что бы перепрыгнуть проблему, мы ее обходим...

ПС. Термины навеяны недавним окном ИТРП и их нравоучениями (с коими я не совсем согласен), но лично я давно партионный учет (НКС, МПЗ, расчеты с контрагентами, ЦБ) решил полным отказом от каких-либо последовательностей, а перепроведение документов - это вообще грех, за который во времена инквизиции сжигали на кострах :)

Мы живем не в идеальном мире. У многих эта проблема актуальна. Перевоспитать всех слищком сложная задача.

(227) Вообще решение лежит на поверхности, причем с объединением (использую термины 1С) ордерного склада, партионки в классическом стиле и партионки в стиле 1С, финансового учета и оперативного учета - это использование учетных цен и счетов 15 и 16. 1С дернулась в этом направлении и заглохла на 1/10 пути. А ведь данная методология (даже не побоюсь этого слова - технология) абсолютно легальна с точки зрения всех видов регламентированного учета (РСБУ, НК, МСФО) и поддерживает любые прихоти управленческого учета. Применение методики учета в БУ счетов 15 и 16 разводит реальный складской учет и финансовый учет на две составляющие (приход/использование и расчеты с поставщиком/оценка себестоимости).

(0) зачем тебе последовательность?
А где пит?

(229) Так вот пита и нет... а то бы сейчас!!! Кстати, кто-нибудь что-нибудь о нем знает (о Пите)?

Как только вы захотите анализировать реальную валовую прибыль по сделкам, вам понадобится последовательность (партии, средняя и т.п.). Все разговоры про "волшебный" РАУЗ или про учётные цены только в первом приближении кажутся легким решением, на самом деле не отвечающее требованиям оперативности и точности. Решение не редактировать документы задним числом тоже имеет кучу минусов. В итоге по-любому встанет проблема востановления последовательности и, соответсвенно, её оптимизации. Самым лучшим решением будет в любом случае восстановление только реально нарушенной последовательности (а не всей подряд как это делает типовое решение). В случае если у вас есть механизм восстановления последовательности точечно (по конкретной номенклатуре/организации/складу и т.п.), распараллеливание процессов уже не становится некой сверхзадачей (хотя бузусловно ускорит процесс).
Если же последовательность нарушается глобально, по всем измерениям и всегда, как это требует автор, то тут уже стоит задуматься об организации бизнесс-процессов как таковых, а возможно и отказа от партий в принципе.

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

(232) - собственно что в этом то сложного? У меня на работе холдинг в 9 конторок упрощенки, упп, месяц проводится монопольно за 20 часов. При исправлении данных месяцом ранее (стабильно бывает и не раз в месяц) - последствия понятны... Так вот, всего то пару часов допиливал групповую обработку справочников и документов, и там сделал то по сабжу всего ничего - отбор по вохождению "Организация" и "номенклатура из списка в документе" + проведение с паузами - чтобы если край как надо днем восстановить - работе не мешать. Как бы вот и вс1/ зачем огород городить в этом случае?

А сабж тоже бред собственно. Если такое "надо" каждый день - так это что то в "датском королевстве" не аллё.

средневзвешенную уже предлагали?

> Не покатит, есть понятие транзакции. Иногда то что кажется лишним вовсе таким не является.
.
- непонятно! сторонней обработкой решаем логически законченный блок/алгоритм востановления/расчета псоледовательности... при чем здесь транзакции? или речь идет о фоновом восстановлении последовательности при работающих юзверях..?
.
вообщем особо непонятно зачем восстанавливать последовательность... получается что последовательность восстанавливать нужно только для правильного исчисления себестоимости/партионки... - ну и нахрена? была кривая партионка, по ней принимались решения, выполнялись.. теперь хреняк! выясняется, что "партионка" кривая - надо бы подкорректировать... - ну и фигли - корректируем в текущем моменте! нахрена ее сзади корректировать...??? отсается вопрос - как узнать, как именно корректировать в ТА...? какие данные - ПРАВИЛЬНЫЕ..???
.
вопрос идет о чем? о том как быстро восстановить последовательность...? может все-таки более продуктивно - не давать ее нарушать..? по крайней мере нарушение количественной последовательности - отлвливается практически мгновенно (спасибо питу, селенат и иже)... нарушение суммовых последовательностей последовательностей - см. выше - нака их восстанавливать..? кидаем добавку (на сумму исправления) в ТА - и все...????

Я смотрю на этом форуме сплошные идеалисты. У нас есть отдельное направление которое занимается консалтингом. Что такое сторнирование и т.п. я прекрасно представляю. Я понимаю что важно для управленческого учета не допускать коррекции задним числом. Но жизнь такова что все не идеально. Есть статистика в виде обращений клиентов. Одна из проблем - вышеозвученна.