Всем привет.

Стоит задача запустить внешнюю обработку, чтобы перепровела все документы за 4 мес. По словам внедренцев двух дней на перепроведение может не хватит. И вот мне генеральный задает вопрос: почему так долго?

Вот и я не знаю, почему так долго )))

Помогите разобраться, где узкое место. Какие нужны вам исходные данные?

+(41) Ну и очередь можно куда проще проверить.

(37) да, компетенции у него достаточно

(34) Лучшее объяснение - потому что 300 000 документов.

(41) да? а нерассчитанные итоги не дадут такого эффекта?

(34) Запусти тест Гилева. Сам. Когда никто в базе не работает. И начинай писать отчет директору, со всеми выкладками. 300k документов будут проводиться не один час, это аксиома, и ни один специалист не будет вертеться ужом, доказывая что не верблюд. Нужно задать вопрос, а почему такая необходимость возникла, ведь фирма 1С делает все, чтобы в актуальных конфах такой потребности не было, как раньше? Доказывать свою компетенцию - если уж дошло до такого, все средства хороши. Как напишешь отчет, отправляй на email директору с копией внедренцам и будь готов держать удар.

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

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

(47) сам не могу. Везде имею доступы, а вот 1С исключение.

(47) через внедренцев только запущу вечером

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

(50) Тогда как ты можешь узнать причины тормозов? Пусть внедренцы и объясняют.

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

(47) где тест гилева показывает зависимость проведения некоторого количества доков?

(53) всё, что я могу им показать, что во время запуска перепроводки счетчик производительности показывает, что дисковая подсистема нагружена на столько процентов, а процы на столько. Мой, смотрите, уважаемый генеральный директор. Диски нагружены на 10%, а процы на 30%. Но он спросит: а почему тогда так долго проводятся документы?

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

(54) Пусть делают на тестовой базе сначала.

(51) вот и посмотрим на сколько начальник компетентен: если пошлет с гилевскими попугаями далеко, значит действительно так

(57) тестовый запуск проводок будет на тестовой базе, точней на копии актуальной

(55) Тест Гилева доказывает, что железо не говно. К автору могут быть вопросы плана, мол зачем купил все это, если все равно результаты посредственные?

Дичь какая-то.
Правильно выше сказали, в твоём случае единственно верный ответ - "потому что это 300000 документов за четыре месяца". Больше никакой вменяемой информации ты дать не сможешь по этому вопросу.

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

Просто генеральный считает (ведь на домашнем компе у него так), что раз диски SSD, то всё должно как минимум за минуту выполниться. А почему это не так, как он думает, я не могу доказать, потому что как уже говорил в 1С темный лес

(60) тест гилева показывает различие двух систем, не факт там, где показало больше попугаев будет эффективнее работать с определенным прикладным решением!

(15)  вакуумный расчет:
300000/86400 =3.5 дня(в вакууме, не верю что будет быстрее 1 документа в секунду)

Когда у нас HDD 15k RPM стояли, то очень часто нагрузка по счетчикам была 100%. После замены на SSD + рейд-контроллер, нагрузка в пике 70%

Дай своему генеральному ссылку на эту ветку. Пусть видит, как у тебя болит душа о работе и серверах.

(62) это самый простой и быстрый способ увеличить производительность. Что будете делать через год-два?

(34) > Мне надо какой-то ответ дать генеральному, почему так долго проводятся 300 тыс документов

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

А вообще 300тыс за двое суток - это как-то слишком. Какая хоть конфигурация?

(64) добавляем время регламентных операций и прочей хни = 4 дня минимум. я бы так закладывал.
Делаем проведение разных дкоументов в несколько потоков, в одной транзакции по 1000 элементов, ну может быть вернемся к 3 дням. Это если так сходу в лоб.

(65) ответь: проведение работает быстрее когда в базе никого нет или так же?

(70) разницы совершенно никакой

(63) Для автора это хоть что-то, чем можно оперировать при такой постановке вопроса. Статистику собирать, тот же Apdex, надо было заранее.

(71) а теперь бери конфигуратор, включай замер, сделай отбор доков ща сутки и проведи

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

(28) Ну возьми копию и запусти там,заоодно узнаешь сколько занимает

(72) проводится одинаково с юзерами и без них. Зачем apdex?  Что бы сейчас сказать что месяц наЗаД док проводился на секунду меньше, apdex  нужен для сравнения с исходным состоянием, до оптимизации, ну или для отслеживания. На вопрос ПОЧЕМУ, оно не оиветит

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

+ (73) смотри топ запросов по времени, а так же по количеству их выполнения, с этим уже можно идти к руководителю, проанализировав конеш

