Frequently, P6 does not appear to release XP’s “Page File” usage when closed.    Any way to clear this out without actually rebooting?     (or is this just me?)

I haven't found a way.  But it is a small chunk though that it grabs that I can see. Just 100MB of Physical Memory on my 2GB RAM system.

Do you keep your cached rendered images?  Or do you delete them?  I don't use Poser for rendering.

I'm frequently seeing more than half of my 2.4GB still in use after closing P6 following a render - with only about 40MB of that being the other base system apps.

opps - typo above.

Should have read: -"with only about 400MB, (not 40MB) of that being the other base system apps."  

Sometimes when I exit Vue after a LOOOONNNNGGGGG render, it takes about 15 - 30 seconds before I get back my RAM and swapfile.  But I have to start up Internet Explorer and browse here and check my email or Facebook before XP realizes that it has no RAM and triggers a deallocation.

I could restart the computer, but that takes longer.

Then back to normal.  I will try rendering some LOONNNGGG in Poser 6 and see if XP lets go of RAM afterwards.  I never noticed much resource issues before with Poser because it doesn't grab as much as Vue does.  But right now, I have a huge Vue scene rendering (with Poser imports).  2 hours left to go.

hmmm...  mine (usually, but not always) stays there after closing P6, no matter how long I wait, - until I reboot.  
 
If it is going to release some, it seems to happen within the first minute after closing P6.

Give RAMRush memory optimiser a try. It's freeware but I get on OK with it.

Quote - Frequently, P6 does not appear to release XP’s “Page File” usage when closed.    Any way to clear this out without actually rebooting?     (or is this just me?)

How are you measuring that it's not 'released'? It may not be released immediately but should be dropped if another application calls for the space. Let Windows take care of its pagefile, don't worry, you can't manage it better than it can itself. 

Commit charge is not page file 'useage', it is the amount of space that has been reserved (pageable RAM + pagefile)  rather than the amount that has been written to the pagefile alone.

Quote - Give RAMRush memory optimiser a try.

No such thing as a memory optimiser - it can't do anything that Windows isn't better qualified at doing itself.

Quote - No such thing as a memory optimiser -

The Emperor is naked?   What should I be looking at for more info Magic?

Naked as the day he was born...

All memory 'optimisers' do is drop memory pages thereby seemingly 'freeing' up memory. If you need that stuff then it has to be paged back in from pagefile or memory mapped files. They can't do anything nor manage memory better than Windows does itself - they can't without rewriting the memory manager since that is all they're dealing with.

With regards your pagefile, I wouldn't worry. It'll be freed when required. If there was an inherant memory issue with Poser then I'm sure we'd know about it by now. Leave Windows to manage its memory as it sees fit, i.e. system managed pagefile(s) and leave the memory managers alone.

...system managed, the best option.

 I was once told to set my swapfile to the double size of my physical RAM. I've been doing so for years... Is that totally daft then?

It was a rough recommendation back when RAM was 1GB max probably. Best option is to leave it as system managed and stick a pagefile on each physical drive you have.

Windows can manage its useage best that way and, with multiple drives and pagefiles, it'll make use of I/O counters to see which is the 'best' pagefile to use at a time.

Windows automatically sets your swapfile to double your RAM total if it needs to.  Virtual RAM has been double real RAM since there was virtual RAM.  The catchup was going from 8-bit to 16-bit to 32-bit ,etc, file access.  Buyers could afford more RAM while the OS developers could increase file access size as computers improved.

There's never really been a connection or rule between installed ram and pagefile size, it was just a rough estimate back when ram sizes varied little and were a lot smaller. Leaving Windows manage the size is the best option, it will set an initial size and then, if it needs to increase it, can do so.

I tried RAMRush when I started using Poser 8. I was getting lots of Out of Memory Errors when rendering. System is XP pro, 2GB and Athlon XP 3200+. RAMRush appears to page unused apps out of physical memory a little quicker (either automatically or on demand). Now that Poser is on SR3 I'll have to see how it behaves without RAMRush.

Is there any benefit in setting  fixed Virtual Memory using XPs max recommended settting?

Quote - Is there any benefit in setting  fixed Virtual Memory using XPs max recommended settting?

Only if you are low on hard drive space would you keep Windows from grabbing too much for virtual RAM.  My drive has 8BG left, so I could MAX out the setting if I don't plant to install any huge game like Fallout 3.  I have System Restore turned off to get more drive space.

Slower hard drives will benefit by having the MAX set so that the virtual space is initialized at startup and not have to work at growing/shrinking the size during use.  Helps with less fragging of the drive also.

Just don't turn off virtual RAM though, unless you want to learn a new definition for the word pain.

Quote - Is there any benefit in setting  fixed Virtual Memory using XPs max recommended settting?

Setting a fixed size pagefile (unless overtly large) can only potentially cause you issues.

Windows uses the pagefile to store unbacked memory pages. These are pages that exists nowhere other than in memory, e.g. changes that have been made to a file.

If you set a fixed size and begin to reach that limit then the memory manager is limited in what it can do. It can't page out unbacked store since the pagefile is full, therefore it has to drop memory pages relating to code that is backed on the disk, i.e. program .exe, .dll code etc. e.g. that large document that you have sitting idle in the background that has been changed but hasn't been saved has to be kept in memory since there is no room to page it out to the pagefile. As a result, the performance of other things begin to suffer. When you next need that application code, as part of the application you are running, it has to be paged back in again at the expense of other memory pages that must likewise be dropped in order to keep that document that you haven't saved in memory. Performance suffers because you have limited what the memory manager can do.

If you allow the pagefile to be system managed then the pagefile can be extended - you still get paging but the memory manager can best organise this according to what it thinks you still need and what you don't any more.

Quote - Slower hard drives will benefit by having the MAX set so that the virtual space is initialized at startup and not have to work at growing/shrinking the size during use.

Windows sets a sensible initial fixed size even if set at system managed, it doesn't keep dynamically changing the pagefile size. It'll work within this fixed size until it requires more. If system managed as opposed to manually set, it can add further extents as required.