Добрый день.

Прочитал интересную статью про параллельные вычисления (http://softpoint.ru/article_id424.htm).

Вопрос заключается в следующем:

При запуске нескольких фоновых заданий, распределение их на ядра процессора происходит автоматически или это надо прописывать(указывать)?

Чёрт возьми, уже вечер...

в понедельник пиши :D

Буду рад скорейшему ответу.

(0) даже если все они(фоновые задания) попадут на один rphost, они будут не на одном ядре и рулить распределением по ядрам ты не сможешь, да и не нужно

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

(0) ещё учти, что все эти "параллельные вычисления" реально могут напрячь сервер приложений, и при огранниченных ресурсах днем количество потоков, которые можно запустить без ущерба для общего быстродействия, не так уж велико.
У нас восстановление последовательностей по партиям и реализации, по восемь потоков каждое, выводит сервер("с 16-ью ядрами") на 100% загрузку

У меня 4 ядра, собственно столько потоков я и хочу запустить... Это логичное решение?)

v8: Эффективность фоновых заданий

Добрый день, коллеги.
На текущий момент вопрос складывается такой:

Как управлять количеством запущенных фоновых заданий на основе одного регламентного задания?

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

Буду признателен за ответ, который подтолкнёт к нужному решению...

(9) Видимо, следует написать некое подобие своего примитивного диспетчера потоков.

rphost многопоточное приложение, поэтому фоновые задания крутятся в разных потоках. Как эти потоки будут распределяться по камням, по-моему рулит Windows. По крайней мере 1С не содержит функций распределения фоновых заданий не только по процессорам, но и даже по rphost'ам

Ну а как мне запустить определённое количество фоновых заданий?
Или можно запустить только одно задание регламентное?

(12) Просмотрел.

Надо ориентироваться на количество запущенных фоновых заданий и если их больше 4, то не запускать регламентное задание?!

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

Я вообще то в программировании слабо разбираюсь.
Но вышеизложенный способ реализации параллельности вычислений, для меня,начинающего 1Сника выглядит как бред.

Цитата из Википедии:
"Основная сложность при проектировании параллельных программ — обеспечить правильную последовательность взаимодействий между различными вычислительными процессами, а также координацию ресурсов, разделяемых между процессами."

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

Но повторюсь - это мое ИМХО. 1С я начал изучать несколько месяцев назад и до этого программированием не занимался.
У 1с явно сложности с параллелизмом. Платформа писалась на С++. Ни о применении функционального программирования, ни о других методах повышения скорости вычислений относительно своей платформы 1с никогда не заикалась.
Да какая параллельность вычислений, если у 1с даже среда разработки дубовая. Сравните с Visual Studio

(17) восстановление последовательности в несколько потоков - вполне реальная вещь

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

а умные слова типа "функционального программирования" - лишь способ сделать свой пост "умнее"

(18) может быть. Надо разобраться.
функциональное - ага :) надо же выебнуться :)Просто насколько я слышал некоторые функциональные языки не имеют проблем с параллельностью. Только на них реально никто не пишет

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

(17) да даже обычные бухгалтера могут распараллелить 1С - запустить два клиента, а они вообще не в курсах про дубовость среды разработки.
А сравни бухгалтера с программистом, уверен, Noxvil распараллелит 1С и даже свою "зероэмку" придумает и тоже попадет в викепедию

(0) Не слушай никого - все реально. Единственно что не все прикладные задачи хорошо распараллеливаются. Задача какая стоит?

(24) вы не путайте человека. Суть вопроса:"Могу ли я повлиять на распределение потоков по камням средствами 1с, тем самым ускоряя обработку? "
Нет, не сможете.
Можно ли ускорить проведение документа через реализацию "механизма многопоточного проведения" ? Ну если это оптимизирует работу конфигурации, то да.

(25) не было ни первого, ни второго вопроса )
Вы подогнали вопросы под свои заумствования.

(26)+1

(15) Может наконец пора озвучить решаемую таким образом задачу?