Перед проведением такого количества итоги нужно совсем отключить.Имхо дешевле будет их в конце посчитать.

(62)У него на домашнем компе 300000 документов проводятся за минуту?

(78) (79) Вы пишите системному администратору сейчас  о итогах, запросах и прочем)

(76) По Apdex можно примерно прикинуть время на проведение пресловутых 300k документ. Да и динамика тоже была бы любопытной. Конечно, это не дает ответ на вопрос "Почему", но тем не менее. Была бы основа для дальнейшего анализа. А там можно и ТЖ ковырять, и топ запросов.

(80) это образно я выразился. Я имею ввиду SSD панацея )

(56) Процессор будет нагружен на 4-8%. И?

(84) саммарно по ядрам? Или какие-то ядра на 100% будут нагружены?

(83)Вы все еще считаете его компетентным?

(63) При правильной настройке однопоточный тест Гилева зависит только от частоты и используемых версий ПО. Именно в частоту процессора и будет упор при проведении.

(69) Тут надо грамотно план составить, чтобы в взаимоблокировки не упереться.

(86) да нет конечно. У него инженерное образование и все же ему легче намного объяснять те или иные нюансы.

А конфа хоть какая?Переписана?

(90) Типовая, была, Торговля. Переписана вдоль и поперёк )

(71) Классика жанра - упор в частоту 1 ядра.

(85) Суммарно. Но так, что 1 ядро будет загружено на 100% - скорее всего не будет, ОС может перекидывать потоки с ядра на ядро. Будет характерная ровная линия загрузки на 4%, иногда подскакивающая до 8%. Это если в другие подсистемы упора нет.

(91)Ну а чего хотеть-то)))))

(91) Франчами?

(94) не знаю, что имеете ввиду. Переписана этими внедренцами.

(95) Откройте договор, там наверняка есть пункт типа что оптимизация за отдельные деньги. Смысл им писать так, чтобы не тормозило?

(82) Более 3х суток. Сейчас можно отследить код, который самый тормозной

(64) сейчас спросил внедренца. За 2-е суток в прошлый раз провели 200 тыс. документов.

(97) Для этого надо иметь доступ в Конфигуратор и включенную отладку на сервере.

(98) Т.е. они лажанулись один раз, затем второй раз, и совсем не факт что не лажанутся опять... может им деньги не платить?

(100) я не директор решать )

(101) И не разработчик, чтобы на такие вопросы директора отвечать конкретикой.

(101) замеры производительности есть в момент перепроведения?

Давайте просто элементарно посчитаем:

300 000 за двое суток, т.е за 48 часов или 2880 минут , или 172 800 секунд. В итоге каждый документ должен перепроводится менее чем за секунду , что имхо нереально ни на одном железе (если конечно документы не пустышки без движений по регистрам).

(103)Да нет у него доступа в 1С.

(105) Замеры производительности = сбор данных с счетчиков производительности винды

(104)Бред, зависит от кода в обработке и в проведении. У меня еженочно порядка 10000 проводятся, средняя скорость 2.04 документа в сек.

(106)Поняла.

(107) что за документы, поди реализации?

(0) Пригласите специалистов.
Ответы на подобные вопросы может дать только квалифицированный специалист, шарящий и в 1С, и в СУБД, и в железе. Называется 1С:Эксперт по технологическим вопросам.
Если ваш директор хочет получить однозначный и понятный ответ, придётся раскошелиться на работу такого спеца. Зато он назовёт конкретного виновника - железо, настройки сервера(ов), настройки 1С, настройки СУБД, конфигурация (неоптимальные алгоритмы, косяки в данных и пр.).

(109) Судя по объему - они, родные. FMCG и всё такое.

(109)Поступления, реализации, операции. Примерно в равных долях.

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

(104) > 300 000 за двое суток, т.е за 48 часов или 2880 минут , или 172 800 секунд. В итоге каждый документ должен перепроводится менее чем за секунду , что имхо нереально ни на одном железе

Всё вполне реально.
У меня бухня с её тормознутым регистром бухгалтерии при закрытии квартала проводит 42000 документов за 6 - 6.5 часов (на ночь запускают). То есть 300000 документов провелись бы как раз за двое суток (будь такая задача). И это отнюдь не на топовом железе и не на пустом сервере. На этом сервере живут ещё 20 различных баз, работает куча разного рода обменов, веб-сервисов и просто пользователей, которые трудятся 24/7. И это не считая регламентов СУБД и регламентных заданий 1С-ки.

(113) Не бред. С хорошим железом, вылизанным кодом с отключенными на время обработки проведения защитами от дурака это вполне реальные цифры.

(113)УПП. Я там код знаешь как вылизывала для серверного выполнения? Там ни одного лишнего плевка))) Поэтому и говорю, что от кода тоже много зависит.

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

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

