Лечится ли ошибка "out of memory" возникающая при выгрузке xml? #394297

Есть база 7.7 Выгружаю из нее данные для перехода на 8ку. База не очень большая.. элементов справочника контрагентов имеющих остатки порядка 600 тысяч.. при выгрузке в xml после пары тройки часов вываливается  с "out of memory" причем на компе естественно никакой нехваткой памяти, процессорной мощности или жесткого диска и не пахнет. вопрос это лечится или придется резать стандартные правила для перевода "по кускам" ? естественно что платформы все обновлены, релизы и правила последние.

гаечки поштучно учитываете?

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

Только бить, и выгружать частями

угу. просто хотел уточнить.. а то потрачу время а окажется что есть какойнить "обновленный драйвер для xml" который позволяет работать с файлами больше чем 1 гиг.

У тебя валиться XML-парсер, тот который от мелкософта. Валиться он изза того что пытается отожрать больше 2 Гб памяти (он _весь_ формируемый/считывамый xml-файл держит в памяти + его собственные глюки). Попробуй формировать выходной файл вручную - xml этоже по сути текст ))).

Скорее всего не удастся выгрузить в последовательный файл, хотя чем черт не шутит.

даже не буду пытаться. либо по оле выгружу либо правила покоцаю чтобы частями выгружать.. подумаю еще что именно делать...

Не по спортивному получается ;)

поставить 64бит систему и соотв скл. Написать выгрузку через скл. и 8ку взять 64бит.

быстрее по оле + лицензии на х64 сервер предприятия нету :) а система и так х64

Сдается мне что по ОЛЕ не быстро 600К контрагентов с остатками выгрузится ;)

ну думаю быстрее чем переписывать правила под SQL + смена платформ на x64 + неясный результат в итоге :) причем по оле можно запустить в несколько потоков. 1с не занимает все ядра в процессе работы. тоесть на четырехядерном проце можно запустить четыре потока и они будут нормально в полную силу выгружаться :)

Под ОЛЕ есть готовая обработка ??? и потом непонятно как бить на части, по буквам алфавита ???

на 80% готовая. а зачем по оле бить на части?

>>на четырехядерном проце можно запустить четыре потока и они будут нормально в полную силу выгружаться :) Или 4 раза одно и тоже выгружать ???

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

хм. нужно думаешь разные процессы всеравно на первый будут вешаться ?

зачем одно и тоже: первый выгружает допустим остатки по 62ым счетам второй допустим по 60ым третий какойнить там 10ый счет естественно перед этим предварительно полная синхронизация справочников.

Да. всегда грузиться первый камень. Хочешь чтоб нагрузка распределялась на все: ставь линь (или бсд) поверх нее wmware esx server. на него гостевую вынь 2003; тогда у тебя будут загружены _все_ камни - nix разрулит.

Сами по себе остатки - мелочь, там по ссылкам цепляется всякая фигня, вот и растет файл выгрузки. Как раз >>полная синхронизация справочников. и занимает большую часть места в выгрузке, они же виноваты в том что для выгрузки в хмл ипользуется DOM. Закусывать надо. Операционка сама вешает процессы на разные ядра, или как она посчитает нужным. Вот распаралелить один процесс с 1с она не может.

Set Affinity в таск менеджере решает данную проблему без линуха,бсд и вмваре

Опять не по спортивному, а так поставил в вмваре линух, там в виртуалбох вин2003 а там и 1с запустил - благодать

тучные, потные, ленивые программисты 1с с отдышкой и пивом далеки от спорта...

Предложенная схема была реализована в Казани, фирмы Прогресс, база РарусАльфаАвто, никак не оптимизированная, только доточенная, юзеров онлайн сидело 60+. железка была "супермикро", 4 гига оперативы, 4 камня. Тянула еще второй DC.

Что-то я не понимаю смысл огорода. Один процесс 1С никакой вмваре или линух на несколько потоков никак не разложат. Поднимать линух, на нем вин2003 ... непонятно.

