Как передать в фоновое задание большую таблицу значений (12 млн записей) #725664

Добрый день коллеги, пытаюсь с помощью многопоточности ускорить обработку таблицы значений, но встал вопрос как эту таблицу передать в фоновое задание, через параметры если передавать, то пожирается гигов 30 памяти на сервере 1С и повисает, запуска самих заданий не дождался, есть какие идеи?

Добрый день коллеги, пытаюсь с помощью многопоточности ускорить обработку таблицы значений, но встал вопрос как эту таблицу передать в фоновое задание, через параметры если передавать, то пожирается гигов 30 памяти на сервере 1С и повисает, запуска самих заданий не дождался, есть какие идеи?

Добрый день коллеги, пытаюсь с помощью многопоточности ускорить обработку таблицы значений, но встал вопрос как эту таблицу передать в фоновое задание, через параметры если передавать, то пожирается гигов 30 памяти на сервере 1С и повисает, запуска самих заданий не дождался, есть какие идеи?

В файл выгружай

там наверно ключевое "ускорить обработку "

база на скуле? такую таблицу проще затолкать в таблицу скуля и обработать там, если она на куски не рубится

а мысль :)

кстати, вариант...

И кто только придумал эту ересь - передавать огромные ТЗ в параметры фонового задания. Распараллеливают они, ппц Лучше придумать другой алгоритм "диспетчерзиации" задач между запущенными заданиями. Так, чтобы не требовалось гонять половину базы в оперативной памяти (а это и происходит при передаче параметров фонового задания).

И ещё кстати... Почему не заставить РЗ самому получить эти 12 лямов строк?

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

"Этот вариант оч. долго согласовывать" Беги оттуда

формально он у тебя есть - ты же в базу ходишь как-то

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

>И не совсем понятно как объектные сущности в таблице значений разложить в таблице SQL много шаманства по моему будет мы не в курсе накой черт тебе 12 лямов записей

Мне они не нужны, табличка из типового проведение себестоимости УПП (РАУЗ)

Если РЗ=ФЗ, то думал об этом, но к сожалению в моей задаче это не сработает

Изначально не выносить с сервера на клиент

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

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

Сериализация-десериализация ТЗ способны устроить кошмар любой системе.

Как эта ТЗ формируется? Очень сложно?

Добавь свой регистр сведений - будет как ТЗ.

>Как эта ТЗ формируется? Очень сложно? запускают чего-то типа расчет себестоимости - и привет

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

Хреновое решение.

где ТС? что распараллеливается то?

было не так давно в одной отраслевой упп... модуль проведение документа. внутри два цикла, один в другой вложен внутри 2-го обход ТЧ и набивание ТЗ построчно... теперь простая арифметика: и каждый счетчик циклов по 100 итераций ТЗ = 10 000 000 строк клиент "думает" до 2 Гб и падает

Огласи чемпиона.

что делает клиент? звонит во франь, консультант франя заходит по rdp на сервак и (о чудо!) проводит документ. За 10 минут. Сервак 64-бит. А значит 3,5 Гб на клиента скребя ложкой по дну ему хватает. какой вывод сделал франь? купите 64-бит сервер 1с...

так куплен же. что еще покупать?

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

у тебя то сервер падает

Запись движений в базу (сколько строк столько и движений)  :)

+ движений=записей в регистр накопления

а нельзя эту ТЗ прямо внутри фонового генерить?

+ например, в фоновое передавать только организацию, подразделение и там группу какой-нить номенклатуры, а таблицу оборотов (предположим, что речь про обороты) получать из базы уже там

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

Пусть фоны читают ТЗ и ждут, пока все флаги в служебном регистре сведений не установятся в "Можно писать"

ДЛЯ ИЗМЕНЕНИЯ не годится в этом случае?

управляемый режим давно уже включен, "ДЛЯ ИЗМЕНЕНИЯ" игнорится, наверное можно управляемую блокировку установить, только по таймауту тож легко вылететь Наверное в регистр в ресурс с типом ХранилищеЗначения проще положить саму табличку, спасиб за идею с регистром, ща буду пробовать

