В результате мощной обработки (400 000 строк) 1С в памяти отожралась с 1.5 гига до 5 гиг оперативки.

И продолжает с таким же размером висеть после закрытия обработки. В чем прикол?

Ох нифига себе прикол!

В диспетчере.

У меня была запущена 1С. И я ее не закрывал!

Запустил один раз обработку (как писал сожрала 5 гиг). закрыл обработку, 1С осталась. И решил заново запустить.

А в диспетчере появился второй экземляр 1С (хотя фактически всего 1) и тоже начала сейчас сжирать 5 гиг.....

Чота я не понял юмора это как так. 1С кстати файлов....

Запущена одна, а в оперативке отобраэается 2. И обе по 5 гиг сожрали.

Сейчас ради прикола еще третий раз запущу.

Единственным благом является знание, а единственным злом – невежество.

(0) сегодня обрабатывал 30 000 000 строк.
память не отожралась.
После закрытия обработки 20 ГБ, которые она съела - очистились.
Ищи проблему в коде)

Третий раз не появилась. Но в диспетчере отображаются 2 запущенных 1С по 10 гиг.
Хотя открыта фактически одна.

(3) голову сломал. не могу найти хоть тресни.

Работает быстро. 400к строк обрабатывается всего 30 секунд.
И другие вещи тоже вообще за секунды.

Но память отпускать не хочет. И еще как то баг что две 1С.

Пипец. заработался. я две запустил)))) сорян.

Лдано короче. 5 гиг фигня. На таком обьеме обработки. Позапускал еще. Больше 5 не жрет. На файловой.

После закрытия отпускать память не хочет. Фиг с ним.

вообще-то от релиза платформы зависит. Т.е. на некоторых ситуация совсем невыносимая, а на некоторых терпимее.

Но на всех в 1С уборкой мусора в памяти дела обстоят плохо. И никогда не было и видимо не будет явных деструкторов объектов. Хотя в Си, на котором собственно и разработана платформа, эти самые деструкторы в наличии.

(9) упрутся в производительность-будут

(10) Один и тот же код, выполняемый в 1С, примерно в 12 раз медленнее выполняемого на Java

Что-то кэширует, а сборщик мусора отдыхает )

Если обработка использует память в больших объёмах, то нужно при написании освобождать по мере отпадания потребности: ДофигаПамяти = Неопределено;

(11) Как мне дир говорил,

база начала откликаться в 3 раза медленнее, мы росли на 30% в год, потом отклик с секунды ушел за 3, и компания удвоилась, думаю что будет если остановить ее нахрен ;-)

(0)Небось какой-ть объект не убил, вот он в памяти и остался.

В общем из огромного кода мне стало доподленно известно что память сжирается в результате заполнения ТЧ обработки.

Выявил это путем комментирования участка кода где она заполняется.

Прикол в том что она заполняется из такой же ТЗ (которая висит в хранилище), такого же размера строк.

Те занимает память именно ТЧ обработки. При закрытии обработки память не чистится. Хотя ТЧ является реквизитом.

(0) 400 000 строк кода?

(9) уже лет 20 смарт-поинтеры используются. И это С++, а не С.

(16) кто тебе сказал, что в хранилище (даже без сжатия) и в памяти будет занимать одинаковое место, сам придумал или подсказал кто-то?

(9) раз в 20 мин приходит мусорщик и кэш шринкуется

Причем прикол в том что я даже убрал данные это ТЧ - просто создание пустых строк.


Сейчас ради прикода просто создам пустую обработку с ТЧ и сгенерирую в ней 500к строк. гляну как память жрать будет

Блин пацаны ну это бред чтобы ТЧ в сотни тысяч строку (даже пустая) жрала 3 гига оперативки.

Хахах. Ля прикол...

Создал обработку с нуля. 30 строк кода. Обработку с ТЧ и создал процедуру в 10 строк генерирующую там указанное количество строк.

И что вы думаете. Жрет память)

Сейчас закрою ее. И подожду 20-30 минут.

(22) значит, механизм ТЧ в памяти, который сделан для отчетов и обработок, не рассчитан на большое к-во данных. Попробуйте ТЗ или еще что-то.

Если завести ТЗ на сервере и засрать ее таким же количеством строк - расход тот же?

(25) фигово как то с ТЗ формы. совсем не подходит. тут вариант может быть пробовать Табличный документ и через него работать.

(26) я ее и делаю на сервере. в модуле обработки идет заполнение.

(23) всего 2 варианта: либо после обработки происходит какая-то транзакция в бд, в результате чего и отжирается память, либо твой запрос на 3 строчки раскладывается в кластере на 3 страницы, захватывая для чтения всю бд и в плане запроса в профайлере в нем куча строк. Но это для скульных баз. У тебя такая?

Количество реквизитов не имеет значения. В моей десятки самых разны (есть и неограниченной длины).

В пустой обработке я сделал всего два со строкой длинной 10. Память жрется даже если не заполнять реквизиты, просто пустые строки.

А вот ПРИКОЛ. поставил сделать 99 999 строк. Заполнились за 1 секунду и памяти выросло всего 30 мегабайт.

Скорее всего работа с этими ТЧ внутри 1С сделана без учета того, что кто-то будет туда пихать сотни тысяч строк. По идее, что можно хранить в ТЧ обработки? Ну настройки какие-нибудь переменной длины, это десятки строк, ну сотни максимум. Полагаю, примерно так они и думали.

Бред. Меняю количество генерируемых строк. Уже не жрет.

Сейчас пытаюсь тестить на добавленных реквизитах. Все таки зависимость есть.

(33) ну резонно. Меняй в сторону уменьшения самих реквизитов, их количества и колоичества строк - и жрать перестанет :)

(32) я тестирую на на 99 999, 200 000, 400 000. Случайно поставил 4 миллиона даже.

Есть зависимость от количества реквизитов которые даже не заполняю.

Сделал ТЗ формы - ничего не жрет.
Сделал ТЗ в коде (через переменную) - ничего не жрет.

КОроче. нафуй......

То жрет то не жрет. И таблица формы уже начала жрать как только реквизиты добавил. и ТЧ жрет. Все жрет.

Зависимость от реквизитов есть. Причем даже если их не заполняем.

Видимо все таки таблица растет и все реквизиты что в ней ее раздувают, даже если пустые.

Нифига не понятно только почему 1С на такую хрень гигабайты тратит.

Работает все быстро. И 400к строк в принципе за секунды создается. Но память убивается.