Как это, память не должна освобождаться? Оно не на первой итерации падает. А поработает несколько раз и укладывается.

а почему она должна освобождаться?

она потом переиспользуется

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

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

Это не рабочая система, это специальная база, которая делает только это. Эксперименты проведены неоднократно. На сервере дофига памяти, падает оно и у меня локально на платформе x32, и на сервере x32.

Как доходит до предела памяти на процесс, так и падает

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

Это не гадания. Это факт. Когда была добавлена принудительная очистка переменных, добавлены методы очистки результата поиска узлов в дереве, тогда стало падать не через три раза, а через четыре. После завершения работы скрипта, где-то накапливаются данные. Но где непонятно. Потому что никакого сохранения результата кроме как записи в регистр нет.

" результата поиска узлов в дереве"
знач не xpath. Перечитайте еще раз что я писал выше, а потом еще раз и еще раз, а вот когда надоест, возьмите и попробуйте через xpath

Хорошо, пускай xpath волшебный. Сейчас я использую найтиПоФильтру. Но что это меняет? Если мой код завершил работу, я ожидаю что у меня все значения содержащиеся в переменных очистятся, а если что-то сохраняется в сеансовых данных то оно убъется после завершения сеанса фонового задания, разве не так?

А почему вы ожидаете такое поведение от платформы (то что память должна освободится)?
Я помню на сдаче экзамена Морозову зашла тема про GC, на что он сказал "в платформе нет GC", я склонен ему верить т.к. он тесно взаимодействует по своей работе с ребятами которые пилят платформу, если вы найдёте пруфы где говорится, что в платформе есть gc, прошу поделиться. А раз нет gc, то почему вы ожидаете такое поведение? Кстати, то что память занятая не очищается легко проверяется.
Как на самом деле платформа распоряжается памятью знают только разработчики платформы, но то что она вполне себе может не освоить память ничего удивительного

Я чёт несколько не уловил связь с ГЦ, ну вот допустим у меня серверный вызов, он отожрал 200мб памяти, по окончанию вызова память должна таки вернутся для переиспользования кластером (не в винду, но в доступную для кластера), если память остаётся занятой под что-то что было в уже завершенном серверном вызове и фактически недостижима то это прям конкретная утечка в платформе.

мы вправе ожидать, что в платформе нет утечек памяти... но её тоже люди пишут... причём на С++, да ещё 10 млн++ строчек кода... не удивительно, что там кто-то где-то может недосмотреть...
Кстати, интересно, все завершившиеся фоновые задания остаются в менеджере фоновых заданий и если их сильно много, то это тоже прилично память будет жрать... а метода Удалить у менеджера вроде нет (я на 13-й платформе ещё сижу, может уже сделали?)...

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

Утро доброе, кто-то уже пробовал использовать "Сервис Интеграции" от 1С?

А её уже выпустили в народ? Или всё ещё бета тест и пишите письма?

ну в 8.3.19 я увидел ее в списке объектов конфигурации

https://nometa.xyz

вопрос-то в чем?

оно там с 8.3.17