Continue to Site

Welcome to MCAD Central

Join our MCAD Central community forums, the largest resource for MCAD (Mechanical Computer-Aided Design) professionals, including files, forums, jobs, articles, calendar, and more.

Register Log in

Pro/E wildfire memory issue, please read.

D

donha

New member
I am on 2001 and UNIX. Open a part, drawing, assembly, close them and erase. Memory usage decreases, but not to the original beginning amount. The longer I work in Pro/E, swapping in and out data, the less memory I have from what I originally started with. OS or Pro/E? Don't know. This issue is not Wildfire specific.
 
I agree with donha, it is not Wildfire specific. I have it here also with Intralink and Proe2001. Only way to completely release memory is to shut down Proe and Intralink. If we don't do that several times a day, they get real slow by afternoon.
 
I'm curious hammerpe, what did PTC support say? Is there a problem in their eyes?



I don't crash very often but things sure get slower from time to time.



Steve C
 
I just happened to be reading some of these old posts and was wondering
if this issue was ever resolved. We are experiencing the same problem.





Thanks,



Richard
 
I feel it is one of those Pro/E things also working with Intralink at the same time compounds the issue, particularly if the number of frames build up in the workspaces.


Also the Local.ddb file under the .proi directory best I saw was about 205Mb the users was saying things were running a bit slow


Don ProE 2001 Intralink 2
 
Hi Hammerpe!


I'm in a similar situation, but the diference it's that the program shutdown when the memory use grows until the top value. Sometimes, changing working directory it's enough to crash down.


I'm working to solve it, you have given me a new point of view, when i get positive results i'll feed you back, i would appreciate the same from you...


Regards,
 
What OS (Operating System) you
use - Win 2000 orXp - Did you try that without use of Servis Packs - I
hate them
smiley7.gif
- If you work under XP - nothing more that SP 1 is needed for great
work
smiley17.gif
- Did somebody of youtry something in this area? I don
 
Experienced similar problems while running mechanism on 512Mb RAM machine, now upgraded to 1M but still slows down, just takes longer to fill RAM up. Found a free utility called FreeRAM XP Pro which runs in the background and gives you an indicator in the system tray as to how much RAM is available. You can set it to autofree RAM every so often. Seems to work fine.


Stu
 
I have been running a linked session of Wildfire 2.0 M060 with Intralink 3.3. I am working on a Dual Processor workstation w/ 2 Gig of Ram. I have been working in large assemblies as of late, and occassionally get outright kicked out of pro/e. I saw the last post and had MemFree Standard installed to monitor the memory situation. It seems to help some, recaliming memory over time. Generally, before openning Pro I start out with 800 MB free ram and the application will drag it down as low as 200 MB. I am hoping that over the long haul, this will help improve the performance as I am not sure that a 2 to 4 Gig Ram update is part of the plan.
 
the workaround I have used on a number of projects is to just log off/restart themachine, say at lunch, or morning break, etc, when you are needing to reclaim some of the memory space...Pro has been holding memory hostage since i2....or before?
 
This problem could be related to a problem that occurred back in about
version 16 or 17. When you were in family table and wanted to verify
all the instances Pro/E would open a new window to show an instance and
then close it before showing the next.



The problem was that the memory consumed by the CSRSS process was not
getting freed up again. We were running Digital Alphas at the time with
128MB of RAM and with CSRSS using 40MB instead of the usual 5 or 6MB it
made a pretty big difference.



I sent a model to PTC with 150 or so simple instances for them to try
and the verify crashed their Intel boxes. Maybe this is the reason why
verify now builds instances in the background.



DB
 
I have WF2 M90, on P4, 3,2Ghz, 2Gb of RAM, and 3D labs wildcat realism 100, and I haven't experience big problems of memory. But this problem of memory isn't of WF is of Windows. If you work in other applications, and monitor memory you will see that when you exit this applications memory is still big and didn't go down. Also if you open a big assembly, and xtop process went approximately 880 Mb of RAM, Windowos will kill the xtop process, and crash Pro/E. So its not really Pro/E problem it more windows.
So you must tweak windows to use more then 1Gb of memory for single process (xtop is single process).
 
I'm running Linux Fedora Core 3 to be specific, and have seen this
issue for several versions of wf2. It is a memory leak.
There are probably more than one. They must be in part of the
code base that is common to Windows and Linux/Unix. I can watch
the memory usage from a tool such as top or KDE system guard from Linux.



-cm
 
Hammerpe,


It's been a problem for quite a while, especially in linked sessions. This is due to the way Intralink keeps track of changes to files. Intralink uses triple the ram of a non-linked session because it tracks 3 copies of the file (CS, WS, session). Running WF2 with 512MB of ram is a joke unless you're non-linked. Whoever told you that it is acceptable doesn't run Pro/E on a daily basis. Afterall your Microsoft OS is using probably ~160 MB on startup, other stuff like Outlook & Office are using another 50-100 MB, then Pro/E starts up using 80-100 MB leaving you 150-200 MB for files. Also, Microsoft OS's like NT, 2000, & XP reserve 2 GB of ram for the OS and they're notorious for failing tofree ram when a program exits. We have WF2 M130 running on Dell 370's with a Quadro FX 3400 & 4 GB of ram for the large assemblies (>2000 parts). Even with those rigs we still use a switch to force XP to use only 1 GB for itself. This give us ~ 3 GB of ram to work in before we start swapping to disk. BTW, those of you running Intralink shoud use the compaction tool "ldbcompact" from the command line to clean things up a bit. Comments or questions? Get back to me & I'll see if I can help.
 
I'm glad I'm not alone on this one as well. We added the 3GB switch option as outilined in PTC's TPI 111330 document. I don't know if it helps or not. Wildfire gives up at about 2.5GB on the page file reading, but it steadily climbs. Unless I use erase not display the second big assembly I open crashes out after taking an age to regenerate. Wildfire actually gives a "Memory error" prompt before it dies.
 
This problem is certainly not limited to Pro/E.



I had the misfortune to be using SolidEdge for 3 months. In a typical
day I would be running out of memory by lunchtime and the machine would
slow down noticeably. The sum of Mem Usages in Task Manager was miles
short of the fitted RAM yet Available RAM was low. Exitting SolidEdge
immediately restored the lost RAM.



DB
 
You must log in or register to reply here.

Sponsor

Articles From 3DCAD World

Back
Top