(115) (116) Вот.., я не сказал что это недостижимо, сказал что трудозатратно и не всегда оправдано.. Ну, а так, да, это круто.

(118) да читают конеш, мож. еще и советы дают))

(116) Очистку наборов записей тоже свою делали?

(121)У меня не перепроведение, у меня создание и проведение. С созданием сопутствующих элементов при необходимости (контрагенты, договора, счета).

(0) "И вот мне генеральный задает вопрос: почему так долго? "
Ответь: "Еще не изобрели таких процессоров, на котором это было бы быстрее".

(104) Бред. У меня средняя скорость 300-400 документов в секунду. Бухгалтерия 3.0. Итоги бух регистра отключаем для перепроведения за месяц.
Вот логи:
Фоновое задание №209, время  = 54 сек. Обработано документов 1 000 из 1 000
Одновременно работает до 20 фоновых заданий.
База на SSD.

(123) 1С - на шаг впереди)

(122) С созданием сопутствующих элементов и док проводится за 0.5 сек?Я однозначно хочу посмотреть на этот действо и вылизанный код.Покажете?

(126)Нет, сорри, код показать не могу :) Могу примерные логи показать. И не 0.5, 2.04 документа в среднем, 30% объема операции, они конечно, хорошо статистику равняют :) Но проведение РН все равно меньше секунды.
https://cdn1.savepice.ru/uploads/2018/11/16/6e79507a658b2467f02e9dd82120e171-full.png




Начало загрузки из хх: 15.11.2018 22:00:44

Период загрузки из хх: 06.11.2018 00:00:00 - 15.11.2018 00:00:00
Не найден ИИН для счета KZхх
Счет в невыясненных : KZхх\Нет\Г\KZT\9\Да\Да
По документу ххх не найдено соответствие лицевому счёту получателя (KZхх)
Счет в невыясненных : KZхх\Нет\Г\KZT\9\Да\Да
По документу ххх не найдено соответствие лицевому счёту плательщика (KZхх)
Создание : KZхх\Нет\Ф\KZT\7\Да\Нет
Создано новый контрагент с наименованием ""
Активирован
Создание : KZхх\Нет\Ф\KZT\7\Да\Нет
Активирован
По документу ххх ЛицСчетПлательщика некорректен(KZхх):
БалансовыйСчет: 1741
Создание : KZхх\Нет\Ф\KZT\7\Да\Нет
Активирован
Создание : KZхх\Нет\Ф\KZT\7\Да\Нет
Активирован
Не найден ИИН для счета KZхх
Создание : KZхх\Нет\Ф\RUB\9\Да\Нет
Ошибка получения данных лицевого счета: KZхх
По документу ххх не найдено соответствие лицевому счёту плательщика (KZхх)

Окончание загрузки из РС: 15.11.2018 23:10:35
(2,04 в сек)
    Обработано : 8 544
    Загружено  : 8 538
    Ошибок     : 0


(0) У вас некомпетентная обслуживающая организация, отправили вам стажеров.

(4) Очевидно, нужен новый сервер!
R7100 + H7300 + SSD 4800Gb + 480 Гб ОЗУ, тогда скорость загрузки тяжелого отчета станет 3,2 сек.

(129) Надо два для отказоустойчивости, обязательно СХД на ССД к ним с 10 Гбит линком ещё.

+(130) Хотя нет, 56 Гбит инфинибэнд лучше будет.

Разумеется, это всё в VMWare кластер HA (обязательно лицензионное).

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

(0) Что мешало перепровести 4 месяца в копии базы и потом планом обмена загрузить документы с движениями за выходные?

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

(135) Блокировки?

(135), (136) Ну хотя ночью фоновым запускать пачками...

(136) Вопрос в (0) не в блокировках, а "почему так долго" :)

+(138) Речь о том, что на непрерывное проведение 300к документов уходит 48 часов, а директор вопрошает голосом индейца из "Горячих голов" - "х.ли так долго?".

(139) Вопрос к адекватности 1С-ников
https://its.1c.ru/db/metod8dev/content/5843/hdoc

(140) Автор не адинэсник, собсно.
В (124) уже такое решение описано.
Вопрос в том, насколько оно применимо к задачам ТС? Если речь идёт о последовательном перепроведении одного типа документов, ничего распараллелить не выйдет.

(141) Да, но вопрос из (0) должен быть адресован в сторону 1С, который неадекватен и легко ему спихнуть все свои косяки на железо.
Если бы был проц 2Гг, HDD убитые и все это в виртуалке, тогда да. Но автор темы больше в теме разобрался похоже, чем обслуживающая организация.