[Info-vax] Problem with RWMPB

[Bob Gezelter]

On Oct 8, 4:09 am, "Ian Dean" <ian.d.d... at baesystems.com> wrote:
> Hi,
>     Whilst running an image, it hangs and shows a status of RWMPB (Modified
> page writer busy).
>
>     Can someone explain (in simplish terms) what is causing this and what
> actions I can take to overcome this?
>
> Regards,
>     Ian

Ian,

As has been noted, RWMPB means that a page fault has occurred, and the
swapper is in the process of adding the needed page to the set of
pages currently available to the process. If the process has available
resources, and the page is already available in memory, the time in
RWMPB (for any individual such occurrence) is infinitesimal. If the
page is not immediately available, or memory to hold the page is not
immediately available, the process takes longer and is more time
consuming (e.g., another presently memory-resident page may need to
written to mass storage).

Needless to say, large volumes of page faults differ from the
preceding description only in scale.

The causes of large amounts of page faulting can be many, including:
- insufficient process/account quotas
- insufficient physical memory
- poor choice of implementation strategy

The first two causes are addressable by the system manager, or the
user running the program. The user can increase the working set of the
process using the SET WORKING_SET command. The system manager can
adjust the account's paging quotas (using the AUTHORIZE utility or
setting the batch queue overrides on user working set limits) or
consider the possibility of increasing the physical memory installed
on the system.

The third reason requires an examination of the code and data
structures implemented by the program. This is somewhat more involved,
but it also potentially has a far larger payoff. Virtual memory uses
physical memory to simulate the presence of a far larger main memory.
This removes much of the worry for programmers at the cost of
increasing the work required of the operating system. On balance, this
trade-off is generally highly productive.

However, if the mechanism is used excessively, poor performance is the
result. Consider a case that I dealt with many years ago. A user noted
that his job was page faulting excessively. Successive increases in
quotas had no effect. The program code was known to be modest in size,
with some data areas that in some cases could grow to significant
size. However, the page faulting was occurring even on small test
cases that should have used only modest amounts of memory.

When the code was examined, the program was found to allocate virtual
memory for the largest problem, initialize the data structures
throughout, and then do its actual work. This was common practice on
non virtual systems, and had a benefit of ensuring that a data
structure was initialized before it was first used. On a system with
virtual storage, it is safe and without consequence for small data
structures, and catastrophic (in the context of performance) for very
large data structures.

Needless to say, small changes to the way in which storage was managed
had a significant impact on the amount of page faulting.

More recently, I have seen examples of programs that increase their
paging rates as running time increases. Most often, these programs
have some form of memory leak that gradually increases their active
pages, thus increasing paging. This also requires a look at the
sources, although the problem is often quite a bit more subtle than
the program that explicitly initializes entire large data structures.

Needless to say, most focus on the first two possibilities, and the
third is often omitted. In their defense, I will note that the first
two cases are common, particularly the case of the quota or working
set values being too low. I caution clients to always be conscious of
the third possibility as the cost of an error can be extremely high.

I hope that the above is helpful. If I have been unclear, please let
me know.

- Bob Gezelter, http://www.rlgsc.com