Добрый день! Есть база на семерке, в которой запускается тяжелая обработка. Когда процесс 1С занимает больше 1.5 Гб памяти, происходит вылет с ошибкой "Out of memory". Насколько я знаю, 32х разрядные процессы не могут занимать больше 2Гб оперативной памяти. Подскажите, существует ли способ решения данной проблемы (без перехода на 8 :))?

Можно для начала оптимизировать "тяжелую обработку"

Переделать тяжёлую обработку - не предлагать?

Сделать легкую обработку вместо тяжелой.

(1)(2)(3) вы на г.р. ТС посмотрите, и вопросы отпадут....

(4) +1!

(4) Не все 86 одинаково бесполезны. Я знаю как минимум 2х, которые мне (!!!) дадут фору во многом... Причём одна из них - женщина

(6) я был о тебе более высокого мнения

(7) Ну извини, что разочаровал... Пойду убъю себя...

(8) стой! не убивай! я пошутил

(0) что делает "тяжелая обработка"? Попробуй вариант разделения на несколько.
Сверни базу, если позволяет религия заказчика.
(4) на очень хорошая шутка, можно подумать, что некоторые сразу родились гениями от программирования

(10) конечно

(10) >> можно подумать, что некоторые сразу родились гениями от программирования

Увы, это так...

"Пригласите специалиста" было ?

(0)
1. чисти неиспользуемые переменные (особливо крупные ТЗ)
2. не тащи на клиента сто тыщ мульонов строк - сворачивай в запросе
3. если работаешь с xml - либо дроби наборы данныз на более мелкие, либо переходи на ole (если КД)

(14) Как нетащить на клиента мульоны строк , в семерке все тащится в клиента.

(15) не звезди

(0) да.

(4) При чем тут год рождения, может у человека задача такая, что действительно памяти не хватает. У меня тоже была подобная задача: нужно было автоматически создавать документ и заполнять его, падал на ~6000 строк с такой же проблемой. Пришлось автоматом разбивать на 3 дока, чтобы все влезло.
P.S. Сам тоже 86 года.

(17) Если не трудно, кинь ссылку куда копать.

(18) >падал на ~6000 строк

бггг. Вот когда падает на over 180 тыс строк, тогда нужно задумываться над бренностью бытия.

(0) тяжелая обработка тяжело обрабатывает тяжелые данные? Там поди и создание объектов в цикле есть, и переливка ТЗ в ТЗ?

Обработка грузит из Excel данные и заполняет ТЗ. Потом их обрабатывает. Все это время ТЗ нужно держать в памяти. Вопрос стоял не в том, как оптимизировать обработку. А в том, есть ли средство от ограничения в 1.5Гб под процесс 1С.

(18) всегда чего-то не хватает: памяти, времени, денег...
нужно уметь рационально использовать доступные ресурсы...
а год рождения.... ну ЧАЭС взорвалась, и у многих этого года рождения возникли дефекты в ДНК. некоторые - с уклоном в гениальность, но бОльшая часть - с уклоном в дебилизм.

(21)" Все это время ТЗ нужно держать в памяти"
Как вариант - сделай служебный документ для этой обработки и держи информацию в ТЧ.

(23) Справочник служебный

типизация колонок тоже помогает сократить память

(21) перестраивай алгоритм обработки, напиши VBA скрипт для подготовки данных из Exel и просто грузи данные не анализируя.
В (23) то же хороший вариант.

(23)(24)  а также dbf-файл, таблица на сервере и т.п.
(25) и это тоже.

(26) В 23 совет плохой с ТЧ документа

(21) Средств снять ограничения по памяти на 32-битный процесс нету , разве что попросить фирму 1С специально для тебя скомпилировать 77 в 64 бита.

(28) если строк данных меньше 9999, то подойдёт. Реализация через справочник примерно на том-же уровне проблемности реализации.

(30) Не в строках дело, а в том что при использовании документа лочится 1СЖурнал. Ляжет проведение других документов пока у него этот гипопотам ворочается.

(21) см 29.

(31) залочится он только на момент создания нового (ну или запись-проведение). но записывать или проводить этот документ совершенно нет необходимости.

(33) Сожрет память тогда точно так же как таблица

(0) на самом деле предел памяти не 2, а /3GB

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

(21) Собственную таблицу SQL (временную или постоянную) или что-то в это роде не предлагать?

