Имеем риб с 10 узлами. Блокировки при получение в цб.
В основном документы которые делают движения в рс.
Как победить? идее?

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

(0) Разнесите время загрузки, чтобы в ЦБ не работали одновременно несколько обменов. А если все-равно долго делается, значит сервер с ЦБ слабоват

Еще можно уменьшить количество объектов в пачке, то есть в файле обмена.

(0) о, я помню работал в базе где было порядка 50 узлов. Приходилось извращаться. даже свой обмен писать. так что ваши 10 - семечки.
по сути в чем проблема? В номерах сообщений.
Можно ж просто прочитать файл загрузки, а потом программно передвинуть номера сообщений.
Правда, давно дело было (2014), уже все забыто... Но если покопаться, могу поискать код.

4) а еще помнится как ты сюда прибегал, изобретя грабли, и недоумевал а чего данные не синхронизированы

(5) ну я практик, в отличии от теоретиков, могу ошибаться.

вот зачем они так.

Функция ДанныеСоответствуютФильтруПравилРегистрации(ЭлементДанных, Знач Получатель)

Из за этой хрени. все объекты в регистрации ломились в другие узлы и смотрели или он действительно должен выгружаться. и еще где то есть приколы.
Мы не могли понять что ждет обмен. а он каждый объект проверял на соотвествие. Если в обмене до 1к то пофиг. типа не заметно. а вот у нас форс мажор. по 30к на узел и вот привет. 1 обмен на узел шел 6 часов. убрав эту хрень 2 часа. это то что сразу выявили. а что еще оптмального есть в ут 10 у нас БАС ут. пипец замутили БСП

(7) блокировки были из за парарельной работы фоновых на узел и к обращению этой хрени. наложение на измненения объектов в узлах.

(7) вообще какого х. там идем все по плану регистрации. файлик есть) не ... проверяем. что ? потом еще проверки всякие. зачем все так сложно. блин.  сейчас вот грузим данные у нас где то 600к объектов к обмену. 40 пролезло за 2 часа в узел. если все 10 узлов то падает сервер. забивает запросами проверки к субд и не отпускает данными. 250 гб отжирал. Вот что делать то. а если 10 кк. вопрос же типового решения УТ ) капец

(9)Вот что делать то. а если 10 кк. вопрос же типового решения УТ ) капец
Если у вас к обмену по 10млн объектов, то очевидно типовой обмен вам не подходит. Можно попробовать писать напрямую в SQL справочники и документы BULK вставками а движения догружать когда база свободна кусками по 200-300 записей.

вот тут http://catalog.mista.ru/1c/articles/1216620/ товарищи машут миллионами записей в оперативном режиме каждый день

почему нельзя типовое ? где написано что оно не может работать при таком объеме ?

(12) у нас проблема и про 40к. из за проверок на проверках. когда 50к выгружало 6 часов. после нахождения одной проверки за 2 часа. на тесте 40 минут. если выгружать этот же массив не через риб. сцу... 9 минут. что за чмд

(13) ищем проблему в космосе. проблема в 1с. да была разница амд и интел. но блин.

(10) без вихи sql, как в 1с

(12)где написано что оно не может работать при таком объеме ?
Так в (0) и в (7) же написано, что не работает и в (9) написано, что надо предусмотреть когда будут объемы в 20 раз больше

(16) В 0 написано что работает. Никто не говорил что обмен будет укладываться в 2 секунды.

(17)Ну раз все работает... то можно закрывать тему

(18) Ну так вопрос в том и состоит как ускорить процесс работы

(19) + что бы возможно не упало когда прийдет много чего

(18) работает. на сейчас. вот сейчас уже загрузил 150к объектов. еще гружу будет от 600к. как их спустить ниже. времени не более 2-4 часов.

а почему так много? 600к это очень много объектов. мне кажется надо проверить логику, что должно включаться в обмены, как часто и куда ехать.
слабо верится что такое количество данных реально вводится для регулярного обмена.

(22) допустим заказ на 300 позиций. +характеристики+ единицы измерения + коэффициенты . итого- один док тащит на обмен 1,5к объектов.