HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

General query on system performance

Go to solution
Regular Advisor

General query on system performance


We are still currently using AlphaServer ES80 (4 CPU, 8GB RAM) on OpenVMS 7.3-2 as our production server. Currently, we are on the midst of planning to upgrade to Itanium.

My question is actually a general one, but since I don't have seen much of these happening in our current environment, as well as my previous environments, maybe those who have some experience can share their thoughts:

1. How long can an OpenVMS system sustain before crashing during a prolonged 100% CPU utilization? I believe that definitely response time will be greatly affected, but will the system crash?

2. Is there any theoretical value how the system performance will degrade to if we start using pagefiles? Currently, we try to maintain our memory utilization by just using the physical RAM. We are, by the way, using EMC Symmetrix storage array for our OpenVMS disks.

Thanks in advance to those who will reply!


Steven Schweda
Honored Contributor

Re: General query on system performance

> 1. [...] but will the system crash?

I don't see why it would. As you said,
response times will probably be longer than
they would be if the CPU(s) had some idle
time, but that's normally non-fatal.

2. [...]

Knowing nothing about how much you would be
using page files if you used them, I couldn't
guess how much more slowly your applications
would run. It should be fairly easy to
remove some memory (physically or logically),
and then run the experiment.
Andy Bustamante
Honored Contributor

Re: General query on system performance

1. Indefinately

2. It depends.

Adding pagefiles should have no impact on a CPU saturated system assuming no shortage of memory. If you have a memory shortage and are paging, the real fix is to add more memory. Adding additional pagefiles on multiple disks can spread I/O, assuming there isn't an I/O bottleneck. Depending on the application this can be a very noticeable performance impact.

OpenVMS will slow if CPU resources are exceeded, but will gracefully degrade rather than crash. Graceful can range from application delays to application time outs and failure. Your end user may not be able to tell the difference between an application failure and an operating system failure.

Adding to the load at this point will begin to create delays in response time. If you have historical metrics, and knowledge of the application environment changes, it's possible to forecast the amount of time a system will stay at any given performance plateau. A good reason to use tools such as T4 before you have issues.

If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
Respected Contributor

Re: General query on system performance

Just to put things into perspective:
1) I have had machines at 100% utilization for weeks. VAX 780 up to and including Alpha DS10s.

2) The impact on the user can be minimized by changing the base priorities of the processes. If you know that a particular process will require a lot of CPU, set the base priority DOWN to force it to use the "spare" CPU time rather than the intereactive CPU. This will allow the interactive processes to continue with reasonable response while still allowing the proces to get its work done.

3) Monitor the system to check for page waits or mutex waits and adjust the system as required.

4) Adding page files will remove some of the memory load, but can add to the CPU load if not handled carefully. Watch also, working set sizes and quotas.

Hein van den Heuvel
Honored Contributor

Re: General query on system performance

1. How long can an OpenVMS system sustain before crashing during a prolonged 100% CPU utilization?

A) VMS can go forever, but human operators might not. The crashes I've seen in this space were forced, _thinking_ the system was not working anymore.
I highly recommend DECAMDS be set up to allow access at driver level versus general process level to evaluate and correct situations with excessiv,prolonged, CPU overload.

B) Enabling HYPERTHREADING while often giving little or no immediate / hard performance gains does give the systems some extra stretch for sure.

2. Is there any theoretical value how the system performance will degrade to if we start using pagefiles?

Use tools lile T$ as pointed out before.
Focus on 'inswaps', not page-outs.
Paging out is fine and does not cost much, but when you need the pages again, over and over, then you are hurting.
Note, remember that just loading images for a first time involves liegit and required page-ins.

HvdH Performance Consulting.

John Gillings
Honored Contributor

Re: General query on system performance


You paid for the CPU, so 100% utilisation will make your accountants happy. No wasted resources. OpenVMS doesn't care if the CPU(s) are 0% or 100%.

With GB sized memories, you have to try quite hard to get systems to do any paging. Stuff like absurdly limited working sets and/or extravagantly wasteful use of memory. Upgrading from where you are will almost certainly mean an increase in memory size, so if you aren't paging on your ES80, you won't on the new system.

The time paging really starts to hurt is when the page files start to get full. With the cost of disk space at less than 10c per GB, a trivial investement in disk space will prevent that from ever happening. Similarly, the cost of RAM is a very small part of the total cost, pay a small increment in cost up front to make sure you have way more RAM than you think you need.

Bottom line: pay a small amount now to avoid paying large amounts for slow systems and/or outages.
A crucible of informative mistakes
Regular Advisor

Re: General query on system performance


As always, thank you for your insights! I'll definitely bear these in mind when I propose changes on our systems.