Hard VS. Soft Page Faults

[Chaim Budnick]

Is there a way using MONITOR to be able to differentiate between hard/soft page faults?

Chaim

[Uwe Zessin · Accepted solution]

Yes.
http://h71000.www7.hp.com/doc/72final/6491/6491pro_006.html#index_x_227

And when using "MONITOR SYSTEM", there is a vertical bar (|) that separates the hard and soft faults.

[Chaim Budnick]

Which side is hard and which is soft?

Chaim

[Uwe Zessin]

http://h71000.www7.hp.com/doc/732FINAL/6048/6048pro_004.html#index_x_1494

""In the Page Fault segment, the page read I/O rate is indicated by a vertical bar. The bar provides a visual estimate of the proportion of the total page fault rate that caused read I/O operations (the hard fault rate). The hard fault rate appears to the left of the bar.""

[faris_3]

Hi,

- on the monitor page screen the 2nd to 5 th line are hard faults
the 5 next lines are soft faults
(free list to Wrt in Progress)

- on the monitor system screen
under page fault Rate, a vertical bar separates hard faults (left) from soft faults.

hth,
HF

[Chaim Budnick]

Thanks for all the replies !!

There are a large number of page faults (between 300 - 1000), most of which (probably around 90%) are SOFT.

Can this magnitude of soft PFs seriously affect performance?

Chaim

P.S. This is a DSM application

[Uwe Zessin]

It depends on the hardware whether it has enough horse power - 300-1000 does not sound much to me. Soft faults means just shuffling a few pointers around, so this is not has 'bad' has hard faulting. Remember that you will never be able to eliminate all faults - VMS uses the page fault handler to get images into memory - there is not separate program loader.

[Wim Van den Wyngaert]

Chaim,

Try to find out which process is doing it (mon proc/topf). It might be that the working set is too small for what the process is doing or that lots of image activations are done. WS : increase quotas, image act. : try installing them.

Database servers with bad WS quotas can pagefault like crazy.

Wim

[Hein van den Heuvel]

Chaim,

If you need further help, then please attach some sample monitor output in a text files. Concreate numbers help discussing this.

What Wim refers to is notably Global Valid Pagefaults. Those mean that a shared-library/share-buffer-page was in memory, but the process could not 'look' at it yet due to restricted wsquota (or because it had never tried to look at it so far). Increasing WS will not directly increase physical memory usage for this while it will reduce this soft pagefault overhead. (indirectly memory usage may creep up, if for example SORT sees the extra WS and uses it).
A similar reasoning applies to free/modified page list soft faults. Just increase WS!?

If this is an Oracle DB application, you may want to consider RESERVEED MEMORY allowing the SGA to be mapped with huge pages and with no WS charge/usage.


Hope this helps some,
Hein.

[Willem Grooters]

If a program initiliazes (fills) a (large) array with values the wrong way, it can introduce a huge pagefaultrate as well - soft, mostly, but nevertheless choking the system for some time. "the wrong way" depends on the language. IIRC, a FORTRAN will store arrays column by column, so filling it is best done column-by-colunm; doing it row-by-row may introduce huge pagefault-rate, if the array is large enough, it may be 1 pagefualt for each cell)

[Jan van den Ende]

Willem,

just exactly YOUR example demonstrates where Working Set plays its game.
In the modern times of abundant cheap memory, whenever you have an application with your type of needs there is really only ONE good solution: give the process enough Working Set!
.. and if it is REAL big, mind SYSGEN WSMAX to be compliant.
And yes, during the initial fill of your array you will incur a lot of pagefaults.
They are DZRO faults (Demand ZeROed page), which are soft faults.
Any application that will still not fit probably warrants the old "Buy More Memory", more than it has ever been true in the past!

HTH

Cheers.

Have one on me.

Jan

[Uwe Zessin]

Jan,

> .. and if it is REAL big, mind SYSGEN WSMAX to be compliant.

may I remind you that WSMAX is usually MAXed on today's systems (since VMS V6.0) anyway...

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=658938
starting: Aug 8, 2004 04:43:14

