Заметил что в 1с8 криво работает с оперативной памятью. Например в памяти ТаблицаЗначений на 20000 записей. ТабЗнач.Очистить() не приводит к освобождению памяти. И создание объекта заново ТабЗнач = Новый ТаблицаЗначений, тоже не освобождает память. Что делать?

а разве она сразу должна освободиться?

да и вообще, как ты увидишь что она занята?

ТабЗнач = неопределено;

Кто сказал, что в 1С есть сборщик мусора?

Пля ну и название темы... Зашел только из-за этого )

Судя по тому, что 1С-ке монопенисуально наличия netframework - она не юзает мелкософтовский GC.

Может свой сборщик, а может тупо - убил - освободил.

Сборщик по любому есть в 1с, память ведь должна как то освобождаться.
Не понял причем тут netframework на нем не программил.
Вопрос в следующем как освободить память занимаемую таблицей значений?

Я вижу что она занята в диспетчере задач windows.

(8) неправильный критерий

А правильный ответ был дан на первой минуте...

Всегда найдется десяток клоунов которые ответят не в тему. Если не хватает внимания общайтесь в чатах. Нечего создавать помойку из серьезных тем.

ТаблицаЗначений = Неопределено ?

(0) что в таблице?

(11) Дятел, присваивание значения "неопределено" - универсальный деструктор снеговика.

(11) Ответ на Ваш вопрос, мой твердолобый друг, был Вам любезно представлен в (4). Здесь собравшиеся наверняка оценили Ваши природную скромность и чувство такта, когда Вы благодарно назвали их клоунами в ответ.
В 1С нет сборщика мусора, уважаемый, там лишь счетчики ссылок на объекты. Достаточно, или будете стучать клювом дальше?

Пару раз в неделю сборщик мусора заглядывает в мой кабинет.Но он не из 1с точно.

ТаблизаЗначений = Неопределено не освобождает память. Во всяком случае в моем случае. В Таблице значений находятся остатки из регистра сведений (Пишу свертку базы с переносом остатков через COM/OLE).

Лирическое отступление для твердолобых:
Уважаемый  БалбесВ1с почитал темы созданные вами на форуме они мне показались тоже очень смешными, однако я не зашел в каждую и не поглумился над вами.
Просто за... флудеры на форумах. Как я уже сказал выше не хватает общения общайтесь в чатах. Из 16 ответов в тему только
2-3.

По всем регистрам остатки перенес, застрял на одном СкидкиИНаценкиНоменклатуры вот для него то и не хватает памяти

(18) Делай частями, не ошибешься ;)

(17) Для оси - не освобождает, а вот для самой 1Сины еще как освобождает. Кстати OLE-какашка жрет памяти точно больше, чем ТЗ на 20000 записей.

Я и делаю частями.

(0) >Что делать?
для начала покурить "область видимости переменных"...

Делаю так:
1.Запрос к оле базе
2.Выгружаю в ТабЗначOLE
3.Создаю ТабЗнач и конвертирую Олешную таблицу значение в ТабЗнач текущей базы.
4. Когда количество записей привышает 10000-20000 тыщ (устанавливается). Очищаю ТабЗнач (ТабЗнач = Неопределено типа чтобы освободить память) и продалжаю процесс.

Насколько я понимаю 1с освобождает память объектов только после завершения процедуры в которой они созданы.

(24) Покури в гугле аллокаторы. может просветление и наступит.

(24) да не освобождает она память для WINDOWS. Она в своих внутренних таблицах освобождает. Так что в диспетчере задач смотреть глупо.

(17)То что в (16)называется ап.И кстати твердолобым обозвали тебя в (15).

(26) освобождает...

Мне то не легче от того что 1с освобождает в своих внутренних таблицах. У меня оперативки не хватает.

(0) ну вроде как сборщик мусора не интерактивно работает а типа по расписанию, типа раз в 1 мин что-ли... нужно уточнить в первоисточниках...

(29) а сколько памяти-то?

У меня 4гб памяти, но это не важно ибо я делаю по частям.

Автор олень. В 1С нет сборщика мусора. Память освобождать не нужно. Если руки чешутся заниматься сбором мусора нужно было выбирать себе другое направление работы.

сборщик мусора безусловно там есть, но как он устроен - подозреваю даже в 1С не скажут

