|
HP OpenVMS Systemsask the wizard |
|
The Question is: The MPW_WRTCLUSTER system parameter defines the size of a page file write used by the VMS Modified Page Writer when flushing pages from the Modified Page List (MPL). Our current understanding is that VMS will scan the MPL to find the number of pages spec ified by this parameter, and map them into a contiguous virtual address space, before invoking the system routine that writes to disk. The routine that performs the write to a page file may break the I/O request into multiple writes depending upon a numb er of factors (according to "VMS Internals and Data Structures V5.2"). On a VAX, the default value for MPW_WRTCLUSER is 120 pages of 512 bytes/page. On Alpha, the default value for MPW_WRTCLUSTER is 64 pages of 8196 bytes/page. We have raised MPW_WRTCLUSTER on one of our Alpha system (8400 4GB)from 120 to 240 Alpha pages in an attempt to more quickly flush pages to the page files. Never-the-less, we continue to experience processes stalling in Resource Wait/Modified Pagewriter Busy (RWMPB) state with the Page Write I/O Rate (as displayed by the Monitor Page command) very low. MPW_HILIMIT is set to 48000 to allow a large "buffer" before processes start stalling at MPW_WAITLIMIT (set to max value of 65535). The theory being that it's better to start writing sooner. We want to know if the time spent by VMS to locate and map 240 candidate pages for flushing to disk, coupled with the long service time to write 3,840 disk blocks (240 * 16) or ~1.9 Megabytes, is reducing the throughput of the Modified Page Writer. In other words, might we achieve faster flushing of the Modified Page List by using a smaller value for MPW_WRTCLUSTER, such as the default value of 64 SYSGEN> SHOW MPW Parameter Name Current MPW_WRTCLUSTER 240 MPW_HILIMIT 48000 MPW_LOLIMIT 2010 MPW_IOLIMIT 8 MPW_PRIO 10 MPW_THRESH 4020 MPW_WAITLIMIT 65535 MPW_LOWAITLIMIT 65295 The Answer is :
Without a much closer look at what the system is actually doing here,
the answer from the OpenVMS Wizard is a firm "it depends".
Considerations include:
- What is the application doing; it appears to be generating a huge
number of modified pages. What is the page read/write ratio?
Could more memory or larger working sets help here?
- How long are processes stalling in RWMPB? What is the occasion?
The OpenVMS Wizard has seen RWMPB "stall" situations when large
pagefile-backed sections are deleted. (Eg: when the last process
closes a file with large numbers of global buffers enabled.)
OpenVMS formerly only noticed that the world wasn't interested in
this data only after most of it had been carefully saved to the
pagefile. V7.2 has a change that can avoid unnecessarily writing
all of this data in many cases. So far, the OpenVMS Wizard is
unaware of a request to port this back to V7.1 or V6.2, but that
might be an option if there is enough call for the change.
- What is the I/O configuration? Specifically, if you are using SCSI
disks, the maximum transfer size used to be 127 blocks -- not quite
8 pages. Some controllers will allow a larger I/O size starting in
OpenVMS V7.2. But in the past -- and certainly in V6.2 -- this could
lead to large numbers of split I/Os, which are about the slowest
possible way to get data to disk: write some, wait 'til it's written,
write some more ...
You might have better luck using pagefiles on multiple spindles and a
larger MPW_IOLIMIT value.
- As of OpenVMS V7.0, MPW_WAITLIMIT and MPW_LOWAITLIMIT are no longer
limited to 32 KB.
Adjusting these values might also help.
In summary: multiple, roughly equally sized, large and contiguous pagefiles
distributed over multiple disks and combined with a large MPW_IOLIMIT (at
least three per disk) are probably the best configuration. This should
allow the controller or disk to do some performance optimizations. The
OpenVMS Wizard would avoid using huge values for MPW_WRTCLUSTER.
|