Оперативная память 1с при сохранении большого числа файлов #808104

Доброго времени суток! 1с 8.2 Ситуация следующая. Есть каталог картинок которые лежат на сервере(jpg).(картинок около 10 000 штук) Есть ссылки на эти картинки в 1с. Необходимо данные картинки по определенному признаку сгруппировать и поместить в общие файлы pdf. (в одном файле пдф будет по 3-6 листов с картинками) Груповую обработку по формированию пдф файлов написал(Создается таб док, в него рисуются картинки с разделителем) но вот не задача... 1С начинает дико жрать память и не высвобождать ее при сохранении каждого отдельного таб документа. Порциями выгружать вообще не вариант.. Кто-нить решал данную проблему с высвобождением памяти?? и как? Благодарю..

не использовать 1с и табличный документ для этих целей.

ТабДок = Неопределено или формирование каждого дока в отдельной функции не спасает? Про управление памятью которую занимает 1с из самой 1с не слышал не разу. И да может иметь смысл.

скорей всего, что не спасает. Как минимум, на прежних релизах платформы такие манипуляции видимого эффекта не давали

не существует у 1с релиза 8.2 есть релиз например 8.2.19.130. Если у релиза есть проблема с утечкой памяти - инфа об этом давно известна. Если это не проблема платформы - значит проблема кода.

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

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

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

Откликаешься на эту вакансию Устраиваешься работать в 1С. Исправляешь баги платформы. Увольняешься из 1С. Профит!

Принудительно программно его нельзя закрыть? Меня очень смущает сей факт, что это не предусмотрено..

нельзя. В классических языках есть отдельное понятие и процедура деструктора объекта, в котором проверяется вся захваченная объектом память и освобождается принудительно. В 1С деструкторов объектам не раскрыли и конструкции ТабДок = Неопределено не являются дестурктором. Чтоб закрылись все созданные явным и неявным образом объекты с владельцем "текущий контекст" должно "закрыться" объект-владелец, например, именно форма, указанная владельцем в создании табличного документа. Если не указан владелец, то даже не знаю, кого нужно будет "закрыть", чтоб произошла очистка памяти без завершения сеанса пользователя, например.

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

в теории, на грани фантастики.- Если данная функция будет вешаться на форму(определенную) А цикл, будет вызывать- открывать/закрывать формы и выполнять алгоритм. В теории это же сработает?)))

(11,12) ТабДок на чем создается? Если это поле самой формы, то я подозреваю, что форму нужно сделать не внутри объекта вида отчет/обработка, а допустим общая форма конфигурации. Подозреваю, что для общих форм вероятно предусмотрели очистку памяти. А если это формы создаются после создания объекта обработка/отчет, то они продолжат существовать в памяти до момента закрытия само объекта-родителя формы. Тут важно понимать, что формы это не совсем объекты.

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

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

13+ скорей всего, что общая форма тоже не является самостоятельным объектом и "привяжется" к контексту того объекта, в котором она открывается

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

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

все верно... не работает через доп форму это решить.

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

ок, допустим есть возможность в упр режиме запустить. и как это реализовать?

Вы говорите, как будто это что-то плохое.

Это вы еще на 32x сидите скорее всего. Добро пожаловать в светлое будущее x64, когда 1Ска ограничивает себя только свободной оперативной памятью:

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

может имеет смысл формировать html и его уже конвертить

Это реальное потребление памяти при печати/просмотре 100500 высококачественных tiff изображений. Как только свободная оперативка подходит к концу - 1С сбрасывает потребленную оперативку.

т.е. в 1С открываем картинку, за ней другую, и так 100500 раз -и получаем ?

Хочу выразить респект. Если раньше, при потреблении больше 1.5 гига изображения иногда проскакивали неотрисованными/неотпечатанными, то теперь такой фигни нет. Все хорошо в x64.

Да, все так.

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

вопрос решен.. Развернут сервак с 128гб оперативки)))