[Info-vax] What choices are available to the OpenVMS Process Scheduler once all the CPUs are in use?

[sean at obanion.us]

Thank you all for you insight and expertise: it's why I posted this here.

While I work through the other issues brought up, some quick responses:

We are running BL870 I2. Management was willing to be on I4 by now, but the whole I4-HP-VSI-Intersystems support delay has our application vendor behind with no ETA for I4 support (the vendor added AIX support).

We might upgrade to BL890 I2 (so 16 to 32 cores), but it's not budgeted. 

100 to 120 COM Queue (via PAWZ) is typical across the day for about two years, including the day in question. That the CUR Queue hit the maximum of 32 is new.

Cache database tuning is something the application vendor is supposed to do,
and part of our planned efforts to mimic the problem on a test system will support their investigation.

Process priority is not something we have changed for some time, and we are a little reluctant to make radical changes now.
However, there were some batch jobs running reports more business critical than others,
so we may be dropping the priority on the less important jobs or run them the next day.


There was an application code change in the middle of Dec., and we included the OpenSSL patch, and have found the CUR Queue change from that date.

Regarding OpenSSL, we believe that Cache is using the OpenSSL libraries for encryption. 
There are several hundred processes communicating to a number of internal servers that are using AES encryption that we may take to no encryption and move to an isolated, non-routing subnet on our testing system. The other application code changes are being evaluated.


Thanks again,

Sean