(33) сам ты олень

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

(32) хоть 32 гб. вынь проге выделяет 2гб, все остальное свап, и кривизна архитектуры.

Вот он зловредный код:    
   СчетчикСтрок = 0;
       Для каждого СтрТабДвиж из ТабДвижOLE Цикл
           СчетчикСтрок = СчетчикСтрок + 1;
           НоваяСтрока = ТабДвиж.Добавить();
           Для каждого КолонкаТабДвижИз из ТабДвижOLE.Колонки Цикл
               ИмяТекКолонки = КолонкаТабДвижИз.Имя;
               ЗначПер = СтрТабДвиж[ИмяТекКолонки];
               НоваяСтрока[ИмяТекКолонки] = НайтиОбъектCOMвБазе(ЗначПер);
           КонецЦикла;
         
           
           //ЗаполнитьСопоставитьТабДвижOLE(ТабДвижOLE, ТабДвиж);
           Если СчетчикСтрок >= МаксКолСтрок и МаксКолСтрок<>0 Тогда
//Здесь создается документ ввода остатков
.....
//
//ТабДвиж.Очистить();
               ТабДвиж = Неопределено;
               ТабДвиж = Новый ТаблицаЗначений;
               Для каждого КолонкаТабДвижOLE из ТабДвижOLE.Колонки Цикл
                   ТабДвиж.Колонки.Добавить(КолонкаТабДвижOLE.Имя);
               КонецЦикла;
               СчетчикСтрок = 0;
           КонецЕсли;
       КонецЦикла;

Как вариант...
Не просто ТЗ = Неопределено, а перебрать каждую строку и каждому объекту = Неопределено, потом удалить строки, потом и таблицу...

Помнится, в 77 мне такой фокус помогал...

(23) рассматривал вариант не выгружать в тз, а использовать выборку?
я таким образом когда-то победил обработку выгрузки в битрикс, на больших объемах там тоже памяти не хватало

(39) Проверил не помогло.

(37) 1С может и 3 Гб слопать при соответствующем ключике в boot.ini

*Сидит и радуется, что не поленился изучить конвертацию данных*

(38) епта... намекаю последний раз: см. (22)...

(43) Кто сидит? Впрочем, конвертация тоже падает из-за недостатка памяти.

Про OLE надо говорить отдельно.
Умная система Windows для каждого OLE-объекта создаёт сервер, если, конечно, не сказано, что сервер может обслуживать несколько объектов сразу.
Если у нас сервер живёт в своём процессе, как это происходит в 1С, то между процессами устанавливается взаимодействие, через которое передаются данные объектов. Точнее, передаются "указатели" по которым эти объекты можно найти, так как сами объекты остаются внутри своего процесса. За передачу отвечает интерфейс IMarshal, который определяет, как и что переносить.
Далее, когда в клиентском приложении будет создано много объектов из сервера, находящегося в другом процессе, то создаются заглушки, которые живут какое-то время после того, как их освободят, так как всю информацию об освобождении объектов нужно доставить родному процессу.
То есть в вашем случае вы создаёте таблицу с "заглушками". После освобождения таблицы эти заглушки переходят в состояние обнулённого счётчика ссылок и готовы умереть.
Точнее, из-за оптимизации они попадают в "свободный пул", то есть будут выданы другому OLE-объекту.
Далее, родной для объекта процесс получает уведомление о том, что его объекты другому процессу не нужны, и должен их разрушить, но, если они используются ещё и внутри его самого, то они останутся жить - вероятно, что по этой же причине могут остаться жить и "звглушки" в памяти нашего процесса, чтобы не выполнять "стыковку" ещё раз.
И ещё, вся эта вещь общается через Remore Procedure Call и сообщение Windows WM_COPYDATA, причём большой объём данных может передаваться в одном сообщении, и когда ему просто нет места в адресном пространстве другого процесса (а для этого его не обязательно занимать всё, а можно только сильно фрагментировать), то получаем ошибку.
Поэтому, лучше получать как можно меньше объектов OLE из другого процесса, а вместо них обмениваться строками и массивами малой размерности, чтобы им место находилось всегда.

(44) епта а зачем намекать, мы что тут в загадки играем?

(47) ты можешь сказать какая область видимости ТабДвижOLE и ТабДвиж в (38)? я не могу...

