Interpreting the show memory/files command

[Trace Trembath]

How do I interpret the show memory/files command? Specifically as it pertains to the size and usage of my pagefile(s).

$sh mem/files
System Memory Resources on 5-SEP-2006 14:27:53.01

Swap File Usage (8KB pages): Index Free Size
DISK$AS12VMS731:[SYS0.SYSEXE]SWAPFILE.SYS
1 1848 1848
DEVVOL:[000000]SWAPFILE1_SRAY5.SYS;1
2 24992 24992

Total size of all swap files: 26840

Paging File Usage (8KB pages): Index Free Size
DEVVOL:[000000]PAGEFILE5_SRAY5.SYS;1
249 37270 37496
DEVVOL:[000000]PAGEFILE4_SRAY5.SYS;2
250 22986 31248
DEVVOL:[000000]PAGEFILE3_SRAY5.SYS;3
251 29160 37496
DEVVOL:[000000]PAGEFILE2_SRAY5.SYS;3
252 29419 37496
DEVVOL:[000000]PAGEFILE_SRAY5.SYS;3
253 29412 37496
DISK$AS12VMS731:[SYS0.SYSEXE]PAGEFILE.SYS
254 29158 37496

Total size of all paging files: 218728
Total committed paging file usage: 1660276
S

I was receiving a page file filling up message earlier for which I created and installed the above pagefile5_sray5.sys.

How do I interpret the sh mem/files command?

Thanks.

Regards,
Trace

[Travis Craig]

Trace,

I'm not sure what part of it you are asking about, but it shows the number of 8KB pages in each file ("Size") and the number that are free ("Free"). The committed page file usage is not the amount in use, but the total that could be used by processes that are running. Here' a description of it from a system manager's manual:

The total committed paging file usage is the number of pages in the system that require pagefile space for paging. It can be bigger than the total number of pagefile pages that are available because it is unlikely that all the required space will be used for paging at one time.

--Travis Craig

[Jeff Chisholm]

The 3 columns of numbers in the SHOW MEM/FILES display for V8.2 and above are 'index' 'free' and 'size'

The general tuning guidelines say that free space should be 50% of total space, or more, in each file. You see each of the files are organized as a singly linked list of packets. If you want to allocate a big chunk, you need to traverse the linked list to find the big ones at the end. If you've got less than 50% free, the file is internally fragmented, you're spending more time than necessary traversing the list.

VMS does a reasonably good job of load balancing multiple files. Having multiple files residing on multiple spindles is a good idea if the pagefiles are very popular. Most of yours appear to be on DEVVOL. All of them have beaucoup free space.

I really can't imagine you getting any sort of 'pagefile filling up' message from this system unless it's coming from a bit of DCL code that needs a V8.2 update. The columns used to be 'free' 'reservable' and 'total' which could be messing you up?

[John Travell]

What no-one has mentioned yet, is that if you are more familiar with the old format than the new, is the pagefile indexing numbers.
They used to count from zero to PAGFILCNT and SWPFILCNT, and you were in trouble if you ever has all pag/swp file slots filled and desperately needed to create another file to avoid a hang...
For a few versions now there has been a static array pointing to pagefile structures, from index 1 going up are swapfiles, and pagefiles are index 254 going down. indexes 0 and 255 are not used.
Heaven forbid the thought that someone could ever run out of pagefile slots now...

[Jeff Chisholm]

Thanks John, I like this way better, since a default of 4 slots for PAGFILCNT wasn't a lot, and raising it required a reboot. 255 should be enough.

I know I wrote some DCL at some point to parse the output from SH MEM/FILES on one of my systems. Since we've changed the output, any code you've written that depends on the old output needs refreshed.

Having the 'reservable' count on the display was useless anyway, IMHO, and just resulted in a lot of needless calls logged to the CSC over the years.

[John Gillings · Accepted solution]

re: Jeff

>The general tuning guidelines say that free space should be 50% of total space, or more, in each file.

This rule of thumb is way out of date! It was reasonable when 100MB was a "large" page file, but today with disk space costing about $1/GB page files should be MUCH MUCH bigger. The idea of insisting that an 8GB page file have 4GB free for "performance" is laughable!

Plucking a number out of the air... I'd be very surprised if anyone could show a measurable performance degradation on any pagefile with more than 15000 pages free.

That said, please review the costs and benefits of investing in sufficient page file space that depletion never happens. In this example, the committed usage is much larger than physical space, but it's still only 13GB in total. Not a huge cost to cover.

It might also be worthwhile for Trace to coalesce the 5 pagefiles on the same disk. The individual files are only 600000 disk blocks, with a total investement of 3,500,000 blocks. Not even 2GB! Downtime and performance lost through inadequate pagefile allocation is MUCH more expensive than disk space.

Note your swap files are not being used at all. Remember, swap files can only be used for swapping. Page files can be used for both paging and swapping. If you're swapping, go buy more memory!