Pagefile sizes

[Malcolm Wade]

So it's a simple question; if you have the need for multiple pagefile files (due to limited system disk space) is it better to keep them all the same size or should I stick with a small primary pagefile on the system disk and just create a (say) 4 times bigger one elsewhere?

Not such a big issue anymore from a system disk space but I'm just interested. OpenVMS Systems Managers Guide Volume 2 has a good chapter re: pagefile space but not wether it's better to keep them all an even size or not.

[John Gillings · Accepted solution]

Malcolm,

I don't think page file sizes are much of a concern any more. The old rules of thumb of balanced size and keeping them 50% free just aren't relevant in today's environments.

As long as you've got a few 100K blocks free across all your installed files, there shouldn't be any problems. As of V7.3, the number of pagefiles supported has increased substantially and the algorithms for balancing loads have improved significantly.

With the real cost of disk space today, there's no financial excuse for any system to ever fail for lack of a few dollars worth of page file space (on the other hand, many systems I see have plenty of page file space, but literally NEVER use it!)

Personally I tend to create small to moderate sized page and swap files on the system disk, but for normal production use RENAME them to to "SPARE_PAGEFILE.SYS" or something that will prevent them from being installed by default during booting. The "real" page and swap file(s) is/are on an/other disk(s) entirely.

This means you won't have paging I/O interfering with system disk I/O, but the files are there to be used after a RENAME for upgrades. If you ever get tight on pagefile space, you can MCR SYSGEN INSTALL them very quickly, or they can be deleted to recover space immediately if you get into a system disk space crisis.

[Wim Van den Wyngaert]

Note that a processes will stay within the pagefile in which it started. So, if you have processes that slowly allocate lots of memory, you need big pagefiles. Since you don't know in which pagefile you end up, each has to be able to carry all the processes.

We had this problem on a node with 512 MB. We solved it by creating 1 big pagefile of 4GB.

Wim

[David B Sneddon]

Wim,

It is my understanding that a process may have
pages spread across up to 4 pagefiles.

Dave

[Jan van den Ende]

Malcolm,

I tend to agree much with John:

(on the other hand, many systems I see have plenty of page file space, but literally NEVER use it!)

mostly because I think his argument about disk prices is also valid for internal memory. And if you really ARE using the pagefile for paging, the difference in time required to access pagefile pages vs. memory pages would soon lead to allocation of the required budget!

Wim:

So, if you have processes that slowly allocate lots of memory,

... and never accesses pagefile pages again, I presume?
Would that not be a clear sign of a process that keeps doing memory allocations without deallocs?
I am really hard pressed to find a situation where that is truely needed. Usually I would consider this a case of bad programming, some kind of memory leak.

Then again, it probably is without your control, some third party package? Maybe even ported from (?).


fwie,

Proost.

Have one on me.

jpe

[Malcolm Wade]

We might have gone a bit off track here although I posed this question as a direct result of an application issue which seemed to need more pagefile than I had and I needed to add another, larger pagefile without expanding my system disk via the unload/resize/reload mechanism.

As it turns out the application was bouncing off max virtual address space (2+ million blocks or something of that nature) and will have to be recoded or we'll live with that as a max!

Johns answer was more than sufficient for my needs.

Thanks,
Malcolm

[Ian Miller.]

Malcom, it sounds like you will look forward to a future version of VMS being able to fully use the P2 region of the virtual address range which gets you away from the current limits on P0.

In the mean time I guess you have to redesign.

[Wim Van den Wyngaert]

Soory Malcom, just finishing the discussion.

David,

Pagefile allocation is done per RSRVPAGCNT pages (default 128). So, if you do a malloc of 1 page, a reservation of 128 pages is done (but you get only 1). But if all the memory in that pagefile is consumed before you can do a seconds malloc, then the malloc will fail because the reserved memory isn't available.

The 4 pagesfiles is true but is only working if there is no memory competition.

Didn't test it on 7+ but on 6.2 it was like this.

Wim

[John Gillings]

Just to clear up some misconceptions...

(Dave Sneddon)
> It is my understanding that a
>process may have pages spread
>across up to 4 pagefiles.

(Wim)
>Note that a processes will stay
>within the pagefile in which it started

As of V7.3, neither of these statements are true. Also the maximum size of an individual page file has been increased. SYSGEN parameters PAGFILCNT and SWPFILCNT are obsolete.

A system may have up to 254 page & swap files and any individual process can use ANY OR ALL pagefiles! Including page files installed after process creation. Page files are load balanced according to free space.

You can also DEINSTALL a page file which will stop further use. Eventually it can be expected that processes will migrate to active pagefiles (but at the moment OpenVMS doesn't actively chase processes out).

[Malcolm Wade]

All answer now. Thanks to all.