GH_EXEC_CODE

[Douglas Fisher]

We are trying to get more cpu out of our 2 clustered es40's. Autogen suggestes increasing
GH_EXEC_CODE by about 50% from:
Old value was 1024, New value is 1536
Can anyone tell 1. will this help
2. what does this param. do?

Thank You,
Douglas Fisher

[Andy Bustamante · Accepted solution]

Douglas,

SYSGEN> HELP SYS_ GH_EXEC_CODE

Sys_Parameters

GH_EXEC_CODE

(Alpha only) GH_EXEC_CODE specifies the size in pages of the
execlet code granularity hint region.

GH_EXEC_CODE has the AUTOGEN and FEEDBACK attributes.

From "Migrating an Environment from
OpenVMSVAX to OpenVMS Alpha" available at http://h71000.www7.hp.com/doc/73final/documentation/pdf/OVMS_MIG_ENVIRON.pdf?jumpid=reg_R1002_USEN:

On OpenVMS Alpha, you can improve the performance of main images and
shareable images that have been linked with /SHARE and the LINK qualifier
/SECTION_BINDING=(CODE,DATA) by installing them as resident with the
Install utility (INSTALL). The code and read-only data sections of an installed
resident image can reside in granularity hint regions (GHRs) in memory. The
Alpha hardware can consider a set of pages as a single GHR. This GHR can be
mapped by a single page table entry (PTE) in the translation buffer (TB). The
result is an improvement in TB hit rates, resulting in higher performance.
Also, the OpenVMS Alpha executive images are, by default, loaded into GHRs.
The result is an improvement in overall OpenVMS system performance.
These options are not available on OpenVMS VAX systems.
The GHR feature lets OpenVMS split the contents of images and sort the pieces
so that they can be placed with other pieces that have the same page protection
in the same area of memory. Consequently, TBs on Alpha systems are used
more efficiently than if the loadable executive images or a userâ s main image or
shareable images were loaded in the traditional manner.

In other words, it reserves memory for installed images. As far as tuning, you're not talking about large amounts of memory, autogen should be expected to do the right thing. You should keep collecting feedback and run autogen after the next "peak period" to see if any more changes are recommended.

Andy

[Hoff]

GH_EXEC_CODE isn't likely to produce big CPU performance win. It'll help speed up virtual address translation -- it likely won't hurt, and can help. But I'd not tend to expect a big CPU win. (I'm guessing someone here might have been installing images resident?)

Load up MONITOR and set a process loose to record every, say, five or fifteen minutes, or (better) load the T4 probes.

Start collecting run-time data on the system and the environment.

I've seen cases with some simple tweaks that improve performance, and I've seen cases where the server is quite simply at its maximum limit. (My rule of thumb has been that manual tuning -- barring some significant tuning issues -- is good for about ten percent improvement. I'd not tend to spend more than a couple of days on this task in aggregate; the payback for long-term and careful tweaks just isn't a good payback. Not when compared with the price of (faster) hardware.)

Quick wins -- barring "simple" cases of overt performance limits -- tend to involve tossing more, better and/or faster hardware at the problem. Or having somebody in to look at the box, and you may well get a recommendation back to upgrade the hardware. (I know I've recommended that approach on various occasions. And an AlphaServer ES40 isn't the fastest box in the ES4x series, even assuming you're maxed out on the ES40 CPU configuration.)

Finding the performance bottleneck(s) -- which is where the performance data comes in -- is an iterative process, and involves finding and removing each bottleneck as encountered. This can be memory, I/O, or adding or removing processors, or upgrading processors, or offloading activity at peak times, etc.

The process recommended by HP for tuning OpenVMS is set forth in the Performance Management manual. And avail yourself of the T4 tools, if you're off tuning this box yourself.

Stephen Hoffman
HoffmanLabs.com

[Robert Gezelter]

Douglas,

I generally agree with what was already said by both Andy and Hoff, however, I will, with all due respect disagree on the potential gains from tuning.

There is a wide range of performance improvements possible from tuning. In some cases, as Hoff mentioned, ten percent is a reasonable gain, I have also had many occasions where there was a far more substantial gain. Mileage will vary.

I wholeheartedly agree with gathering the details of the performance using the T4 tool kit. This data can be analyzed yourself, or someone with experience in performance tuning can be retained to review the overall performance issues (disclosure: we do provide this service; as does Hoff and several other contributors to this forum).

It is important to remember that the devil is, indeed, in the details. If your system has an egregious mis-configuration, substantial performance improvements are quite possible. I generally recommend that a performance review be done before major hardware reconfigurations and procurements, it reduces the potential for surprises and puts the budgetary request on a far more solid foundation.

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

[Jan van den Ende]

Douglas,

I _DO_ have to back Bob in this.

_IF_ a system (or applicatio!!) is seriously mis-tuned, any amount of extra hardware will be more than a minor relieve, where a simple repair of the misconfig gives much more.
I HAVE seen a case where the RMS files had been reasonably active (in terms of growth, and in records being removed after some time. One cleanup of the RMS structures resulted in a total removal of the experienced bad performance, and a measured speedup of some critical bulk process by a FACTOR of 30.
But if such issues are not (no longer) present, then, Hoff's is indeed a good suggestion, specifically budgetairely. Spending long time for minor gains IS costly!

hth

Proost.

Have one on me.

jpe

[Douglas Fisher]

Thanks to everyone.