"Недостаточно памяти" при загрузке dt #605813

Windows 7 x32 2 Gb Ram (1 свободно) релиз 8.2.15.301 На диске 55 Гб свободно размер архива 313 Мб Не пойму какой памяти не хватает и почему. Процесс 1c8.exe отжирает максимум 30 Мб.

а на нормальной машине развернуть?

а чем эта ненормальная, недавно в батлфилд 3 без тормозов играл на макс.

смишной

Увеличь до 4- гб файл подкачки, попробуй

В мемориз!

возьми нормальную машину. Одно дело игры, другое дело учетная система.

То, что дтшник выгрузился еще не значит, что он загрузится...

Обычно сообщение "Недостаточно памяти" означает, что памяти недостаточно. Ваш К.О.

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

Я с таким сталкивался - Можно задать несколько вопросов ? Я правильно предполагаю, что конфа не типовая ? Размер виртуальной памяти фиксирован, или стоит "по выбору системы" ? Не можете попробовать загрузить dt на 64-разрядной Win 7 (у меня это оказалось "волшебным средством") ? Винда давно устанавливалась ? Она обновляется ?

на поддержке, небольшие изменения по выбору ос завтра попробую на 2003 х64, но как бы не сомневаюсь, что загрузит вопрос в том ram или hdd? полностью согласен

через SQL пропусти.. если есть возможность

На 2Г уже стыдно грузить 300 метровый дт???

