Не хватает памяти при обмене данными через план обмена #351947

Проблема следующая, используем планы обмена, УПП, главная-периферийная база (ПБ), при загрузке пакета обмена в ПБ выдается сообщение об ошибке - "Недостаточно памяти на сервере", это если в клиент-серверном варианте, в файловом примерно тоже самое "Не достаточно памяти". Пакет обмена довольно большой - 3 гига, закрытие месяца, там всегда здоровенные пакеты обмена получаются, но бывали и больше пакеты! по 5 гигов, да долго грузится, но в итоге принимался, без ошибок. А сейчас ниодна ПБ не может принять выгрузку из центра. Пробовал выставлять различные ограничения на количество объектов фиксируемых в транзакции - не помогает, та же самая ошибка, в журнале регистраций пытался отследить на чем именно спотыкается - закономерности нет, на разных объектах. Кто нибудь сталкивался?

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

вернее без попытка исключение

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

а на диске цэ места достаточно? а то у меня из-за этого периодически пролемы возникали... (вернее на диске с %TEMP%)

попробуй вынести обработку во внешний отчет и где межде загрузкой стоит Попытка . . Исключение КонецПопытки эти 3 строки убрать

но есть одно, но если так получится, то только не специалисту лучше не доверять это делать, а то вдруг не загрузится

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

между Исключение . . . КонецПопытки тоже убери все

хотя вроде их там нет

тогда единственно что могу посоветовать проверять место на диске когда идет обработка, если на диске место стремится к 0, то надо его увеличить

ЫЫЫЫ это понятно почему у тебя видимо большие наборы записи под документом закрытия месяца и такой набор создает при обработке подобный эффект. опыт показывает что для падежа достаточно 50 тыс движений по регистру. Есть простое решение создать штатный док с кучей проводок а потом перевесить эти проводки на отдельные доки частями по неболее 10 тыс штук. Такие порции безопасны для 1с

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

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

жесть! В качестве апа. А сами базы, если выгрузить? выгружаются? или с ошибкой валятся? Конфа на поддержке, или на поддержке с возможностью изменения?

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

(Пакет обмена довольно большой - 3 гига) - это в несжатом виде? Т.е закрытие месяца делается в ЦБ, передается в ПБ, и там загружается? т.образом, при проведении в ЦБ документ регистрица во все узлы ПБ разом, или нет? Еще важный вопрос, обмен через FTP, файло или почту?

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

в несжатом, в зипе порядка 50 метров, закрытие делается в ЦБ и регица для 3х переферийных баз, обмен через файло

16, 1. "конфа на поддержке с возможностью изменения" первый косяк может быть тут. там  в одной из таблиц (config) есть строка с безумным размером, который не  переваривается. Мы сняли с поддержки, тем более что вернуть на поддержку всегда можно. Каким чудом это может влиять - ИксЗед. 2. Проводок при закрытии месяца очень много. Факт, особенно в налог учете. Попробуй убить регистрацию изменений у проведенного дока, потом регистрировать порциями, и передавать в ПБ.

19, Сколько по времени проводица док ЗМ? ?

50 метров - жесть! 15 мегов загужается из ПБ в ЦБ полдня.... В качестве бреда: может попробовать на уровне sql сервера.., в одном select в другом insert, потом пересчет итогов.

Закрытие месяца не один док, это несколько видов документов, один из которых, самый "толстый" Расчет себестоимости выпуска, проводится он не так уж и долго, минут 25, остальные документы проводятся пакетно минут за 10, так что в целом закрытие месяца достаточно быстрый процесс...раньше сжатые пакеты размером 40-50 метров грузились часа 2-2.5...Тоже уже решили выгружать по частям, отменили регистрацию для части документов, будем их регить и выгружать по частям, осложняется все тем что выгрузка долго делается...на крайний случай всегда есть возможность создать начальные образы, так как базы идентичные...вот только хочется выяснить в чем дело, чтобы опять на грабли не наступать

23, ясно, у нас просто БП, там один документ ЗМ. Еще есть идея попробовать, перед загрузкой отключить использование итогов, после загрузки включить(и как следствие пересчет итогов....) Удачи.