Primary and secondary pagefiles

[Guy W. Noce]

Tell me if this sounds like a good thing to do:

Primary pagefiles on a local disk, along with swapfile, possibly on a second local disk.

Rename and use the existing tiny one on the system disk as a secondary pagefile.

The reasons for doing the second thing is to have a pagefile in place in case the local disk fails. The system disk is on a high availability SAN.

Would the system default to the secondary pagefile should I somehow lose the single spindle local disk?

Thanks!--Guy

[Jefferson Humber · Accepted solution]

Guy,

If you have two pagefiles defined the system will use them both.

I have two defined on my clusters, one on the system disk, the second on a secondary disk. Both are served by SAN, both sized equally.

I believe I'm right in saying that if you loose a pagefile whilst the system is running, then the system will not be happy to say the least i.e will hang.

Jeff

[Thomas Ritter]

Guy, can assure you based on my experience, you loss a pagefile the system is dead. In a cluster you could bring down the lot. For pagefile work have a redundant disk configuration to shield your self from such failures. Either have host based shadowed disk or some controller based mirroring.

2 cents.

[Karl Rohwedder]

The recommendation was to use pagefiles of equal size, not a small primary one and a big secondary.
We mount our pagefile during boot on a 2nd disk and, if that fails, use a backup file on the system disk.


regards Kalle

[Ian Miller.]

Equal size pagefiles is now the recommendation. If you lose the disk containing a pagefile then any process that has pages in that pagefile can hang. Each process can use multiple pagefiles.
Having some sort of protection for your pagefile disk (RAID etc) is recommended. It is not required to have a pagefile on the system disk.

[Jeff Chisholm]

The notion of 'primary' and 'secondary' isn't really relevant. The 'primary' files get installed automatically at boot time if they have the right names and live in the right place. Other files get installed by code you've added to procedures like sypagswpfiles.com

If you've got more than a couple of cluster nodes sharing the system disk, then that's no place for a pagefile. Some system disks on standalone systems are really popular too, your mileage may vary.

All files the same size? Not a requirement. VMS load balances multiple files quite well under most conditions. Having a tiny file and a very large file isn't a good idea. The idea is to spread the pagefile IO evenly over several spindles to boost performance.

You can boot without any pagefile at all. The system will live until a process needs to pagefault, at which point it will crash. If you have a lot of memory this could be days or weeks away :^) BADPRCPGFLC bugcheck.

If the disk holding one of your pagefiles fails, you might as well shut down. Any process that was using this pagefile will hang. Or you might get a fatal bugcheck type=SSRVEXCEPT with a reason=444 for 'page read error' if you had a pagefile IO in progress.

Put the pagefile on a highly available disk and keep an eye on it for a few days. Chances are you'll have lots of free memory, and you won't be paging much anyway.

If your 'highly available' disk is also a 'really popular' disk, and if your pagefile gets a lot of use, you'll want to move it to a quiet spindle or volume set.

Single points of failure can be avoided.

[Thomas Ritter]

Prespective: a long time ago free disk space was very expensive. Not so these days. We fully allocated 4 local SCSI disks on each node for pagefile work. No need to make precise calulations. Just make the files big and monitor to make sure there big enough. Spend your limited system admin resources on more productive task.

[Guy Peleg]

Hi Guy,

As mentioned here before better not lose
the disk the pagefile resides on.

When a process logs into the system it
maps all available pagefiles and will
attempt to spread it's paging requirements
across all files.

If you attempt to read a page from a bad
pagefiles you'll get bad results....how
bad of results? depends how bad the page
file ;-)

The application can hang if the disk goes
into mount verify waiting for the disk
become available again. The system can crash
if it hits an error like 0x444
(PAGRDERR)in kernel mode.

Bottom line...make sure the pagefile
lives on a redundant disk...or better
yet, buy more memory and avoid paging ;-)

Guy Peleg
(Now that there is another "Guy" on the
ITRC I'll have to append my last
name...nothing is simple these days ;-)

[comarow]

Nice to see you Guy.... either one.

If the years I've been doing performance calls, things have really changed. I think many people worry about the locations of their page file too much these days.

Back in older days, with less memory and slower systems, the need for virtual memory was often much greater, and the capability
of the system disk to handle the load of paging was greatly reduced.


Before people worry so much about the locations of their pagefile, it is often really has no effect.

Thus, if a VAX pagefile needed to do 30 or more I/Os a second on RA disks, it was essential to move those I/Os to another or multiple disks.


If the system is not doing a lot of actual I/Os to the pagefile, what difference does it really make? When you do $monitor page, looking in the average column for page read
I/O rate and more importantly, page write I/O rate are the number even worth speaking about?

Typically, I rarely see memory rich systems today with any significant number of read I/Os, and usually, write I/Os may be virtually non-existent.

That said, I always wonder why the autogen developers increase the page file size when people add memory, when generally, the need for page file useage will be reduced?


That said, the single biggest cause of hangs is when a system runs out of page file space. A simple $show memory/file will show page file useage.

The most common reason systems run out of page file space? For some reason, the customer runs autogen, and it "wants" to create a larger pagefile. Suppose the system had a 400,000 block pagefile, but autogen decides the system needes a 500,000 block pagefile.
Autogen tries to create the pagefile, but on an old system disk is badly fragmented. While attempting to create the new larger pagefile, system quits, and instead of creating the larger page file, it creates a tiny page file! Instead of deleting the new version, there is some error message buried in all the messages.

Consequently, I prefer that people put a
pagefile=0
swapfile=0
in their modparams.dat. This will protect the systems from the above happening.

This move the responsiblity of sizing the pagefile back to the systems mangler.

[Jan van den Ende]

Bob (comarow)

if you ever wanted a posting seconded:

THIS is one I agree the full 100,000 % of!

Proost.

Have one on me.

jpe