Creo - загрузка ОЗУ

[Boryan 0]

Знающие люди, поделитесь знаниями, пожалуйста. Суть в следующем...

 

При работе в программе "Creo Parametric", возникают проблемы с загрузкой оперативной памяти. Дело в том, что при загрузки памяти в районе 90-92% система выдаёт сообщение, что работает с недостаточным количеством оперативной памяти, и продолжение работы может привести к закрытию программы, и желательно сохраниться.
При достижении около 95-97% программа просто закрывается.
При исследовании ошибки, выяснилось, что при запуске программы, занимается какое-то количество памяти (на используемом варианте ПК это около 37%)
После, после загрузки модели, занимается ещё какое-то количество памяти (в моём случае объём доходит до 61-62%):
При выполнении каких-либо операций, объём занимаемого ОЗУ  растёт, при этом, в случае, если закрыть сборку и после этого "стереть непоказанные" элементы, то память почему-то разгружается не полностью (в моём случае до 73%), не смотря на то, что программа в "пустом" виде занимает 37% ОЗУ.
При этом, если начать загружать эту же сборку, то она займёт то количество ОЗУ, которое занимала в момент "выгрузки" (если же перезапустить полностью программу, эта же сборка будет занимать меньший объём ОЗУ, в данном случае те же 61-62%). В случае загрузки другой сборки/детали, которая будет "много весить" - программа просто закроется. Однако, при полной перезагрузке программы - сборки/детали опять загружаются.
В чём может быть причина такого использования ОЗУ? Если это как-то связано с настройками программы - подскажите с какими, так как данная проблема накладывает существенные ограничения и большие неудобства, особенно при работе с большими сборками - приходится после определённого количества действий пересохранять сборку и перезапускать программу.

[GOLF_stream 292]

У меня таких цифр никогда не было.

Надо анализировать не только проценты, но и абсолютные величины.

Сколько оперативной памяти? Не в процентах, а в гигабайтах. Может, у Вас всего 512 Мб, тогда совсем неудивительно.

И какого уровня сборки? Сотни тысяч деталей?

Возможно ещё сами детали сделаны "через анус" так что каждая весит очень много.

[persona1980_1 123]

Какая операционная система?

[Boryan 0]

У меня таких цифр никогда не было.

Надо анализировать не только проценты, но и абсолютные величины.

Сколько оперативной памяти? Не в процентах, а в гигабайтах. Может, у Вас всего 512 Мб, тогда совсем неудивительно.

И какого уровня сборки? Сотни тысяч деталей?

Возможно ещё сами детали сделаны "через анус" так что каждая весит очень много.

 

На данной машине - 2 Гб. Так же проводил те же самые исследования на 4 Гб - смысл тот же. Отличие идёт только в начальной загрузке модели (в процентах занимает меньше оперативной памяти) и в количестве выполняемых действий (получается выполнить бОльшее количество, примерно раза в два).

В данном случае всё исследовалось на Win 7 x86, пробовал так же на XP - опять же, на пару действий получается выполнить больше, за счёт того что сама система "кушает" меньшее количество оперативной памяти.

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

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

Однако, суть даже не в этом, а в том, что функция "стереть непоказанные" полностью не вычищает то, что находилось в ОЗУ, оставляя "пустую" программу, хотя, это может как-то взаимосвязанно...

 

Какая операционная система?

 

Win 7 x86. То же самое проделывал и на XP.

[wexus 41]

Действительно наблюдаю такую же картину и на 32-  и на 64-битной системе с любым количеством памяти.

Есть такой параметр proe_memory_buffer_size со значением по умолчанию в 50 мб, определяет размер в мегабайтах буфера памяти, резервируемого Creo Parametric на случай нехватки памяти. Необходимо перезагрузить Creo Parametric для того, чтобы изменение вступило в силу. (Отвечает за то сколько памяти будет занимать процесс при старте программы). Посмотрите свой конфиг, есть ли там такая запись.

 

Что касается загрузки памяти - тут всё зависит от того с какими сборками вы работаете (количество компонентов) и в каком представлении. Для работы с большими сборками нужно пользоваться упрощенными представлениями, а так же использовать производительную систему (большая частота рбочих ядер, больше быстродействующей ОЗУ, быстрый жесткий диск, если работаете локально и стабильная высокоскоростная сеть до сервера, если данные находятся удалённо). Советую использовать 64-битную систему не менее 4 ГБ ОЗУ (лучше 8-16) для тех кто работает с крупными сборками, деталировщикам хватит и 4-8 ГБ.

 

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

