Comments

rmack350 wrote on 3/5/2006, 12:10 PM
Sure. If your virtual memory usage keeps rising as you work then that's a problem. You can usually stop this by lowering your preview RAM setting.

Virtual memory usage should top out and stay there if the ram preview setting is not set too high.

Rob Mack
Grazie wrote on 3/5/2006, 12:29 PM
. .and the other method to reduce usage is to, DUST them fans!!! G
Widetrack wrote on 3/5/2006, 1:04 PM
What determines where VM tops out? does it depend on the amount of processing Vegas has to do?

right now, Mine's jumping up and down around 973,300. I set up 3000MB of VM on each of my 2 internal disks.

And does anyone know what "Page Faluts" are all about? I've got about 19 million of them.
Widetrack wrote on 3/5/2006, 1:06 PM
My fans made too much noise, so I just stuck a fork in there to keep them quiet
GenJerDan wrote on 3/5/2006, 1:58 PM
Page faults are misnamed, or at least misleading. They're not a bad thing...they're normal operation. They're just memory reads. (But if you have a zillion of them, it might be an indication you need more memory...real or virtual.)

Now, the bad one you have to watch out for is an "invalid page fault". That's when the OS goes looking for a chunk of memory and attempts to read one that doesn't exist (or similar actual errors).

On the other hand... an invalid page fault will most likely crash the OS, or at least the app, so you'll definitely notice something is wrong. ;-)
Widetrack wrote on 3/5/2006, 3:49 PM
Not a zillion, but as the rendeer completet i'm at 46,842,750 and fluctuating wildly.

Mem usage is down to 775,940 and it's beginnig to look like this one's going to finish. I did it in a newly re-installed 6.0b and it is bigger and with as many nested vegs as the attempts that failed in 6.0d.

Wish I knew what to do at this point.
dpetto wrote on 3/6/2006, 6:56 AM
What kind of fork, plastic or metal??? I would think resonant retrospective continuity could be an issue with metal.
Widetrack wrote on 3/6/2006, 8:04 AM
DOH!

So THAT'S where that high, metallic A# whine is coming from!

Better go to plastic.
GenJerDan wrote on 3/7/2006, 5:45 AM
What I would do is remove everything from the pagefile drive(s), kill the page file(s), then put it back at the static size. Then put the "real" files back.

Whether this will help or not...I don't know. But it's what I would do. (And DO do occasionally, just for S&G)
Jayster wrote on 3/7/2006, 8:42 AM
There are lots of posts in this forum on this and similar topics.. One thing they'll point out is that Windows' 32 bit operating systems generally limit applications to 2 GB of address space (ram + VM). An app that hits this limit will croak, regardless of how much physical RAM or swap file you have available. There are some workarounds (like a /3GB swtich in boot.ini), but apparently (?) only applications that were compiled with particular flags will make use of the additional address space.

Other forum entries have highlighted that plopping lots of still images at huge resolutions will consume a lot of memory. You can't display all the pixels of a whopping 6 megapixel still to present on a TV screen, so many posters will tell you to downres those files before you put them into Vegas.

These are just highlights. I'd recommend searching this forum for more detail...
Widetrack wrote on 3/7/2006, 10:02 AM
Dan:

This sounds like a good technique. Can you please be more specific?

What exactly do I remove from the page file drives?

How do I kill the page files?

Put the real files back means setting the PF size to about 3K, right?

Thank you.

Widetrack wrote on 3/7/2006, 10:16 AM
Jay

You are on the money. In the stills-intensive programs I've done lately, I had to downres stills down to DV/NTSC specs. They looked as good as anything you see on TV, IMHO.

My current difficulty is that 6.0d is choking on an edited-down version, using the same stills that worked fine in 6.0c and, as I just found out, works fine in 6.0b.

I've been talking to Sony Tech Support to resolve this, and they're trying.