там было поднято три вмваре. каждому вмваре по ядру в каждом вмваре по 20 пользователей :)

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

(27,28) А смысл? Каждый юзер юзает свой процесс 1С. А ОС сама эти процессы раскидывет по ядрам. Поэтому смысл ставить на тормознутую вирт. машину?

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

Ну у меня отдельная машина под 1С и отдельная под терминал, и там и там юзаются все ядра, без извращений. На филиале все во одном, и тоже не замечал, чтобы ядра простаивали.

Установил 2003. Роль назначил: сервер терминалов. Настроил юзерам коннекты к серверу. Установил на серваке 1С. Базы положил локально. Пользователи заходят в 1С, работают. ДЗ выдает загрузку 1-го камня. Что я делаю не так ?

2003 какой чистый или R2? Сколько юзеров? А если в ручную назначить 1С у юзера другой камень?

Что-то делаешь не так, не нужно ставить сервер терминалов, чтобы разные процессы 1с грузили разные ядра. Запусти на локальной машине две одинески и будешь приятно удивлен. Может что-то там с лицензиями в вин2003 ???

Так чисто, чтобы мы понимали о чем речь. 1С у 1 юзера под виндоус не может занимать N ядер. 1С однаядерная, т.е. 1 экземпляр = 1 ядро. Но ОС может раскидывать разные экземпляры 1С на разные ядра, т.е. каждый экземпляр 1С будет занимать свое отдельное ядро (в общем случае).

В общем случае не обязательно "Каждый экземпляр 1С будет занимать свое отдельное ядро", разложит как посчитает нужным, и не факт что несколько 1с на первом ядре это плохо. На самом деле 1С довольно слабо грузит проц, в основном грузится дисковая подсистема за счет всяких временных ДБФов и прочей ахинеи.

никс раскидывает задачи одного юзера на несколько камней.

Ты утверждаешь, что однопоточный процесс никс раскладывает на несколько ядер ???

При этом тормоза вирт машины сводят этот плюс на нет. Если бы у тебя было бы 20 камней и 4 юзера, тогда да. Но у тебя и так на каждом камни сидит по 5 юзеров, поэтому смысл раскидывать на то, что уже занято?

таг. в мну указал что твориться если поставить никс. В я задал вопрос. В - вывод. Неявный вывод, но все таки. 1. Где утверждкние ? 2. Смысл ловить меня за язык ? Не работает так как как утверждаю в 25 - я мутаг. Готов сменить картинку в профиле. 3. Что мешает тебе попробывать а не молоть языком ?

лучше бы придумали где взять волшебный_патч_заставляющий_виндовых_xml_понимать_файлы_больше_2GB

звонить в_подддержку_не пользоваться_вынью_взять_в_руки_фзыкпрограммирования. Быть, а не казаться.

см

43 это: ... ~Метка: или я чего то не понимаю ?

Человеку свойственно ошибаться, как в 25 проверять не стану, ибо лень. Да и никаких рекомендаций от 1с в эту сторону нет. Опять же проверять что вин2003 работает производительнее под вмварью из под никса не хочется. а то что такая система будет работать я не сомневаюсь. К тому же тут другая задача. переписывай под сакс модель выгрузку от 1С ;) тогда будет ограничение только на размер файла на ФС ;)

благодарю

Перегружать справочники лучше при помощи COM-соединения. Размер программы -операторов 15-20 плюс по оператору на каждый реквизит справочника. Запускется в режиме транзакций с периодическим завершением и началом транзакции через 200-300 элементов справочника.

хм, а 64-битного парсера хмл мелкомягкие не выпустили?

хм... у меня такая ошибка была не в 1с а просто когда открываешь файл... после перезапуска исчезает.. оказался банально вирус... он перехватывал запрос проги на достаточность памяти и посылал неверный ответ в следствии чего прогама сама по се вылетала!