CAD Forum

Summary:
Add RAM won't solve SW out of memory problem.
Increase pagefile size will.


I got this while saving bodies out of an import file with 1000 bodies: RAM use was only half and only SW closed.
So I start another import (500 bodies) and watch memory use: Notice SW has 13GB committed and Windows show 41.4GB.
Committed go up slowly and I let it run overnight.

It didn't crash and total committed is 58GB with SW 18GB. Commit is when a program ask Windows for a block of memory.
So something asked Windows for 58GB which most of it is SW because it went down when SW is closed.
Committed doesn't mean used. It means Windows allocated "memory address" for that program, or reserved memory.
Total allowable "committed" is RAM + pagefile.
You can see I have 80GB = 16GB RAM + 64GB pagefile

Since SW process only show 18GB committed with 6GB RAM free, I'll say SW keep asking for RAM which it never used.

I'll say the out of memory earlier was because SW asked for more then 80GB and Windows told it no.
Instead of releasing what it allocated and didn't use, it shut itself down.

I'll run the 1000 bodies again tonight. I've add another 64GB to pagefile on another HD.
144GB on the last screenshot. SW didn't release anything even I went and change pagefile size in Windows

Let see how it looks tomorrow.

This is for my recommendation of having a large enough pagefile so SW won't crash.
The usual recommendation was 4x RAM. Some even turn it off believing 16GB or 32GB RAM is enough.
They're correct since SW only has a 3GB working set but asked for over 40GB from Windows.

This also explain why adding RAM won't resolve "running out of memory".

If you want an headache, read this:
https://superuser.com/questions/1174229 ... windows-10

The most important part:

When commit charge fills up and windows starts asking me to close things, most of the time physical memory is at around 60%. This seems horribly inefficient.

It isn't that Windows is being inefficient. It's the apps you're running. They're committing a lot more v.a.s. than they're actually using.

Wow, how long have you been trouble shooting this Fred?

When I come in office next week I might have some little stuff to add to this.

It started yesterday.
Took more time to organise and type it out.
Lots of time to think when you're making subassemblies from a 500 parts assembly.
That's why I hate multibody. People don't set it up correctly and parts are import1 import 2 .....
1 weldment, 1 machined. 2 different part. So I end up with 4 import1 to import1000.

Will run the 1000 part one tonight. Hope it won't crash.

Ooof, geez looks like you're cleaning up someone's mess

Its not really a mess. It became a mess when export and import.
If I don't get the files name right, it will be a mess.
We did one set Rev A. Its updated to B. Customer order Rev C without model.
We quote and order material from A. Need to order ASAP because material price is going up 4% a day.
So we're manually comparing Rev C drawing to Rev B model to order Rev A material.
Someone just don't realize the mistakes gonna cause more then 4%.

Its a 160in tall gearbox housing. Looks like one in 11 out.

Ran the Save Bodies with "Derive resulting parts from similar bodies or cut list" on the 1000 bodies part last.
It finished with 41GB committed this morning.
SW show committed 12.6GB and used 3GB. Will try another one with that off next week.

Hi Frederic

Why do you export the whole thing. Why not break it down first and export it in chunks.
For large and difficult files I use the delete body feature, selection sets in combination with save-as-selected body function.
Other handy tools. Insert weldment feature and let SW collect all identical bodies.
Just a few thoughts. Hard to say what applies in your case. Not enough info. There are more tricks you could use.
Filter tree, macro to traverse bodies by name...etc.

Good luck anyways....

Elmar

Because I'm testing why SW run out of memory.
SW used 3GB of RAM but asking Windows for 40GB and crash.

This is an imported file with 1000 bodies.
Bodies are named import1 to import1011.
Because its faster working in assembly. Easier to select parts and move them into subassembly.
Working in multibody part is very slow. Even just select and delete bodies is slow.

Run save bodies on the 1000 bodies again last night: SW used 3.3GB RAM, asked for 19.3GB paged. Got a total of 63GB paged allocated. 14GB was before SW start.
So SW don't NEED 32GB of RAM. It NEED 100GB pagefile/swapfile.

Quelle surprise.

In short, what lots of us have been thinking over the years is true. The program is in dire need of an overhaul because the sloppy and lazy programming of patching the patches with more patched patches has led to a program that can't efficiently use the hardware that it's supposed to run on.

But hey, don't blame it on Gian Paolo who's only been the CEO for 6 years and another 3 years being VP of R&D. I'm sure that any year now you'll see a real change and a massive improvement... really....any year... well perhaps in a few decades.

Peter De Vlieger wrote: ↑Wed May 05, 2021 9:11 am Quelle surprise.

In short, what lots of us have been thinking over the years is true. The program is in dire need of an overhaul because the sloppy and lazy programming of patching the patches with more patched patches has led to a program that can't efficiently use the hardware that it's supposed to run on.