[persona1980_1 123]

Может Creo не лицензионный у Вас? И в этом проблема?

[EIV 59]

Может есть циркуляционные ссылки (с расширением .crc) и от них вся беда?

[Bamboo 192]

proe_memory_buffer_size со значением по умолчанию в 50 мб

а если у меня RAM 16Gb сколько надо прописать в этой опции? 

[Boryan 0]

Действительно наблюдаю такую же картину и на 32-  и на 64-битной системе с любым количеством памяти.

Есть такой параметр proe_memory_buffer_size со значением по умолчанию в 50 мб, определяет размер в мегабайтах буфера памяти, резервируемого Creo Parametric на случай нехватки памяти. Необходимо перезагрузить Creo Parametric для того, чтобы изменение вступило в силу. (Отвечает за то сколько памяти будет занимать процесс при старте программы). Посмотрите свой конфиг, есть ли там такая запись.

 

Что касается загрузки памяти - тут всё зависит от того с какими сборками вы работаете (количество компонентов) и в каком представлении. Для работы с большими сборками нужно пользоваться упрощенными представлениями, а так же использовать производительную систему (большая частота рбочих ядер, больше быстродействующей ОЗУ, быстрый жесткий диск, если работаете локально и стабильная высокоскоростная сеть до сервера, если данные находятся удалённо). Советую использовать 64-битную систему не менее 4 ГБ ОЗУ (лучше 8-16) для тех кто работает с крупными сборками, деталировщикам хватит и 4-8 ГБ.

 

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

 

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

 

По поводу конфигурации машины - возможно. Однако, тестировал ту же самую модель на машине с относительно хорошими параметрами (2,8 GHz - процессор (4 ядра) 16 Гб ОЗУ, видеокарта Quadro-K4000) - там, конечно проблем с ОЗУ не замечается, ввиду  объёма, однако возникают другие проблемы, в частности - "тормоза" при переопределении элементов, или создании чертежа. Но тут, возможно, так же имеет место быть проблемам неправильно собранной модели сборки (или, скорее всего, её подсборок). Так же, конечно, быстродействием ОЗУ и винчестер на машине не отличаются - средний уровень. Работа ведётся на машинах локально, так что проблема с быстродействием сети вряд ли сказывается.

 

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

 

Может Creo не лицензионный у Вас? И в этом проблема?

 

Проблема точно не в этом - продукт лицензионный.

[GOLF_stream 292]

Если лицензионный, то имеет смысл обратиться к поставщикам.

[wexus 41]

 

proe_memory_buffer_size со значением по умолчанию в 50 мб

а если у меня RAM 16Gb сколько надо прописать в этой опции? 

 

Я думаю с 16 ГБ очень трудно добиться вылета от нехватки памяти.

 

Действительно наблюдаю такую же картину и на 32-  и на 64-битной системе с любым количеством памяти.

Есть такой параметр proe_memory_buffer_size со значением по умолчанию в 50 мб, определяет размер в мегабайтах буфера памяти, резервируемого Creo Parametric на случай нехватки памяти. Необходимо перезагрузить Creo Parametric для того, чтобы изменение вступило в силу. (Отвечает за то сколько памяти будет занимать процесс при старте программы). Посмотрите свой конфиг, есть ли там такая запись.

 

Что касается загрузки памяти - тут всё зависит от того с какими сборками вы работаете (количество компонентов) и в каком представлении. Для работы с большими сборками нужно пользоваться упрощенными представлениями, а так же использовать производительную систему (большая частота рбочих ядер, больше быстродействующей ОЗУ, быстрый жесткий диск, если работаете локально и стабильная высокоскоростная сеть до сервера, если данные находятся удалённо). Советую использовать 64-битную систему не менее 4 ГБ ОЗУ (лучше 8-16) для тех кто работает с крупными сборками, деталировщикам хватит и 4-8 ГБ.

 

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

 

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

 