+(48) и кто из нас загадки загадывает?

(46) Это не относится к моей проблеме как мне кажется. Т.к. у меня выполняется запрос к базе OLE Затем выгружается результат запроса в таблицу значений и эта таблица не жрет много памяти. Память начинает улетучиваться когда я заполняю таблицу значений в рабочей базе, объектами же рабочей базы. Но мне не понятно почему ТЗ с оле объектами не жрет память, а таблица с объектами рабочей базы полностью идентичная с тем же кол-вом строк и колоно жрет.

(48) Область видимости ТабДвижOLE и ТабДвиж в приделах процедуры кусок которой я привел в (38)

Может память занимает не ТабДвиж, а что то другое?

(51) ну тогда память, занятая ТабДвиж должна освобождаться при завершении этой процедуры...

(53) Проблема в том что память заканчивается раньше чем эта процедура :)

(54) ну дык дроби данные...

Код выполняешь с закомменченной
ЗаполнитьСопоставитьТабДвижOLE(ТабДвижOLE, ТабДвиж);

??

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

(56) ДА

Тогда код процедуры
НайтиОбъектCOMвБазе()

в студию!

может ОФФ.
в 77 для обработок замечал, что память в диспетчере освобождается только при убиении обработки.
использует ли сам 1С "высвобожденную" память - хз.

в запросе - освобождает, если УДАЛИТЬ ВременнаяТаблица; делать, в коде - кажись по окончанию процедуры и перед возвратом в интерактивный режим

(57) в таблице ссылки

Код функции НайтиОбъектCOMвБазе(ЗначComПер)

Функция НайтиОбъектCOMвБазе(ЗначComПер)
   //Определяем тип переменной
   ТипНашейПеременной = ОпределитьТипComОбъекта(ЗначComПер);
   ТипыСправочников = Справочники.ТипВсеСсылки();
   ТипыДокументов = Документы.ТипВсеСсылки();
   ТипыПеречисления = Перечисления.ТипВсеСсылки();
   Если ТипНашейПеременной = ТипЗнч(Неопределено) Тогда   //неопределенный тип
       Возврат  Неопределено;
   ИначеЕсли ТипыПеречисления.СодержитТип(ТипНашейПеременной) Тогда    //пречисление        
       ИмяПер = ЗначComПер.Метаданные().Имя;
       ИмяЗначенияПер = OLEСоединение.XMLСтрока(ЗначComПер);
       //Сообщить(ИмяПер+":"+ИмяЗначенияПер);
       Если ИмяЗначенияПер<>"" Тогда
           Возврат  Перечисления[ИмяПер][ИмяЗначенияПер];
       Иначе
           Возврат  Перечисления[ИмяПер].ПустаяСсылка();
       КонецЕсли;
   ИначеЕсли ТипыСправочников.СодержитТип(ТипНашейПеременной) Тогда    //Справочник
       УИД = Новый УникальныйИдентификатор(OLEСоединение.XMLСтрока(ЗначComПер.УникальныйИдентификатор()));
       Возврат  Справочники[ЗначComПер.Метаданные().Имя].ПолучитьСсылку(УИД);
   ИначеЕсли ТипыДокументов.СодержитТип(ТипНашейПеременной) Тогда  //Документ
       УИД = Новый УникальныйИдентификатор(OLEСоединение.XMLСтрока(ЗначComПер.УникальныйИдентификатор()));
       Возврат  Документы[ЗначComПер.Метаданные().Имя].ПолучитьСсылку(УИД);
   Иначе  //не ссылочный тип
       Возврат  ЗначComПер;  
   КонецЕсли;
КонецФункции

Иначе  //не ссылочный тип

       Возврат  ЗначComПер;  

100% уверенности что примитивное значение вернется?

//Здесь создается документ ввода остатков

.....
//

//ТабДвиж.Очистить();

               ТабДвиж = Неопределено;
               ТабДвиж = Новый ТаблицаЗначений;

ИМХО неопределено не поможет, переназови по другому ТабДжиж2 например :)

               Для каждого КолонкаТабДвижOLE из ТабДвижOLE.Колонки Цикл
                   ТабДвиж.Колонки.Добавить(КолонкаТабДвижOLE.Имя);
               КонецЦикла;
               СчетчикСтрок = 0;
           КонецЕсли;
       КонецЦикла;