Даже тупо записать все из ексель в таблицу займет ну 5-10 секунд при самом плохом раскладе если читать напрямую и писать.
Потом над этой таблицей издеваться апдейтами.

35 это вроде только для приложений которые умеют AWE. 1с к ним относится думаешь?

(0) а код выложить слабо?

(36) тут на инфостарте недавно обсуждали, как нагнуть сервер путём создания ВТ в N гигов :))

(0) Кстати, а сколько примерно строк и колонок в екселевском файле?

(40)
Это же сколько строк и столбцов должно быть чтобы виртуальная таблица в гигах измерялась. Жесть в чистом виде.

(21) Оптимизируй, слушай Старших. Поверь, нет такого екселевского файла, который бы ложил бы систему :)

При загрузки из екселя, пиши все во временные файлы DBF
А после работай уже дальше :)

(43) +1

43 да там в итоге окажется что какую нибудь элементарную сортировку / фильтрацию нужно сделать, которую вообще бы стоило выполнить в самом экселе открыв его по ОЛЕ.

У меня в 8ке расчет прайса упирался в размер ОЗУ и не валился на 32х-разрядной системе. (но на х64 - всё хорошо, слава 1С 8 !)
(десятки клиентов, каждому - расчет по тысячам позиций и всё это - в один файл)

Потом нашел место для оптимизации и сейчас памяти кушается меньше. Но при увеличении числа позиций в несколько раз снова всё упрется в предел.

Функционал отчета переделать в Stored процедуру на sql. Результат в свою таблицу укладывать. А семерка пусть этот результат готовыми частями качает

тьфу ты... "упирался в размер ОЗУ и Валился"

+(43) файл excel можно и сразу в дбф сохранить, прикрутить файл индексов и работать спокойно.

(42) Это про восьмёрку было, там влёгкую.
Недавно попалась интересная статья Спешурика про составные типы в восьмёрке - вот где жесть так жесть.
http://infostart.ru/public/184361/

(41) Около 500 000 строк. Колонок - 20

(51) и версия эксела какая ?
:)

(49)+

(6) Исключения только подтверждают правила

(0)
4GB - легко. :-)
Тема: http://forum.infostart.ru/forum26/topic50264/message550872/#message550872
Сообщения: 12, 14.
Проверял на 1cv7.exe.

(0) а код мы так и не увидели.

(56) а что там смотреть.
зачти 51
ясно но же что надо писать в таблицу sql
а может быть даже к ней применить нормализацию
и индексы грамотно расставить.

(57)

создавал тестовую таблицу в 1 000 000 строк и 50 колонок простых типов строка(20)

в режиме /3GB


скорее всего автор не типизирует колонки

(58) на таких объемах индексированная ТЗ даже с простыми полями уже значительно хуже чем sql таблица.
ну и ключевое слово в 57 - нормалицация

(58)(59) Ребяты, вы ж предлагаете мозгами поработать... а у ТС их нет...

(0) Код нужно смотреть. Есть большая вероятность, что можно решить проблему оптимизируя код. Либо оптимизируя алгоритм работы. Что опять же ведет к изменению кода.

(51) Ты лучше поведай, что ты через ексель перегоняешь?
Для информационного баланса это исчерпывающая информация :)

(62)ВО!
Чел дело говорит!
И вообще что это за такой екселевский файл что аж на 500 000 строк?
Да и какой придурок мог его навоять.
Явно опять таки из какой-то базы.

Не проще ли прямо из 1С в то место вломится и взять что надо?

(55)Доброго времени суток. Извините что пишу Вам в этой теме. Хотелось бы узнать Ваше мнение. Моя конфигурация 1С 7.7 Бухгалтерский учет. Столкнулся с проблемой больших файлов DBF, а именно файл 1SBKTTL равен по размеру 1.09 Гб. Собираюсь использовать Kernel3x, но у меня возник вопрос, при таком большом файле 1SBKTTL, файл 1SENTRY.DBF весит всего 400 Мб. читал на форумах, что такое не нормально, вот мне и интересно, а можно ли уменьшить 1SBKTTL? и в чем может быть причина что он стал таким емиким? Буду признателен за ответ.

(51) Если вопрос из (0) еще актуален, то я бы порекомендовал работать через 1sqlite. Создаешь свою базочку, туда льешь данные из Экселя, индексируешь и потом крутишь, как тебе вздумается.