УПП 1.3 РАУЗ Оптимизаиция расчета или Что делать и Кто виноват? #553826

Время проведения документа выросло в геометрической прогрессии, с начала проведение занимало 1.5 часа, сейчас 5 часов (за основу взят один и тот же период). База файловый вариант (клиент-серверный считает 8 часов и более). Описание машины :

Процессор: i7

Увеличилось количество аналитик. И кстати, там достаточно неоптимальные запросы и операции по записи в регистр... Я возился и увеличил скорость проведения с суток, до 4.5 часов.

64-разряда Win7 Если кто сталкивался с подобным помогите пожайлуста.

Много переписывать пришлось?

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

Количество записей в регистр "Учет затрат" от 200 000, "Первое приближение СЛУ" от 170 000. Сколько было у Вас? На каких операциях были основный проблемы?

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

У нас с 3 часов до 20 минут оптимизировали... серверный вариант. Руки пока не дошли посмотреть как

Подскажите пожалуйста кто оптимизировал?

Програмеры, ктож ещё

1. ~500 000, 2. ~ 800 000

:) Спасибо большое за информацию ДенисЧ, пошел за напильником, придется поработать!

Скажите пожалуйста, какие настройки сделаны в константах? или оставили типовые?

У нас убрано распределение затрат на характеристики и серии.

Но это не для скорости было сделано, а для удобства распределения.

А количество итераций СЛУ изменяли?

Временные таблицы для хранения промежуточных решений используете?

У нас за 5 минут всё считает. Ничего не настраивал.

Как снятие флажков в детализации учета РАУЗ влияет на скорость - хорошо бы проверить.

Сообщите пожалуйста данные указанные в .

Учтите что количество записей указано в одном документе

У нас ведется учет по сериям, так что снять только флажок с характеристиками получиться. Плюс еще метод списания МПЗ ФИФО. что судя по коду тоже увеличивает время.

1. 33 000 2. после обеда посмотрю

Как думаете количество итераций 50 это наверное для таких массивов данных многовата?

Вот здесь про такую ситуацию

Спасибо за ссылку

...а если еще РАУЗ наложить на переписанную базу, где и так своей аналитики выше крыши... никакие ВрТ не спасут и разбивания запросов. Да, 1с-ники, хорошие инструменты по оптимизации выданы... Палка-копалка и каменный топор. Даж пристрелить нечем.

У меня одна итерация. А где ты смотрел "Первое приближение СЛУ"?

Спасибо интересная статья. Регистр сведений "Первое приближение для решения СЛУ"

Не за что. 2. ~25 000 То сложность расчета у меня конечно в разы меньше, чем у вас.

У меня такая же проблема, в первый месяц использования РАУЗ с/с считалась 1.5 часа, сейчас по 8-10 часов. Только приступил к оптимизации, уже нашел неоптимальные куски кода: Запрос в цикле, в рекурсии, в котором остатки по регистру УчетЗатратРегл соединяются с вирутальной таблицей по реквизитам КорАналитика...

ДенисЧ, подскажите какими инструментами пользовались при поиске неоптимальных кусков. Еще подскажите, как оптимизировали запись регистра в БД, типовой расчет с/с итак пишет по 1000 элементов.

у меня есть предприятие, где себестоимость безо всяких РАУЗ считается от 6 до 15 часов (в зависимости от периода - один или 2 месяца).