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

[John Gillings]

>opinion that install/shared is always
>no-brainer, or not

Well, if it were a no-brainer, then all images would be automatically INSTALL/SHAREd ;-) Sorry, you'll need to evaluate the plusses and minuses.

It depends on how much sharing you expect, and how much of the image is shareable. Is the image mostly shareable code, or non-shareable data structures? What is the number of address fixups required? - remember these are per-process if the image isn't installed /SHARE=ADDRESS. Is there sufficient P1 space to use /SHARE=ADDRESS, or which images should be chosen?

If you expect enough sharing, maybe you could consider /RESIDENT? That eliminates address fixups and paging of the shareable stuff, but eats into S0/S1 space, and requires allocation of GH regions. The downside is you may require a reboot to replace a resident image, and you'll need to modify your LINK command. It's really only useful for very stable code. If the system is going to be running this image all the time anyway, why not make it resident?

(I'm not certain if /RESIDENT is applicable to executable images. If it isn't, reLINK the program as a shareable image with a single entry point "MAIN" and build a tiny jacket executable image which calls it).

[x2084]

>>>Well, if it were a no-brainer, then all images would be automatically INSTALL/SHAREd ;-) Sorry, you'll need to evaluate the plusses and >minuses.

True.

>>>What is the number of address fixups required? - remember these are per-process if the image isn't installed /SHARE=ADDRESS. Is there sufficient P1 space to use /SHARE=ADDRESS, or which images should be chosen?

I don't understand. Fixups are per image activation. If an image is installed with shared address data, the fixups are pre-applied. If the image is not activated, the process doesn't use the P1 space. It is just reserved VA space, which you can't use for any other purpose.

But that installed image is only activated, if all the images it depends on are still installed with shared address data (You can not install an image with shared address data if these other images are not installed with shared address data, but you can deinstall these other images afterwords or let logicals point to [newer] versions of these images)

You can install main images with shared address data, they do not use any P1 space, see VMSIMAGES.DAT.

>>>If you expect enough sharing, maybe you could consider /RESIDENT? That eliminates address fixups and paging of the shareable stuff, but eats into S0/S1 space, and requires allocation of GH regions.

Not true.

/RESIDENT alone does not eliminate address fixups.

Take your favorite shareable image, LIBRTL and look at the output of INSTALL LIST/GLOBAL/RESIDENT. You will see the short data segment or linkage section in P1. That's where the fixups are applied to.

LIBRTL is installed WITH shared address data, so no fixups at activation time. But if you leave out the shared addres data, its short data segment or linkage section ends up somewhere in P0 and fixups are applied at activation time.

Also, keep in mind /RESIDENT defaults to /RESIDENT=CODE. So shareable data is not yet made resident.

Also, on I64 starting with 8.3 you can use S2 space for resident code.

>>>The downside is you may require a reboot to replace a resident image, and you'll need to modify your LINK command.

Not true.

By design, resident images can be replaced in a running system. You need more resident memory, if the old image is still in use. Only if you run out of resident memory, then you need to reboot. There were some problems in this area, they are fixed in the current versions Alpha and I64, or will show in the next version of VMS.

Only on Alpha you need a modified the LINK command and relink.

>>> (I'm not certain if /RESIDENT is applicable to executable images. If it isn't, reLINK the program as a shareable image with a single entry point "MAIN" and build a tiny jacket executable image which calls it).

You can install main images with /RESIDENT (I assume your "executable images" refers to images you usually run from DCL, which I here refer to as "main images").

So you don't need to relink your main image as a shareable image. Anyway, it is known, that you can run shareable images as main image. So you don't need an additional jacket.

[John Gillings]

Hartmut,

Thanks for the corrections. Sounds like some of the limitations have been fixed. Does this mean ACTRL patches won't require a reboot any more?

[x2084]

I don't think that an ACRTL patch contains any system image. So I don't see a need for a reboot.

To replace the CRTL, aka DECC$SHR (or what the logical points to), a INSTALL REPLACE is sufficient. In case that the CRTL is in use and that there is not enough resident memory, the image is automatically installed without the /RESIDENT. That means there is a KFE for the new image and all the subsequent image activations for the DECC$SHR will use the new image.

[Lester Dreckow]

John, Hartmut,

Thanks for your interesting comments; helped my understanding of these install options.

Cheers.

[Lester Dreckow]

The SDA commands provided by John helped to explore image mapping to process pages.