[Jan van den Ende]

Uwe,

that indeed is __USUALLY__, but NOT guaranteed...
eg, if AUTOGEN is NOT used to set params, or WSMAX calculation is overruled by MODPARAMS, (maybe because of an old, not removed, setting)

Cheers.

Have one on me.

Jan

[John Gillings]

Chaim,

For detailed page fault stats, use MONITOR PAGE. As Homi pointed out, the ones of interest "soft faults" are the 4 lines after the first 5:

Free List Fault Rate
Modified List Fault Rate
Demand Zero Fault Rate
Global Valid Fault Rate

Generally speaking, if you're seeing significant Free List, Modified List or Global Valid faults, you can probably reduce (or eliminate) them by increasing working set sizes, WITHOUT any affect on real memory consumption. That's because they represent pages pointers being moved around in memory (the pages themselves don't move). Unless your numbers are very high, you're unlikely to see a huge difference in performance, because these faults are very "cheap" - they're really just flipping a few pointers (but then, avoiding the fault costs ZERO, so there is a benefit in tuning them away).

That leaves Demand Zero faults. A high DZRO fault date is usually an indication of a high image activation rate. If you can find the cause and fix it, that may give you a performance boost. For example, calling a program in a DCL loop, feeding it one file name at a time. You may be able to modify the program to accept a list of file names - in other words move the loop to inside the program.

[Lawrence Czlapinski]

Homi, on MON PAGE, line 3, Page Read I/O Rate is the hard page faults.
Chaim,
1. If a process has a lot of page faults and the pages in the working set are more than WSDEF and WSQUOTA, the process will benefit from larger WSDEF and WSQUOTA. I use a modified version of DEC's WORKSET.COM (attached)to measure page faults before and after the change. I start increasing WSDEF and WSQUOTA's for the processes of this type that are page faulting the most.
NOTE: If the process has a working set smaller than WSQUOTA, increasing WSQUOTA won't help.
2. If you have a high demand zero fault rate, on Alphas, you can increase SYSGEN parameter MIN_ZERO_LIST_HI. "On AXP systems, ZERO_LIST_HI is the maximum number of pages zeroed and put on the zeroed page list. This list is used as a cache of pages containing all zeros, which improves the performance of allocating such pages." This can be helpful if you have a lot of system activations since the system can zero the pages before it needs them. I assume it does this when the processor would otherwise be idle.
NOTE: I've found that increasing MIN_ZERO_LIST_HI reduces demand zero soft faults.
Lawrence

[John Gillings]

Lawrence,

>NOTE: I've found that increasing MIN_ZERO_LIST_HI reduces demand zero soft faults.

?!? that sounds very unlikely. For a given workload, the number of DZRO faults should be invariant. Consider activating an image with an array in DZRO pages. The program then traverses the array and exits. The number faults may vary, but the number of DZRO faults must ALWAYS be the same, by definition.

What *might* change is the nett impact of the DZRO faults. Since you keep more pages on the zero list, there are likely to be less cases where a process needs to wait for a zero page to be created. That may result in the MON PAGE stats being reported differently. The only way to reduce demand zero faults is to not request them! They can't be "tuned" away.

The downside of increasing ZERO_LIST_HI is the pages being zeroed need to come from the free list. Once a page has been zeroed, it's no longer available to be faulted back in from the free list. If the page is requested again, the data needs to be read from somewhere, requiring I/O. If that's happening, the negative performance impact would be FAR higher than keeping ZERO_LIST_HI low.

I'd recommend increasing working sets to reduce or eliminate Free List and Modified Page List faults BEFORE adjusting ZERO_LIST_HI.

[faris_3]

Lawrence,

I think the
Page Read I/O Rate is the rate of I/Os resulting from Hard Faults, because more than one page (a cluster) is read on a hard page fault occurrence.

The ratio between page Read Rate and Page Read I/O Rate depends on how many pages
are read per I/O. This depends on the
SYSGEN parameter PFCDEFAULT and/or the page
fault cluster size of the image/file section.