Что пытаемся распараллелить? Что реально делает код - он таки что-то усиленно вычисляет или он исполняет запросы?

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

Коллеги, я так понимаю - двигаюсь в правильном направлении...

За 5 дней провел бы уже обычным способом

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

(31)Спасибо КЭП :)

Но мне интересна сама технология...

(31) смотря сколько документ проводится. если минуту - то нет

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

(34) если документ проводится минуту, я лучше бы этой проблемой занялся :)

(29) Запусти несколько 1С. В каждой сделай отбор по своему списку контрагентов.
И жми "провести".

(17) "Да какая параллельность вычислений, если у 1с даже среда разработки дубовая. "
Да видел я глаза трупрограммистов, которые впервые узнали, что у 1С тоже есть дебаггер...

(37) - (33)

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

Только что допёрло, что именно в момент запуска регламентного задания и надо запускать фоновые задания с разными ключами. Собственно основное регламентное задание и есть диспетчер... Правильно?
Код запуска фонового задания - ФоновыеЗадания.Выполнить("СтрокаЗадания.ИмяМетода") и оно как раз и будет запускаться на сервере, т.к. регламентное запускается на сервере.

(16) пропустил я твой пост... изобрёл велосипед

Я, конечно, извиняюсь. Но, мне кажется, что распараллеливать какие-либо процессы в 1с часто не имеет смысла т.к., обычно, производительность упирается не в загрузку процессора/ядра  а в дисковую подсистему.

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

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

типа параметров сеанса

(41) В первом посте нет задачи, там вопрос "как происходит?". А хотелось бы посмотреть на формулировку задачи для 1С, для решения которой распараллеливание имело бы смысл.

(42) не через базу - это как? через сторонние сервисы?

(45) ну типа глобальных переменных, чтобы семафоры ставить правильно.

(46) а... справочник и блокировки :-)

+(44) Прочитал задачу по ссылке - похоже, там изначально проблемы не с производительностью (скоростью выполнения) а с возможностью работы вообще: большим объемом данных, который 1с не смогла "переварить" в одном документе.

(48) Да, но как побочный эффект - скорость выполнения выросла.
(42) Думаю, что фоновое задание может обращаться к набору параметров через определённый этап работы в цикле. Параметры могут быть константами...

(42) в фоновое задание в вызываемый метод можно параметры передать, обратно можно выкрутиться через СообщениеПользователю - Сообщить в задании и фоновоеЗадание.ПолучитьСообщенияПользователю(<УдалятьПолученные>)

+ (50) так же задание можно рубануть и запустить новое с новыми параметрами, еси чо

(51) ну, допустим, у нас есть стек заданий, 3 потока. через базу (упрощенно) - мы диспетчером запихиваем очередь, запускаем фоновые задания, задание читает хвост, удаляет, выполняет, читает хвост... при этом время выполнения одной задачи может в разных потоках различаться в разы. Как убрать в этом случае оращение к базе?

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

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

когда 3 потока запущены: ФоновыеЗадания.ОжидатьЗавершения( Наши3ФоновыхЗадания, 1 ), после завершения ожидания (выход по таймауту генерит ошибку) проверяем состояния заданий, если есть завершенные, удаляем элементы из массива согласно соответствию и стартуем новые.

+(54) если диспетчером является форма, то там можно вместо ОжидатьЗавершения сделать через обработку ожидания

ФоновыеЗадания.ОжидатьЗавершения( Наши3ФоновыхЗадания, 1 ) не подходит, так как одно задание может идти 10 секунд, а 2 других - по секунде. + очень большие накладные расходы на старт/стоп заданий, так что лучше бы не перезапускать их, а организовать работу с 1 очередью

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

если через СУБД, то менеджер записывает, допустим в РС, очередь.  запускает фоновые задания, каждое задание берет задачу из очереди, удаляет запись, выполняет. берет следующую задачу. тогда обеспечивает равномерность нагрузки на потоки выполнения задач