But hey, don't blame it on Gian Paolo who's only been the CEO for 6 years and another 3 years being VP of R&D. I'm sure that any year now you'll see a real change and a massive improvement... really....any year... well perhaps in a few decades.

I am afraid Dassault call that changes as 3DEXPERIENCE on cloud...

Peter De Vlieger wrote: ↑Wed May 05, 2021 9:11 am I'm sure that any year now you'll see a real change and a massive improvement... really....any year... well perhaps in a few decades.

Too true, unfortunately

Have you submitted the file and the reproduction process to SOLIDWORKS technical support?
Maybe they can figure out the root cause of the unusual behavior.

They already know. It is one of the following:

Unsupported Hardware
Corrupt Registry
Software needs to be re-installed
...

User need training.
Don't open large import.
Don't make large assembly.
Don't use SW.

You must be trying to do something crazy like using mates..........or making an assembly with more than three components.........

User today clocked a high score of 11.7GB memory used for SW2021, with another 3GB going to Explorer/Solidworks PDM. Just had two SLDDRWs open. Time to go memory leak hunting.

linsd wrote: ↑Tue May 11, 2021 4:27 am Have you submitted the file and the reproduction process to SOLIDWORKS technical support?
Maybe they can figure out the root cause of the unusual behavior.

Hey, I think you forgot to use purple:
Have you submitted the file and the reproduction process to SOLIDWORKS technical support?
Maybe they can figure out the root cause of the unusual behavior.

@Frederick_Law
Data in RAM memory is the fastest, paged data is slower, could be much slower. So if RAM is not used to the available amount, speed is not optimised?

Frank_Oostendorp wrote: ↑Wed May 26, 2021 4:05 am @Frederick_Law
Data in RAM memory is the fastest, paged data is slower, could be much slower. So if RAM is not used to the available amount, speed is not optimised?

Technically, yes. We have no idea what is stored in pagefile.
Problem is SW show 10GB committed. Windows say 60GB. So SW lost 50GB.

Repost from the SwYmP because the platform can't view photo properly:
Users had reported RX complaining low memory even with 32GB RAM install.

How could SW see low memory before any file is opened?

Changing Windows swap file to fixed 64GB will remove that.
While working on a STEP import with 1000 part SW crashed will low memory. With 6GB free RAM.

This is a recreate of what happened. I can repeat this with different large STEP files. So feel free to test it yourself.
Very simple steps.
Import STEP, break link, Save Body, Create Assembly. Turn Off "Derive resulting parts from similar bodies" for maximum effect.  I have it on for a quick example.
Watch Committed grow. My highest was 77GB. My pagefiles size is 64GB + 64GB.

Start with SW fresh start, 14GB committed, 7.3GB free RAM

SW used 253MB Private Byte 396MB Working Set After Save Body, 44GB committed, 5.3GB free RAM.

SW used 12GB Private Byte 3GB Working Set

Committed increase 44 - 14 = 30GB  SW used 12+3 = 15GB  RAM used 7.3-5.3 = 2GB

Extra in committed 30-15-2 = 13GB (not sure if committed include RAM used, assuming it is) Close all open files in SW, 43GB committed, 6.2GB free RAM

We free 1GB RAM and 1GB committed.  So committed include RAM
SW will not free the committed until it's closed.
Since closing SW release all committed, they are allocated by SW
Reopen SW, back to where we started.  So it is not a problem with other running program. I also observed committed grow slowly during the day with every file opened.  Closing the files does not recover all committed memory.
That's why user need to restart SW.

Double screenshot is killing this forum too.

Frederick_Law wrote: ↑Fri May 28, 2021 10:40 am Double screenshot is killing this forum too.

Your double screen shots work better if you have a big landscape display. Maybe you could split those up if you want people to see them.

matt wrote: ↑Fri May 28, 2021 11:06 am Your double screen shots work better if you have a big landscape display. Maybe you could split those up if you want people to see them.

I don't understand the "double screen shot" problem. They look fine to me, I think.

If I get Chrome to span both screens, I can read it.
Probably will keep them single screen.

bnemec
Can't scroll up down or side way to read the text when browser is on single screen.

Frederick_Law wrote: ↑Fri May 28, 2021 11:43 am If I get Chrome to span both screens, I can read it.
Probably will keep them single screen.

bnemec
Can't scroll up down or side way to read the text when browser is on single screen.

I see. I'm slow. I have the habit of right click, "open image in new tab" when I want more detail than a preview. As you say, zoom and pan would be sweet in the image viewer.

Even right click doesn't work in the SwYmP. It open a low res compressed one.

Just RMB on the picture and select "Open Link in New Tab". Then you have full resolution PLUS zoom and pan.

I was looking for the bottom scroll bar.
I was SwYmPed.