I64 INSTALL /SHARE, process uses more private memory

[Lester Dreckow]

Hi,
After installing /SHARE an image, processes are using more process global pages, as expected, but they are also using significantly more process private pages.

See attached (on the test server, for just one example inquiry transaction).

As the increase in private memory is much more than the saving due to shared memory, this tends to indicate that installing the image may be detrimental - contrary to the normal expectation.

Am I being paranoid? Are there ways, perhaps with SDA, to see what the private memory is attributed to (I'm an SDA novice)?

The application is an in-house Rdb, Decforms, Cobol interactive transactional application. The production system runs approx 330+ of these processes, consuming some 14GB of the 16GB total memory. No problem as such, but XFC cache reduces to the minimum, and page writing occurs at this load.

I am (was) attempting to assess the potential saving in memory, intending to make more available for Rdb global buffers or row caching.

Regards,
Lester

[Lester Dreckow]

Some info from the production system.

[Wim Van den Wyngaert]

On VMS 7.3 I tested the same using isql of Sybase.

On install about 600 pages moved from process memory to global memory. As expected.

Also noted that on each iamge activation I got slightly different values (diff of about about 150 pages, t.i. between 3800 and 3950 pages).

fwiw

Wim

[Wim Van den Wyngaert]

An install with /share=address increased the globalising with about 150 pages. You could try that too (but then all depending images must be install /share=add too).

Note : you must do a remove and install to implement this, not replace.

Wim

[x2084]

As far as I know and as I understand, there is no difference in the behavior on Alpha and I64.

There are a lot of working set dynamics involved, here, which make the working set bigger or get more private pages into the working set.

It's true and it is a wanted effect that pagefaults are handled faster if they are resolved from a global section, which is already in memory. That happens in your case and that happens the same way on Alpha. To my knowledge that can influence how the working set grows and then you can have more pages in the working set, including process private pages.

(p|g)pgcnt are number of pages in the working set, they are not numbers of global or private pages created by INSTALL. In other words, nobody should interpret this as "installing an image creates more private pages used by an image". That was and is not the case on Alpha and is not the case on I64.

[Wim Van den Wyngaert]

May be you should consider decreasing the working set size of the users thus freeing memory for xfc.

If you have availability manager you can reduce the working set size (purge/adjust working set).

Wim

[Hoff]

If you're not seeing significant memory savings from sharing your images (and those savings depend on how much code is involved across however many processes), then you might want to throw some hardware at the problem.

Might be faster to upgrade a few DIMMs, and particularly if you're seeing XFC caching constrained.

That, or toss some processes off the system via batch or via scheduling or swapping or other means.

The rx2620 permits use of 2 GB DIMMs in twelve slots for up to 24 GB physical memory maximum.

I'd include the published HP list price here, but I can't find that right now. Another well-known vendor is quoting US$560 list to fill a two-slot memory bank providing 4 GB aggregate for this rx2620 box; a pair of 2 GB DIMMs. HP undoubtedly has analogous memory offerings.

[John Gillings · Accepted solution]

Hi Lester, long time!

Presumably you're most interested in the nett memory consumption? It can be confusing to calculate for multiple processes.

>SDA, to see what the private memory is
>attributed to

SDA> SHOW PROCESS/IMAGE

shows the ranges of memory associated with particular images.

SDA> SHOW PROCESS/PAGE/SUMMARY

will list all pages (make sure you display 132 wide or send to a file).

You may need to write some code to correlate the two to determine what pages belong to which images.

[Lester Dreckow]

Wim, Hartmut, Hoff, thanks for your comments.

I had not thought of looking at /shared=address. Looks like it moves the image out of P0 space if we needed to.

I certainly understand that the process page counts are the result of paging into the working set as a code-path executes. The tests were done on an otherwise idle system, the results were consistent over several tests.

The economics of adding memory are acknowledged. As a first step I thought we should install the image /shared, but these tests surprised me.

Regards,
Lester

[Lester Dreckow]

Hi John, long time, yes, but I still always appreciate your advice here.

Those SDA commands are exactly what I was looking for (apart from an opinion that install/shared is always no-brainer, or not).

Thanks.

Regards,
Lester