v8: Ускорение восстановления последовательности документов в УПП. #541251

Дано: Есть УПП с партионкой. Нужно восстановить последовательность документов(путем перепроведения) с партионным учетом с целью перерасчета правильной себестоимости. Предположим серверные настройки оптимальные, сервер очень мощный.  Линейное ускорение  проведения документов, за счет оптимизации запросов,  возможно не более чем на 15%. Стоит цель ускорить время проведения в 3-5 раз. Каким образом можно это сделать и от чего это зависит?

Дано: Есть УПП с партионкой. Нужно восстановить последовательность документов(путем перепроведения) с партионным учетом с целью перерасчета правильной себестоимости. Предположим серверные настройки оптимальные, сервер очень мощный.  Линейное ускорение  проведения документов, за счет оптимизации запросов,  возможно не более чем на 15%. Стоит цель ускорить время проведения в 3-5 раз. Каким образом можно это сделать и от чего это зависит?

Дано: Есть УПП с партионкой. Нужно восстановить последовательность документов(путем перепроведения) с партионным учетом с целью перерасчета правильной себестоимости. Предположим серверные настройки оптимальные, сервер очень мощный.  Линейное ускорение  проведения документов, за счет оптимизации запросов,  возможно не более чем на 15%. Стоит цель ускорить время проведения в 3-5 раз. Каким образом можно это сделать и от чего это зависит?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор - ламо.

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

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

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

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

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

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

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

В 21-ом посте все расписано.

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

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

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

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

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

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

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

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

Я твоего поста вообще не понял. Ты просил "более менее точную концепцию реализации." Я показал решение - работает сейчас. Ты говоришь - что тебе долго разбираться - чего там ускоряется. Вводишь какие-то новые условия, запросы, хранимки... Лучше я тебе вопрос задам - когда коту делать нечего - он чем занимается?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В снеговике?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Закладка

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

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

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

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

окончание статьи я могу угадать " У автора имеется готовое решение...."