и правда... посыпаю голову пеплом - как же можно было 2 года грузить в файловую на такой машине 500 метровые dt-шки, да еще и работать с ними.... надо было сразу убиться.... (((

не для работы, а для отладки

Обновление на 256 М - это грустно... но получалось)

Думаю, дело вот в этом: "на поддержке, небольшие изменения" Вот попробуйте на серверной копии поставить конфигурацию на поддержку без возможности вносить изменения или наоборот - удалите конфигурацию поставщика. Выгрузите в dt, и думаю, загрузится без проблем. Даже если в пробную базу загрузите вдвое больше данных !

Кста, вот это очень интересно: "завтра попробую на 2003 х64, но как бы не сомневаюсь, что загрузит". Ведь 1С - 32-х разрядное приложение. Но я тоже думаю, что загрузится...

Разок было подобное, тупо места для разворачивания архива не хватало. Чуток почикали "мусор" и все взлетело.

ТС пишет, что у него свободно 55 Гб, а размер архива 313 Мб. Т.е. это не тот случай. И я могу подписаться - такое бывает.

"или наоборот - удалите конфигурацию поставщика" - это как?

Полностью снять с поддержки.

+ Я вовсе не предлагаю это делать с раб. базой - только с копией для получения информации.

Делайте полную проверку базы - при таких размерах, как уже сказали выше, подобное сообщение говорит о том, что где-то в данных был косяк. Ну или у вас админ-криворучка, на временную папку квоты настроил криво, и в ней место кончается при загрузке.

встречал такую ошибку неоднократно. лечится поиском по мисте

Попробовал это лекарство. Понравилось - Скажите, Klest, у Вас PostgreSQL ?

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

ТС, а у тебя часом не УПП с конфигурацией поставщика > 120 Мбайт ?

32-битное приложение не может больше 2 Гб схавать без спец. ключа в boot.ini.

Ему там и гига мож не достается, винде то тоже память надо

А если бы у него была УПП с конфигурацией поставщика > 120 Мбайт, то что ?

А своп на что?

будь мужиком - добавь оперативы!

да, точно такая же ситуация на 2003 х64 загрузилось без проблем

А теперь, если можете, выгрузите с базы на 2003 х64 dt-ху, и попробуйте уже ее загрузить на Windows 7 x32 (я у себя смогу это сделать только завтра утром, а мне очень любопытно...). Если загрузится - это будет фишка !

Загрузилась! А вы говорите х.. компьютер. Ничего в конфигурации и настройках ос не менял.

т.е. есть небольшая база под PostgreSQL. В конфигурацию были внесены изменения. ТиИ делали. Выгружаем dt. Под 32-х разрядным Win - будет "нехватка памяти" (и не говорите, что памяти мало - у меня физически 3Гб, и с виртуальной все в порядке). На 64-разрядном Win все нормально загружается. Выгружаем dt уже на ней - и вуаоля ! Новая dt загружается нормально уже под 32-х разрядным Win. Правда клёво ?

x32

Не хватает оперативной памяти(ОЗУ) и первое что посоветую служба поддержки 1С - попробовать выполнить то же самое на х64 ОС. У меня такая же ошибка, но при проведении большого документа на х32 системе. На х64 проводится

А что, службы поддержки и правда так говорят ? Дело в том, что большие сомнения возникают по поводу "нехватки оперативной памяти": 1. Вылет происходит даже на dt, полученных с маленьких баз, если она выгружена c PostgreSQL и в конфигурацию внесены изменения. Если в конфигурацию изменения не внесены, или dt получена не с PostgeSQL - вылета нет, ДАЖЕ ЕСЛИ БАЗА В РАЗЫ БОЛЬШЕ. 2. Если dt загрузить на x64, потом выгрузить новую dt уже с нее - она меньше не становиться. Но вот чудо, оперативной памяти вдруг уже хватает ! 3. Сбой происходит и при 2Гб оперативки, и при 3ГБ оперативки, и при любых настройках виртуальной памяти. Причем при одном и том же времени после запуска. 3. Я запускал процедуру загрузки dt и контролировал количество занятой и доступной памяти через диспетчер задач. В момент вылета доступной физической памяти было столько же, сколько при запуске задачи (что-то в районе 1,5Гб, вроде), и количество используемой виртуальной памяти практически не росло. Мне кажется, что из этого сложно сделать вывод, что проблема в количестве оперативной памяти. Вот с говнистостью PostgreSQL связь можно заметить. Но самое интересное - связь с x64. Вроде 1С - 32-х разрядной приложение. Тогда каким чудом ?!

Вы хотите сказать, что x32 для 1С 8.2 уже не тянет, вне зависимости от ресурсов компа ?

Скорее другое. В 32-разрядной версии сервера 1с есть какой-то баг, которого нет в 64-разрядной. Из-за этого бага и наблюдаются ошибки вида "нехватка памяти". Скорее всего, при определенных условиях(состоянии базы) сервер пытается выделить буфер в памяти размером больше 2 гигабайт, выходя за пределы доступного в 32-разрядном софте адресного пространства. Собственно объем данных в базе тут не при чем.. А вообще для такого софта (с такими потенциальными потребностями в ОЗУ) должен использоваться свой менеджер памяти, отслеживающий эту ситуацию и принимающий меры для её решения. Например, при необходимости создавать служебные подпроцессы-"хранители данных" со своим адресным пространством, с обменом данными через разделяемую память. 1с было лень это реализовывать.. проще оказалось тупо пересобрать сервер под x64.

только процесс 1с не сжирает больше 2 Гб, там максимум 160 Мб

А я и не говорю, что он сжирает. Он ХОЧЕТ сожрать, но операционная система ему не может дать столько из-за архитектурных ограничений.

Понимаете, dt выгруженную с PostgreSQL мы пытаемся загрузить в ФАЙЛОВУЮ БД. Т.е. 1С сервер уже не работает. На x32 и не x64 стоит одна и та же версия платформы. Кста, как раз в серверную БД dt Загружается сразу и без проблем. Моя гипотеза близка к Вашей. dt, выгруженная с PostgreSQL имеет какую-то проблему в данных. Эта проблема бывает только если конфигурация была изменена. При загрузке этого dt платформа пытается создать временный файл с размером большим чем 2Гб (и ей плевать, что база маленькая). Причем для скорости она пытается работать с ним не обычными функциями чтения-записи, а функциями отображения оперативной памяти. Вот тут в случае x32 и происходит накрывашка по АДРЕСНОМУ пространству. У меня получается вывод - если Вы работаете с PostgesSQL, конфигурации переписаны, Вам нужен x64 на десктоп. Ну, или держать локально MS SQL - делать на нем загрузку/выгрузку для получения "чистого" dt, но это не удобно.

2 "Причем для скорости она пытается работать с ним не обычными функциями чтения-записи, а функциями отображения оперативной памяти." - вы слишком хорошо думаете об интеллектуальности в8. Я думаю что она таки пытается это делать через чтение-запись, но виндовый менеджер памяти сначала все делает через системный кэш.

А может и так.

"Я думаю что она таки пытается это делать через чтение-запись, но виндовый менеджер памяти сначала все делает через системный кэш." Вы переоцениваете винду, искусственного интеллекта в ней пока еще нет.. И самостоятельно переделать open в mmap она вряд ли догадается. :) А системному кэшу при чтении файла до лампочки, какой объем данных запрашивается.. он сработает по имеющейся доступной памяти, никакой ошибки не будет.

Мне кажется, тут может быть проблема с signed/unsigned типами. Точнее, с тем, как процедуры выделения памяти из разных версий Windows интерпретируют один и тот же параметр со значением больше 2 Гб. Это ведь нам могли сказать, что тип DWORD, а в самой Windows внутри и signed long может быть. Или где-то внутри этот DWORD обрезается до signed long. Ну и второй вариант - у 32-битной версии Windows просто нет непрерывного куска памяти размером больше 2 Гб, потому она и выдает ошибку.

"Ну и второй вариант - у 32-битной версии Windows просто нет непрерывного куска памяти размером больше 2 Гб, потому она и выдает ошибку." - думал об этом. Создавал большой файл подкачки фиксированной величины. Пофигу. По поводу первого утверждения. Возможно, но есть аргумент против. Вот выгружаем dt с PostgeSQL. Она имеет размер, допустим x Мб. Загружаем в файловую под x64. Выгружаем новую dt. Она имеет размеры x Мб + НесколькоДесятковКилобайт. После чего она прекрасно загружается под чем угодно. Вывод - в dt, выгруженной из PostgeSQL чего-то не хватает. X64 с этим справляется, а x32 - нет. Но это ситуация - еще фигня. Хуже с обновлениями. Базы, установленные на PostgreSQL с изменениями в конфигурации (УПП) точно также вылетают при попытке штатно обновиться (сервера - линукс 64-разрядный). Приходится делать так. Выгружаю cf. Создаю под x64 пустышку со структурой из cf - файловую базу. Нормально обновляюсь с помощью cfu (какое счастье - кнопка в фильтре "только дважды измененные" !). Выгружаю cf. Загружаю его в базу под PostgeSQL (нормально запускается процедура, отрабатывающая первый запуск после обновления). А знаете, что будет, если эту операцию попробовать выполнить на x32 ? Ошибка вызова функции C++ !!! (да, платформу я полностью переустанавливал, и прочие танцы с бубнами выполнял). Вывод - криво платформа работает с postgeSQL. Потом по x64 она с этим "кривульками" справляется, а под x32 - нет.

Ну вы че вообще, издеваетесь над собой? Даже если загрузится этот dt, неужели так трудно память добавить чтобы работать нормально за компом? тем более щас память дешевая, продается на каждом углу. Пошел на обеде, купил, всунул и готово. Делов на пол часа максимум.