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: 

"Normal" usage for a DS25

Piet Timmers_1
Frequent Advisor

"Normal" usage for a DS25

Somebody asked me:

What are "normal" values for I/O and Pagefaulting on a DS25 running OpenVMS.

I known this is not a "normal" question, but what is the answer I can give tis person.
The reals thing he wants to known is, whether his DS25 is used heavy/low or something between.

Greetings and thanks.

Piet Timmers
Piet Timmers_1
Frequent Advisor

Re: "Normal" usage for a DS25

And I forgot, asking HP is not the solution, our contract does not allow simple questions.
Volker Halle
Honored Contributor

Re: "Normal" usage for a DS25


you can expect thousands of different answers on a question like this.

I remember an answer from an IBM customer a couple of decades ago:

When any resource is used more than 30 percent, buy more hardware...

You can easily apply this algorithm to the CPU load (MONI SYSTEM).

Ian Miller.
Honored Contributor

Re: "Normal" usage for a DS25

the key metric is not a system performance metric like I/O or page fault rate but application response time. This is what the users notice first, followed by application throughput. Not as easy to measure as I/O rate but more meaningful.
Purely Personal Opinion
Robert Gezelter
Honored Contributor

Re: "Normal" usage for a DS25


There is no such thing as "normal" in a general context.

Can the system handle thousands of IOs and Page Faults per second? Certainly. Can the resources be used more efficiently? Almost certainly yes.

In my nearly three decades of consulting practice, often including performance matters or one sort or another, the only generally correct statement is that there is always room for improvement.

And the above does not include "silent" waste such as poor algorithms.

I know that the above is not a definitive answer, but particularly in this case, there is no IMHO good (useful) answer in a vacuum.

- Bob Gezelter, http://www.rlgsc.com
Andy Bustamante
Honored Contributor

Re: "Normal" usage for a DS25

I'll second Ian's response. Normal is what your user community does to a system and finds acceptable. Response time when a user hits the "GO" key (terminal, web form, ODBC query ?) is ultimately what matters. Studying performance metrics and trends can allow you to predict when a system will slow down, or recognize a problem.

When you remove one bottleneck, you often saturate another resource. T4 will allow you to collect and archive performance data.

Remember, "there are nine and sixty ways . . ."

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
Doug Phillips
Trusted Contributor

Re: "Normal" usage for a DS25

The reals thing he wants to known is, whether his DS25 is used heavy/low or something between.

Then that's the question you should address.

What you need to find out is: Why is he asking? User complaints? Considering server consolidation? ...?

There are many threads here and elsewhere, and many other on-line documents describing ways to determine system load and resource utilization and how to monitor and tune various parameters or when you need to add resource based upon your system's primary use; i.e. heavy interactive transaction processing will have different requirements than heavy batch processing or DB server.

It would be good if you can better define the problem.

NB: This is like going to the doctor and asking him to explain gall-bladder surgery when what you really want to know is why you're have this pain;-)
Honored Contributor

Re: "Normal" usage for a DS25

The answer you can give this person is -- as others have stated -- "It depends".

Best values approach zero and zero, but those are entirely theoretical and unachievable values in practice. This means you're using all of the processor, and making minimal use of I/O and maximal use of available memory.

Worst values are those noticed by users or by management.

If the person is even asking this question of you, then the answer is typically AUTOGEN with FEEDBACK and check the process quotas memory availability and interatively re-tune and re-AUTOGEN with FEEDBACK, and if the performance issues continue either look at offloading or at hardware or system upgrades. (This is the basic tuning sequence described in the performance manual.) If the question is on the table, you're dealing with somebody that doesn't have enough other work to do (less likely), or that already has a system with a performance problem (more likely).

In any event, suggest loading and firing up the T4 data collection tools. This data will be needed sooner or later, and it's nice to have a baseline. And suggest the person take a look at the performance manual as a start, or call in somebody to have a look at the box; to perform a quick health-check.

John Gillings
Honored Contributor

Re: "Normal" usage for a DS25


In terms of your underlying issue, it's probably useful to think in terms of "headroom". That is, how much extra headroom do you need to cover contingencies.
If your workload is stable and predictable, you probably don't need much headroom at all, so driving your system at (say) 90% continuously wouldn't be a problem. On the other hand, some workloads have sporadic large spikes. In such an environment, it might be a problem if you found the system over 5%.

The same concept covers all resources. So, a disk containing data that never changes can be full with no problems (CD-ROM?) but if you're (say) capturing data from a space probe which, if missed, is lost forever, would want to have LOTS of headroom to make sure problems downstream don't result in the disk filling up.

There is no such thing as "normal", just make sure you have sufficient headroom on all resorces to cope with your workload.
A crucible of informative mistakes