Нет, не проще.

При положении в ХЗ пойдет сериализация в XDTO + кодирование в base64, которое, я боюсь, выполнено через опу.. При извлечении из ХЗ пойдет обратный процесс.

почему флаги, а не блокировки?

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

Мало ли.

21-й век на дворе, а все возитесь с таблицами значений? Пригласите специалиста...

А специалист с чем будет возиться?

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

Пишется и читается вне транзакции, блокировки вообще не сработают, плюс (если делать в транзакции) большая вероятность таймаута

"Пишется и читается вне транзакции" Это ты так думаешь.

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

Я думаю -там регистраторов по числу потоков.

накой черт тебе 12 лямов записей?

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

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

Короче, вот тут описано, как это надо делать map/reduce в чистом виде. Иначе ни какого ускорения не получится и вся параллельность будет валиться на блокировках

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

XDTO тут не причем, это другая сериализация)

Да, не получилось в ХранилищеЗначения в рег. сведений поместить, 200 тыс. записей легко прошли сек. за 20, а на 5 млн отвалилось по ошибке потока (

+ через 15 минут отвалилось

Проверял?

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

Угумс. Типы, не имеющие XDTO-сериализации - прекрасно помещаются в хранилище значения. Есть и обратные примеры - когда тип помещается в хранилище, но не имеет XDTO-сериализации. Исследования методом "научного тыка" показали, что, помещение в хранилище значения - эквивалентно ЗначениеВСтрокуВнутр, а не XDTO-сериализации.

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

+ Обратные примеры - когда тип имеет XDTO-сериализацию, но в хранилище значения не помещается. Очепятался

ТЗ имеет XDTO сериализацию.

Многопоточность это вообще сложно. И что? Есть типы, которые ее не имеют - но в хранилище помещаются. И наоборот, есть типы которые не помещаются в хранилище, но пишутся в XDTO

Исследования методом "научного тыка" показали. Что делалось?

вроде как эту штуку пофиксили в 8.3

Вкратце - перебирались почти все типы встроенного языка (вплоть до ОбъектМетаданных, ИсторияРаботыПользователей, РасширенноеИмяXML - и прочего безобразия). Для каждого типа делалась попытка: 1. Поместить в хранилище значения 2. СериализаторXDTO.ЗаписатьXML 3. ЗначениеВСтрокуВнутр Совпадение между 1 и 3 - 100% Между 1 и 2 - сильно меньше

Масштабно, епта. Результаты опубликуй. ТЗ В XDTO есть? Нет? А если найду?!

Если найду - опубликую. Еще выяснилось, что просто ЗаписатьXML - который метод глобального контекста - тоже сильно разнится с СериализаторXDTO.ЗаписатьXML. ТЗ в XDTO есть :) Но это не значит, что помещение в хранилище значения - есть XDTO

ЗаписатьXML - который метод глобального контекста - тоже сильно разнится с СериализаторXDTO.ЗаписатьXML. of course!

Это имеет не очень не много смысла. Подозреваю, что просто ЗаписатьXML от 8.0 остался, пока XDTO не было.

Я через  выгружал в текстовый файл и булками загружал во временную таблицу. Ты случайно с ЗаписатьXDTO  не путаешь?

Дааа, ты чертовски прав.. 1) Создал справочник с реквизитом ХЗ. 2) Выполнил код     "ВЫБРАТЬ ПЕРВЫЕ 10 3) Записал. 4) В SQL -е этот реквизит (image поле) выгрузил в файл. 5) Там даже не в base64, а тупо текст. {0,"Ссылка", {"Pattern", {"L"}, {"#",dd0e8719-5e55-43a0-944a-8321d4c46843} },"Ссылка",25}, {1,"Артикул", {"Pattern", {"S",25,1}, {"L"} },"Артикул",25}, {2,"Весовой", {"Pattern", {"B"}, {"L"} },"Весовой",2} }, {2,3,0,0,1,1,2,2, {1,10, {2,0,3, {"#",dd0e8719-5e55-43a0-944a-8321d4c46843,124:8019001517615d5d11dfdff551bb732a}, Простите за кодировку, было лениво морочиться.