(64) да, проверено

Проблема не решена... Есть умные мысли?

(67) написать алгоритм так, чтобы он не жрал столько памяти

(68) Тоже об этом думаю. Только еще не придумал как.

(67) Если не хватает чуть-чуть - то ключик /3GB в boot.ini поставить. Если не пройдет - то разбить выгрузку на части и грузить по частям, перезапуская 1С после загрузки каждой части.

(68) Увы, память жрет 1С, а не алгоритм.

Вопрос: когда заканчивается память? На второй итерации по ограничению количества строк? Другими словами: сколько документов ввода остатков успевает оформиться до окончания памяти, соответственно сколько раз успевает отработать это место:
ТабДвиж = Неопределено;
ТабДвиж = Новый ТаблицаЗначений;
?

(0) юзай КД, не изобретай волсопедов

(72) КД также валится, причем на не самых больших базах.

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

В результате обсуждаемого алгоритма по сути дела одни и те же данные хранятся в памяти 4х экземплярах - не эффективно.

(70) [память жрет 1С, а не алгоритм] — восхитительно! Напиши в рамочку и повесть на стенку, чтобы все видели твою неспособность думать

(71) В зависимости от ограничение которое я задаю, если 10000 то раз 5 успевает выполнится

(74) Какие данные хранятся в 4х экземплярах в моем алгоритме?
Что ТЗ хранит данные в памяти это и ежу понятно. Не понятно почему память не освобождается когда уничтожается объект ТЗ.

Я не понимаю почему полная ОЛЕ ТЗ с сылками ОЛЕ умещается в памяти, а когда я ее преобразую в ТЗ текущей базы  с ссылками на объекты текущей базы, она раздувается в памяти больше чем в 10 раз??? Где ошибка в алгоритме?

"ААПП!!! и тигры у ног моих сели"
:)

(0) заметил, что ты криво работаешь с возможностями платформы 1с8.

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

(79) если знаток, по подскажи как надо.

(80) Батенька, надо запросами и времеными таблицами.

+(81) Запомни, основной способ получения выборки информации на платформе 8 - это запрос.

(82) посмотри еще раз (23).

Зачем вообще создавать таблицу в своей базе? Сразу нельзя писать документы, обрабатывая ОЛЕ таблицу?

(83) продалжай процесс

(85) ниумею.

Почитай про менеджеры памяти для нативного кода. Кроме того бывает зарезервированная и откомиченная память. А также память в нативных (да и в управляемых для LOH) подвергается фрагментации

Попробуй убивать в отдельной процедуре. Как-то так:

Процедура УбитьОбъект(Объект)
   Объект = Неопределено;
КонецПроцедуры

А вообще настрой технологический журнал на утечки памяти.

Переписал код без использования таблиц значений. Память не жрется, фсе формируется. Сначала переписал без использования промежуточной таблицы значений, все равно была утечка памяти. Сделал вывод что нельзя использовать ОЛЕ таблицы значений типа: ТабДвижOLE = OLEСоединение.NewObject("ТаблицаЗначений");

Всем спасибо!

(89) не, там дело в том, что если есть результат запроса - то обходить его оптимальнее не через выгрузку в ТЗ, а через выборку из результата

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

(89) Возможно проблема с подсчетом ссылок. Такая проблема была еще в семерке. Кстати а работаешь через V82.Application или v82.COMConnector

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

Что касается OLE-конструкций, то они в процессе создания имеют один объём (уникальная ссылка на сам объект для интерфейса IMarshal), а в процессе работы с ними просто "обрастают подробностями", то есть добавляются ссылки для методов и параметров и т.п. - память теряется.
То есть вполне вероятно, что когда ты создаёшь объекты, то они в память влазят, а когда каждый объект подключает свои методы (в 1С позднее связывание), то память кончается.

вот еще по теме:
Глюк в 1С 8 с зависанием обработки в памяти (не обновляется код)
http://infostart.ru/public/89283/

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

(93) У меня 8.1

Ну тогда V81.Application или v81.COMConnector

(97) Была такая же проблема с нехваткой памяти при переходе на новую версию конфигурации.

Может не в тему, но интересно самому чем это закончится !

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

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

100!

(98) COMObject("V81.COMConnector");