По поводу конфигурации машины - возможно. Однако, тестировал ту же самую модель на машине с относительно хорошими параметрами (2,8 GHz - процессор (4 ядра) 16 Гб ОЗУ, видеокарта Quadro-K4000) - там, конечно проблем с ОЗУ не замечается, ввиду  объёма, однако возникают другие проблемы, в частности - "тормоза" при переопределении элементов, или создании чертежа. Но тут, возможно, так же имеет место быть проблемам неправильно собранной модели сборки (или, скорее всего, её подсборок). Так же, конечно, быстродействием ОЗУ и винчестер на машине не отличаются - средний уровень. Работа ведётся на машинах локально, так что проблема с быстродействием сети вряд ли сказывается.

 

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

 

Может Creo не лицензионный у Вас? И в этом проблема?

 

Проблема точно не в этом - продукт лицензионный.

 

Иногда тормоза появляются при работе со сборкой, когда открыто так же множество окон в CREO. Он пытается обновить информацию во всех окнах сразу.

[Bamboo 192]

Иногда тормоза появляются при работе со сборкой, когда открыто так же множество окон в CREO. Он пытается обновить информацию во всех окнах сразу.

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

[wexus 41]

Если у вас есть сборка

 

TOP_ASM

-ASM_1

-ASM_2

-ASM_3

--ASM_3_1

---PRT_1

-ASM_4

 

Пример не самый большой. Смысл в том что если сразу открыты окна на: TOP_ASM, ASM_1, ASM_2, ASM_3, ASM_4, ASM_3_1 и вы решили отредактировать деталь PRT_3_1 скорость её редактирования в отдельном окне будет заметно медленнее, чем если бы вы вызвали в сессию только данную деталь. Ещё была давно озвучена проблема с вхождением в редактор эскиза если открыта большая сборка.

[Motek 9]

Действительно наблюдаю такую же картину и на 32-  и на 64-битной системе с любым количеством памяти.

Есть такой параметр proe_memory_buffer_size со значением по умолчанию в 50 мб, определяет размер в мегабайтах буфера памяти, резервируемого Creo Parametric на случай нехватки памяти. Необходимо перезагрузить Creo Parametric для того, чтобы изменение вступило в силу. (Отвечает за то сколько памяти будет занимать процесс при старте программы). Посмотрите свой конфиг, есть ли там такая запись.

 

 

 

можно проверить еще один параметр

 

! dm_cache_limit: A good rule of thumb is 80% of the remaining free space

!**********on the disk where Wildfire cache is located.***

dm_cache_limit 60000

[Boryan 0]

Параллельно с созданием данной темы сделал запрос поставщикам. В общем, ответ был таков:

 

 

Борис, у Вас явно не хватает оперативной памяти.

 

Из  нашего опыта могу сказать что в среднем РАЗМЕР_СБОРКИ_В _СЕССИИ = (РАЗМЕР_СБОРКИ_НА_ДИСКЕ)*(3-4)  т.е. в вашем случае это ~6 Гб

Размер сборки в сессии зависит также от количества повторяющихся компонентов в сборке.

Для примера сборка размером 761Мб при повышении качества отрисовки модели превращается в 4,5 Гб в сессии.

 

То есть, во-первых, нехватка оперативной памяти; во-вторых, оказывается, размер сборки в сессии увеличивается "РАЗМЕР_СБОРКИ_В _СЕССИИ = (РАЗМЕР_СБОРКИ_НА_ДИСКЕ)*(3-4)", и может зависеть от кол-ва повторяющихся объектов (кстати, в моём случае, несколько подсборок повторяются около 100 раз). Это всё, конечно, относится к сборкам, загружаемым "как есть" (без упрощённых видов и замен).

 

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

 

 

При работе с большими сборками Вам необходимо настроить отображение объектов:

- понизить качество отрисовки затененных моделей (Вид> Настройки отображения> Показ модели…> Закраска > Качество) в качестве значения поставить 1.

- понизить качество отрисовки ребер Вид> Настройки отображения > Показ модели…>Кромка/Линия>Качество кромок... в качестве значения поставить Низкое.

- отключить отображение малых поверхностей Вид > Настройки отображения > Показ модели…> Закрашивать > Малые поверхности (галочку снять)

- задать в конфигурационном файле config.pro следующие переменные

spin_with_notes со значением no
spin_with_silhouettes со значением no
spin_with_part_entities со значением no
display со значением shade
display_silhouette_edges no
default_ramp_size со значением 0
lods_enabled со значением no
edge_display_quality со значением low
shade_quality со значением 1
shade_with со значением no
blended_transparency со значением no
show_shaded_edges со значением no

 