Это печально.

Млядские строки, неужели нельзя в ХЗ сохранять кусок памяти.

Так там не один кусок памяти, а набор объектов (строки ТЗ, колонки) содержащих друг на друга, наверно. Может стоит указать объект СжатиеДанных?

Кстати а как насчет использования ЗаписьFastInfoset

78 Типа такого

Вот тут я конечно тот еще басист - но что-то мне подсказывает, что если просто сохранять кусок памяти - то его потом будет оооочень сложно прочитать следующей версией, когда в плюсовом классе будет изменен состав членов. Например, в той же Java - если сделать implements Serializable и не реализовывать свои writeObject и readObject - то именно так и получится. А если реализовывать writeObject и readObject - то это уже не будет "просто кусок памяти".

Все равно будет строка. В которую будут преобразованы двоичные данные :)

Вы забыли указать степень сжатия при создании хранилища.

Сериализация разная бывает. Есть по аналогии с Базой Данных с разруливанием циклических ссылок. Например

83+

protobuf, как и json - всего-лишь форматы. Ничего нового в такое понятие как сериализация они не приносят. К тому же, даже из вашей ссылки на вики: > По замыслу разработчиков сначала должна быть описана > структура данных, которая затем компилируется в классы, > представляющие эти структуры. Вместе с классами идет код > их сериализации в компактный формат представления. В > дальнейшем используя высокоуровневые языки > программирования такие как Java, C++ или Python > осуществляется чтение и запись данных. > Protocol Buffers не предназначен для чтения пользователем > и представляет собой двоичный формат. Для десериализации > данных необходим отдельный .proto-файл, в котором > определяется формат сообщения. Т.е. опять-таки нет речи о том, чтобы просто взять кусок оперативной памяти и зафигачить в файл (а потом просто прочитать из файла). На основании объекта класса строится DTO-представление, которое уже и пишется файл.

ИМХО - Все намного проще делается. Не лучше все движения запихнуть во временную таблицу с полем порядковый номер. И забирать уже из временной по условию (от 1 до милиона) - первый поток, от милиона+1 до двух милионов - второй поток и тд.

Для этого всего-лишь нужно умудриться передать в другой сеанс менеджер временных таблиц)

Каким же образом из разных сеансов (фоновых заданий) получать временную таблицу созданную в родительском сеансе?

Через хранилище разве нельзя? И Запрос и МВТ

Только не в 8.3

Куски памяти, неважно.

Я не сомневался в тебе. Сжатие данных скорее всего сожмет эту строку deflate-ом.

Если это массив структур то можно взять и кусок памяти, так как они храняться все в одном непрерывном куске. Что касается объектов, то они разбросаны по всей памяти. Таблица типизирована, то можно записывать как в DBF для данных с определенным размером либо указывая размер данных в первых байтах например для строк. Либо записывать в аналог иерархической бд

Я не соглашусь с тобой. Имхается мне, что все объекты в 1С - связные списки (даже массивы и структуры) - нет падения скорости вставки на больших объемах.

Мегазадача... а если попробовать как-то получать из разных сеансов адрес ячеек в ОЗУ, занятых исходной таблицей (которую инициировал родительский сеанс)?

Аххх, если бы узнать адреса объектов 1С... мммм, какие возможности, но. Мечты. мечты.

Есть глобальные временные таблицы Временные таблицы Можно создавать локальные и глобальные временные таблицы.  Локальные временные таблицы видимы только во время текущего сеанса, а глобальные — во всех сеансах. Временные таблицы не подлежат секционированию. Имени локальной временной таблицы должен предшествовать знак номера (#table_name), а имени глобальной временной таблицы — двойной знак номера (##table_name).   Инструкции SQL могут обращаться к временной таблице по заданному в инструкции CREATE TABLE значению аргумента table_name, например: