Всем привет!
Ребят, срочно нужен совет.
В 1С 8.3 есть очень тяжелая обработка (выполняется очень долго по времени, около 10 суток).
Я запустил её 5-тью фоновыми заданиями, каждое задание работает со своим блоком данных. В итоге данные теперь выгружаются параллельно, примерно в 4 раза быстрее. И всё бы ничего, но через сутки почему-то произошел перезапуск фоновых заданий, всё как ни в чем не бывало работает, но я смотрю, данные опять начали выгружаться с начала, хотя не выгрузилась ещё и половина.
Т.е. по какой-то причине фоновые задания перезапустились и стали работать опять с тем набором данных, который был им передан в качестве параметра. А в наборе данных список подразделений. И этот список стал опять с самого начала обрабатываться.
Как такое может быть?

смотреть в консоле сервера 1с, через какое время перезапуск бла-бла бла сеансов

Это в свойствах кластера?

Там есть "Перезапускать рабочие процессы"

"Перезапускать рабочие процессы"
У нас там задано:

Интервал перезапуска: 0 секунд
Допустимый объем памяти: 16194303 КВ
Интервал превышения допустимого объема памяти: 60 секунд
Допустимое отклонение количества ошибок сервера: 0%

Галочка "Принудительно завершать проблемные процессы" НЕ стоит.

Т.е. дело в превышении объема памяти?

Рабочий процесс я так понимаю у меня один, и он запустил 5 фоновых заданий. По диспетчеру задач смотрю, rphost занимает сейчас 4 гига. Это и есть вроде как мой рабочий процесс. С чего бы интересно он вдруг 16 гиг сожрал через сутки работы, а сейчас опять спокойно свои 4 гига использует. Операции делаются однотипные, с интервалом 4 минуты каждая

Бабака, что можно делать 5 суток Оо

(0) в ЖР смотри, возможно, была ошибка во время выполнения твоего задания и оно тупо перезапустилось, ты же в расписании рег задания задаешь количество и время перезапуска

оно может и вечно перезапускаться

(6) Это не регламентное задание. Это моя обработка, которая вызывает из общего модуля процедуру как фоновое задание:
Задание = ФоновыеЗадания.Выполнить("имя общего модуля", НаборПараметров);

Если при выполнении ошибка, то у меня обработка вылетает, т.к. перестает действовать это:
ФоновыеЗадания.ОжидатьЗавершения(МассивЗаданий);

Мне ещё непонятно, если рабочий процесс перезапускается, то фоновые задания запускаются заново, не переносятся в этот новый рабочий процесс с текущим состоянием?

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

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

(10) А кто мешает 100 сразу запустить.
Там Филлипов 15К на одном кластере фоновых запускал.

(12) Без разницы. Все упирается в число ядер процессора.

(13) та я то не спорю, но 5 суток это жесть, не поверю что там нельзя соптимизировать...

Ой даже 10.

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

(0) А в конфигураторе - администрирование - параметры информационной базы - время завершения спящего. Сколько стоит?

(14) нет желания переписывать стандартную регламентированную отчетность. Уверен что можно её оптимизировать, но разобраться там не реально.

(16) Может следует в код залезть и понять в чем дело?
Лично сутки до 40 минут ускорил за пару деньков на прошлом месте работы, особо не напрягаясь, можно было еще, но лень.
Может там индекса не хватает, или итоги не расчитаны, и такое бывает.

То есть по факту может случится так, что сам код и правитьне прийдется

(17) спящего - 3600 секунд
пассивного сеанса - 1200 секунд

Но это наверное не относится к текущей проблеме

(19) В прошлой конфигурации я эту отчетность сам написал, работала минут 10. Перешли с ЗУП 2.5 на ЗУП 3.1, там по одному подразделению формируется 4 минуты. Я не успею разобраться и оптимизировать, сроки сдачи поджимают.

(22) ну дык темболее. 10 дней надеятся что РП хост не упадет - это надо быть очень верующим человеком.
Скорее всего проблема где то недалеко, скачай хоть ИР, посмотри проблемный запрос, посмотри его план, часа за 3 можно хотя бы понять в чем дело. Еще окажется что 100500 раз найтиПоНаименованию вызывается (Тру стори между прочим)

(23) 10 дней, если не распараллеливать. У меня за 3 дня должно. Плюс я сделал, что после сбоя могу продолжить с места аварии, а не с нуля. Для меня стало открытием, что фоновые задания сами с нуля запустились. Я не заметил и потерял много времени. Я проверяю периодически, вижу что файлы создаются, процессы работают. Не ожидал такой подставы

(0) "И этот список стал опять с самого начала обрабатываться.
Как такое может быть?"

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

(24) "Плюс я сделал, что после сбоя могу продолжить с места аварии, а не с нуля."

А как реализовал?

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

(26) "А как реализовал?"
Ну вариантов то куча. Я сделал примитивно, пишу лог. Вижу на чем вылетело. На форме обработки запуска для каждого параллельного процесса в поле ввода прописываю код, с которого начинать. Ну и формирую набор данных для пакета с учетом этого

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

(27) Записываете в свой регистр все параметры заполнения (организация/сотрудник).
Два измерения "Выполняется", "Выполнено".
Стартуете фоновые - считываете оттуда параметры, как забрали - проставили "Выполняется". Как отработалось - "Выполнено".

(30) Ну или как-то вычленяете что отчет уже создан.

(22) У меня коллега также говорил, что не успеет оптимизировать. Я ему за 5 минут ускорил с 4 часов до 10 минут.

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

(32) Не знаю ребят, может я тупой, но я как залез в код формирования статистической отчетности П4, так и вылез оттуда с ужасом.
Ну и ещё дело в том, что перешли на ЗУП 3.1 только что, код очень сложный для меня везде, подход совсем другой. Во-первых управляемые формы, во-вторых вся регламентированная отчетность на фоновых заданиях построена. Да и столько вложенности, что теряешь мысль просто.
Максимум что смог пока на скорую руку, это сделать свою обработку, которая сама формирует все отчеты, ибо пользователю нереально сидеть жать кнопку, ждать 4 минуты, потом выгружать отчет, опять ждать... И так 4 тыщи раз :)

(0) >>выполняется очень долго по времени, около 10 суток
Дальше не читал, сжечь ведьму!

(35) Дак это стандартная конфигурация, стандартные отчеты так формируются в ЗУПе.

+(35) Все-таки прочитал, любопытно стало, что может делаться 10 дней без возможности выполнить это порционно
4000 реготчетов
Выгрузить
Ага
Без комментариев

(36) Откуда нахрен может появиться 4000 реготчетов?
Это сколько ЮЛ в базе?

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

Рукалицо

(34) ставите замер производительности с подключением к фоновому, потом сортируете по времени выполнения и смотрите самые долгие блоки.
Если база SQL - проверьте актуальность индексов.
(36) Там может в индексы запрос не попадает. Из практики был регистр сведений, запрос к которому очень сильно тормозил (делали полный перенос по >50 организациям из предыдущей редакции). Стоило только порядок поменять в измерениях - все относительно быстро стало, там он изначально неверный указан.

Ребят, а можете подсказать вот что:
Написана внешняя обработка. В этой обработке есть запрос по подразделениям. Этот запрос выдает список подразделений, который разбивается на блоки и каждый блок передается в фоновое задание:
Задание = ФоновыеЗадания.Выполнить("имя общего модуля", НаборПараметров);
Дак вот, после того как у меня фоновые задания перезапустились, формирование отчетов началось с самого начала, я писал об этом выше. Но я думал перезапускаются именно фоновые задания, именно с тем набором данных, который был в них передан. Однако нет. За время формирования в базе я изменил кое-что в одном подразделении, и в фоновые задания  после их перезапуска это изменение передалось. Т.е. началось формирование не с тем набором данных, который был передан изначально, а с новым набором, как-будто я опять запустил свою обработку, которая формирует новый запрос по подразделениям и запускает фоновые задания. Не могу этого понять. Ведь при перезапуске рабочего процесса моя обработка не может перезапуститься (нажаться заново кнопка выполнить)?

(38) больше 4 тысяч
Одно ЮЛ

(42) LOL
Что это за 4000 реготчетов?

(33) То что нельзя править конфигурацию - можно сделать на копии.
(42) Напишите уже название отчета и версию конфигурации, долго мусолить будем иначе дальше.

(39) ничего не понял. Есть опыт оптимизации отчетности П-4? Типа нет ничего сложного заставить стандартный регламентированный отчет работать быстрее? Или что сказать хотели?
Кстати есть вторая база у нас небольшая (другая организация), там всё быстро формируется.

(43) Да блин, я понимаю что Вам весело и интересно, но тема не об этом. Я уже написал, что это отчетность П-4. Она формируется по подразделению (на самом деле не по подразделению, а по ОКПО, но ЗУП это делать не умеет, это я уже потом склеиваю и формирую XML).
Следовательно сколько подразделений, столько и отчетов. Всё понятно?

(45) Какой-то сюр, а-ха-ха

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

(43),(44) Извиняюсь. Почему то нет поста, где я писал что это отчет П-4. Не отправилось видимо

(46) Хоть какой-то свет пролился на тайну, покрытую мраком
Не компетентен в ЗУПе, не буду комментировать

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

У вас с индексами в базе похоже проблема (только догадки), отчет на 3тыс. сотрудников у нас не тормозит, секунд 20-30 формируется на совсем дохлом железе.
Либо рекурсивно обходит справочник подразделений каждый раз.

(51) Так он его 4000 раз формирует

(51) С индексами должно быть всё в порядке, у нас настроено обслуживание SQL-сервера.
Сотрудников у нас около 20 тысяч.

> "отчет на 3тыс. сотрудников у нас не тормозит, секунд 20-30 формируется"

Это какой отчет? П-4? У вас нет обособленных подразделений, по всей организации в целом формируете?

> "Либо рекурсивно обходит справочник подразделений каждый раз".

Кто обходит, стандартный отчет 1С? Ну не может такого быть

(52) О чем Вы? Конечно 4 тыщи раз формирую. А Вы как хотите, если отчетов должно быть 4 тыщи? Причем тут это

(0) а может быть обработку написать по человечески, которая бы при перезапуске запускалась с того места, на котором прервалась? не думали об этом?

(55) понимаю, что всю ветку читать не хочется. Но спасибо за совет

(41) А никто не может подсказать по посту #41 ?
Мне непонятно как происходит перезапуск фоновых заданий. Хочу сделать, чтоб в случае перезапуска продолжалось с места разрыва, но не понимаю, почему при перезапуске фоновое задание на входе имеет не прежний набор данных, а с учетом изменений (например за время формирования отчетов какое-то подразделение стало иметь другие характеристики, и при перезапуске не попадает в набор данных для фонового задания).
Ведь набор данных для каждого фонового задания формируется запросом в обычной внешней обработке, и потом передается структурой "НаборПараметров" таким образом:
Задание = ФоновыеЗадания.Выполнить("имя общего модуля", НаборПараметров);
Почему при такой реализации при перезапуске фонового задания  НаборПараметров меняется, как будто внешняя обработка заново выполнила запрос? Я понимаю, если бы внутри фонового задания получались необходимые для обработки данные. Тогда всё ясно, оно перезапустилось, входные данные обновились.

случайно не стоит перезапуск процессов раз в сутки?

(57) а точно в коде задания нет получения или модификации переданного ему набора данных?
Значения по умолчанию для параметров определял?

(58) Нет, не стоит.

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

> "Значения по умолчанию для параметров определял?"

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

НаборПараметров = Новый Массив;
НаборПараметров.Добавить(Организация);
НаборПараметров.Добавить(СписокПодр);
НаборПараметров.Добавить(ДатаНачала);
НаборПараметров.Добавить(ДатаКонца);
НаборПараметров.Добавить(СчПотоков);
Задание = ФоновыеЗадания.Выполнить("<ПроцедураОбщегоМодуля>", НаборПараметров);

Сама процедура:

&НаСервере
Процедура <ПроцедураОбщегоМодуля>(Организация, СписокПодр, ДатаНачала, ДатаКонца, НомерПакета) Экспорт

У меня разок было подобное.
В серверном методе возникала ошибка от нее падал rphost и внешняя обработка повторяла серверный вызов.

(57) На 8.3.12 подобное в порядке вещей. Т.е. если явное или неявное фоновое задание крашится, то выполняется "мягкий" перезапуск. Такое ощущение, что многие вещи сейчас работают асинхронно(к примеру, всякие ПроцессорВывода...). Однако, крашится почему-то чаще, и вот эти вот перезапуски иногда мешают, в том числе обработать исключение. Иногда обработка просто зацикливается из-за этого.
Если есть время, попробовать бы на другой платформе, 8.2.13 или 8.2.14.