(57) часто стартовать задания - слишком долго

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

(59) да, продолжают, но выдавать по одной задаче в фон - слишком накладно.

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

(60) всю тему не читал. Замеры делал? мы про какой порядок говорим?

(62) если делать ФоновыеЗадания.ОжидатьЗавершения( Наши3ФоновыхЗадания, 1 ), проверять, какие завершились, запускать новые, тогда очень много стартов фоновых задач.

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

(64) вариант с хранением очереди в СУБД быстрее, чем старт кучи фоновых заданий. но при этом постоянно дергается одна и та же таблица, что не очень мне нравится. даже непонятно, как замерить, какой % времени происходит на забирании задачи из базы :(

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

(65) кучу стартующих задач можно уменьшить, передавая не по одному элементу, а какую то часть. Да и при грамотном регистре нет ничего плохого в его использовании

Для себя решение моей задачи я увидел такое:

Создаю регистр сведений

ЗадачиКВыполнению

Измерения: поток (фоновое задание, может разделяться ключами), ссылка на объект
Ресурсы: проведён, заблокирован, ошибка, комментарий

Создаю регистр сведений:

ФоновыеЗадания
Измерения: поток
Ресурсы: Заблокирован (используется)

Обработка:

ДиспетчерФоновыхЗаданий:

Возможности:

Разбиение документов к перепроведению на потоки, установка количества активных потоков(фоновых заданий), запуск потоков (фоновых заданий)

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

Вообщем все зависит от логики документа "Списание с расчетного счета".
Почитай еще такой пример
http://softpoint.ru/article_id375.htm
Здесь применяется немного другой подход.Все зависит от предметной логики. ПОэтому в этой сфере не бывает универсальных решений.

Так разделить на контрагентов не составляет особенного труда... Берём все доки, смотрим сколько у каждого контрагента, потом по методу фифо (или лифо, всё время путаю) делим всё на 4 части...

(70) Обязательно, но уже вечером или завтра. Всем хорошо сегодня отдохнуть )

(26), (27) - что тут подгонять? Я пытался сказать что ТС ошибается.
Если на пальцах- оптимальное количество потоков не равняется числу ядер процессора.

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

причины
1. распаралеливание может привести к дедлокам
2. распаралеливание довольно тяжело отлаживать и искать в нем ошибки
3. средний уровень 1с прогов на столько низкий, что после увольнения автора сиего чуда конфигурация просто умрет....

автору советую начать с оптимизации скорости тех алгоритмов которые есть сейчас (включая оптимизацию SQL). МуМу правильно говорит но, он не учитывает то что у него есть соответствующая квалификация и опыт а у большенства 1с ников этого нет....

Оно зависит от степени распераллеливания задачи.Есть задачи которые вообще не распараллеливаются и заисит от ресурсов сервера. К примеру если диск станет узким местом в одном потоке - нет смысла вообще делить на потоки. Ну а остальное все ньюансы.(затраты на диспечеризацию и т.п.)

(75) я паралелил 2 задачи

1. востановление последовательности
2. начисление процентов

в обоих случаях после меня проги все переписали в один поток, потому как не смогли внести даже мелкие исправления :)

ИХМО
в данном случае минусы сложности решения занчительно перекрывает положительный эффект по быстродействию

Noxvil рвёт шаблоны общения на Мисте...нехорошо )

(76) ну, это смотря как писать. можно и понятно написать.

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

Коллеги, добрый день.

Дискуссия продолжается!

(78) Жму руку.

"Дабы раскрыть секрет":
Считаю себя средним программистом, способным создать сложную систему. Опыт разработки - 3 года.
Обожаю сверх "красивый" и "оптимизированный"(интеллектуальный) код, который не всегда бывает понятен... )

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

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

sql 2008, windows server 2008, 1c 8.2

(81)
http://kb.mista.ru/2/doku.php?id=it:analiz_sql_block&rev=1347946765
ну и про регламент SQL почитай на проф сайтах

Ок, почитаю. Спасибо.