Out Of Memory 3

[PMcGowan]

I am an IT Tech and my engineers are getting very frustrated. They are running SW 2005 SP5, and when they check a drawing out if the PDMWorks, make one change and try to check it back in there PC crashes with an out of memory error. I have upgraded them from 2000 to XP, they have 4gigs of memory with Virtual set at 8000. Their PC's are higher end PC's and are above and beyond what the SW site states. They are losing a lot of time and I have not been able to get answers from our VAR. Any suggestions? Please help, they are at their wits end.
Any ideas will be appreciated.

 

[CorBlimeyLimey]

Do you have the /3GB switch enabled?

http://www.panoramafactory.com/discus/messages/17/313.html?1057432320

http://aumha.org/win5/a/xpvm.php

Helpful SW websites faq559-520
How to get answers to your SW questions faq559-1091

 

[PMcGowan]

Yes.

 

[CorBlimeyLimey]

Does this happen with any size file or drawing, or just large drawings?


Helpful SW websites faq559-520
How to get answers to your SW questions faq559-1091

 

[PMcGowan]

The file sizes that they are having problems with are usually over 200mb.

 

[PDMAdmin]

Are these 32-bit machines or 64-bit? If they're 32-bit machines, I don't see how you could set the virtual memory to 8000 MB because the maximum virtual memory in XP is 4096 MB.

Having 4 GB of RAM won't help you; you're wasting your money after 2 GB, at least with SolidWorks. That's because of the way Windows allocates memory.

How many other applications or services are running, either in the foreground or background, when these drawings are loaded? Try bringing up the Windows Task Manager while a drawing is loaded and click the "Performance" tab. That will let you see how much memory is in use. If you have everything set up properly, you should be able to hit just over 2 GB of memory usage before you get a memory error.

 

[GunT]

Also ask them to clean up the Temp folder. Check out the faq559-884 by Scott Baugh.

And moreover reintialize the memory by minimizing the SolidWorks before you open up the document. In this way you will get around the memory accumulation problem.

Regards

 

[PMcGowan]

When the user had 1.25GB of memory, he attempted to save the drawing and sent me a screen shot of the task manager. The CPU Usage spiked all the way up, the memory showed Physical Memory total at 1310000, Availible at 31332 and system cache at 316828. The kernal memory was total 85264, paged 76084 and nonpaged 9180. This was right after his memory error and SW closed on him.
This user now has 2.25GB of memory and is having the same problems. He is running 2000 SP2.
Both of my users (the one with 2000 and XP) have the same problems with the same drawings.
The way I see it is it is not a PC problem but an application issue.
Is it possible we have something set up in Solid Works wrong? A setting possibly?
They have lost so much time with these errors, I think we all are about to lose our minds as well

 

[PMcGowan]

My guys here are very good about cleaning out their Temp folders But I think I will provide them with that Bat file anyway. I also provided them with DiskKeeper to defrag everyday.

 

[PDMAdmin]

If you're working with large files/assemblies, don't even think of using Windows 2000. It's not up to the task. You can only use the 3GB option in XP. CPU spiking is not an issue; only the total memory usage is. What exactly does the memory error say when it happens?

 

[PMcGowan]

Error is a SolidWorks Error:

SolidWorks is unable to obtain required memory.

Please attempt to free some memory and then press retry, or press Cancel to terminate your SolidWorks session.

No matter what they do at this point, is closes out and they lose what ever changes they made to the drawing.

 

[SBaugh]

Possilby Bad memory Chip(s)

Regards,

Scott Baugh, CSWP

http://www.scottjbaugh.com

faq731-376

 

[PDMAdmin]

I agree with Scott. You are getting the standard error that occurs when you run out of memory, but you should be well over 2 GB of usage before you get that error, as long as you're running XP with the 3GB option and sufficient virtual memory.

 

[PMcGowan]

Unfortunately, I have swapped the memory chips, and that was no help. I know technically I should not be getting these errors, but we are. According to what I have read and who I have spoken to, things should be running smoothly. I guess the only thing we can do is upgrade SW to 2006 SP1 and hope that works.

 

[J-C]

I don't believe any one application can use more than 1.2gb of memory, no matter how much the machine has. 32bit windows application limit. Though Winxp may increase to this to around 1.4gb I think.

So it looks like when Solidworks gets to that limit, it dies. We had the same issue running UG motion analysis. After UG itself used up the 1.2 or 1.3 gb, it croaked.

The way around this is 64 bit windows with 64 bit Solidworks. Or reduce the complexity of drawing and/or assembly to reduce the ammount of memory used. This involves simplifying sub-assemblies and complex parts through the use of configurations. Or large assembly drawings with multiple sheets could be save as separate files for each sheet or group of sheets.



Jason

UG NX2.02.2 on Win2000 SP3
SolidWorks 2005 SP5.0 on WinXP SP2
SolidWorks 2006 SP1.0 on WinXP SP2

 

[SBaugh]

Check out this link:

http://blogs.msdn.com/carmencr/archive/2004/08/03/207161.aspx

THere is an app at Microsoft that you can DL and install and it will help you dianose if your RAM is good or bad. I can't find the link right now though or I would post it.

Regards,

Scott Baugh, CSWP

http://www.scottjbaugh.com

faq731-376

 

[PDMAdmin]

http://oca.microsoft.com/en/windiag.asp

 

[EEnd]

You’ve said that this is happening on more than one machine and that they even have different operating systems. With this in mind, you would have to be extremely unlucky for the problem to be faulty RAM chips.

Is the error occurring while saving the file or trying to check it into the vault? If your users are trying the combined save and check in, have them save the file and then try to check it in.

Eric

 

[PMcGowan]

I sat with them and watched the process. Before they check into the vault it requires them to save it. At this point they are saving it to there Hard Drive. If they are lucky, it will save. If it saves they normally can get it into the vault.
Eric- with my luck I don't rule anything out

The drawings and assemblies are complex, and to redo these would take an extreme amount of time.

Does the 64-Bit really solve some of these problems? The machines are very costly and the CIO is very weary of spending the money.

 

[SBaugh]

The only thing 64-bit is going to do is allow you to access more memory; there will not be a large speed increase.

I know some of you will disagree with me, but I bet if you check the numbers you will see that if it's faster, it's not by a whole lot.

64-bit SW is even released yet and won't be until the beginning of next year. So you will have to wait that long before 64-bit SW is released. 64-bit Systems and OS will not help you without having the CAD app running 64-bit as well.

You are going to have to have your users dumb down their models, or maybe the problem is in the way they are building them. Maybe their technique is not the way SW would require them to build it. If not then they maybe making a portion of the part with 3 features, but if they knew SW better they could make it in 1 feature. This would cut down on time too load the models. As for assemblies, maybe there are to many mates per part and this is causing slow times. Maybe there are in-contexted relationships this will cause slow downs. Maybe you have complex DT in the parts and assemblies, this will cause it to slow down as well. The incorrect Video card and drivers will cause slow downs.

I think most of your users problems are not with systems, but design intent and just the overall users ability to design using SW. Not saying they cannot design, just with SW you have to think different before the Design is started.

I am not sure if you have went through the FAQ's here or not so see below some FAQ's written:

faq559-871
faq559-1094

Regards,

Scott Baugh, CSWP

http://www.scottjbaugh.com

faq731-376