При работе с большими сборками Вам необходимо создавать и использовать упрощенные представления

• упрощенные представления формируемыми по методу включения/исключения
• упрощенные представления формируемыми по методу подмены
• упрощенные представления формируемыми упрощающими примитивами Оболочками

 

Рекомендации данные выше позволят снизить требования к аппаратных ресурсах ПК.

[Boryan 0]

Ещё небольшое уточнение...

Для 32-х разрядных систем размер динамических данных для одного приложения ограничен 2 Гб. Это значит, что при работе с большими сборками, даже при 4 Гб ОЗУ (максимум для 32-х разрядных) Creo (хотя, в принципе и любым другим приложением тоже) будет использоваться только половина. Следовательно, логичней использовать 64-разрядную систему, иначе идёт иррациональное использование ОЗУ.

 

https://software.intel.com/en-us/articles/memory-limits-applications-windows/

Изменено 17 апреля 2014 пользователем Boryan

[Alex_405 0]

У нас похожая проблема. Используем Creo/Elements Pro 5.0 в связке с Windchill 9.1. Машина мощная: Win7x64, Intel Core i7, 16GB RAM. Открываем маленькую детальку, работаем, и в определённый момент сохраняемся и крео виснет. Висит от 2 до 10 минут, потом говорит, что файл был записан и в общем-то всё хорошо.

 

Примечательно то, что до зависания xtop.exe занимает порядка 400МБ. Пока он висит, размер занимаемой им памяти довольно быстро растёт и в итоге дорастает до 2-4ГБ. Монитор ресурсов пишет, что xtop.exe что-то в огромных количествах тянет с виндчилловского сервера. Логи сервера пишут, что пользователь заново загружает себе всё содержимое рабочей области. Почему - непонятно. Повторюсь - в сессии всего одна деталь без внешних привязок и мы просто её сохраняем. 

 

Далее, если закрыть файл и "стереть невидимые", память не освобождается. Если сразу после "отвисания" попробовать закрыть крео, то он ругается, что выполняет операции с базами данных в фоновом режиме и не может быть закрыт прямо сейчас. Через пару минут закрывается без проблем.

 

Проблема проявляется абсолютно случайным образом - в среднем 2-3 раза в день при операциях открытия, сохранения или регенерации файла, но не всегда - можно 10 раз сохраниться без проблем, а на 11-й подвиснуть.

 

Что характерно: данная проблема присутствует только на мощных машинах. На старых компьютерах с ХР и 2ГБ оперативной памяти таких проблем не было замечено ни разу за несколько лет.

 

Есть у кого-нибудь мысли на этот счёт?

[Гаечка 14]

После упорных настроек CreO для работы с большими сборками...открыла огромную сборку (которая ни в какую не открывается в CreO)....в WF4- все открылось. Для проектов с большими сборками - только WF!!!

[Bacha 0]

После упорных настроек CreO для работы с большими сборками...открыла огромную сборку (которая ни в какую не открывается в CreO)....в WF4- все открылось. Для проектов с большими сборками - только WF!!!

 

Абсолютно идентичная ситуация. Несколько месяцев назад перешли с  WF4 на Creo2. То что раньше было сделано в  WF3,4 открывалось много лет в них без проблем и с запасом по оперативной памяти, то эти же сборки на этих же компьютерах в Creo2 не открываются из-за нехватки ОЗУ. Эксперименты с конфигами, рекомендуемыми настройками проводились - результат отрицательный. Ситуация некритичная, потому что на предприятии идёт замен на более мощные компьютеры, но неприятный осадочек остался, да и остаются ещё слабоватые компьютеры. Может кто нашёл за это время пути борьбы с пожиранием ОЗУ.

Раньше в WF3,4 практически не сталкивались с нехваткой памяти, да и открывали сборки в них раза в три четыре больше по объёму.

[GOLF_stream 292]

Я вот сейчас мучаюсь (в прямом смысле слова) с Крео3. Даже с одной деталью тормозит неимоверно. Работаю с поверхностью Свободного стиля (FreeStyle), используя функцию совмещения этой поверхности с построенной ранее геометрий. В Крео2 этой функции нет, поэтому приходится работать в третьем.