Disks statistics for one day

[Andy Bustamante]

>>> need the disk statistics in terms of disk performance like detect IO bottleneck and other parameters(if available).

You can pull the disk metrics but if you're torubleshooting a performance issue then Hein is spot on:

>>>.. start by droppping all assumptions (such as a disk being the bottleneck at all)
Then you observe the system and 'see' where it hurts

T4 is the utlity right now. http://h71000.www7.hp.com/openvms/products/t4/index.html One of the major data collectors is monitor. You can use monitor interactively as well. In addition the examples above you can record a session, since T4 is available, this falls into the category of silly monitor tricks, but can still be useful.

$ monitor
MONITOR> monitor all_class, disk/item=all /inter=xxx/nodisplay/record=monitor.dat
The default interval is 3 seconds, select something between 3 and 60 for your system:

$ pm == "monitor /input=monitor.dat/view=1"
View controls how long a screen shot is displayed. You can record 2 hours at 1 minute intervals and play back the display in 2 minutes for example.

$ pm disk /item=que
$ pm system

T4 uses the same method to collect monitor data, you can play back the the T4 monitor files as well for an interactive session.

You can also attend a performance class or schedule time with VMS consultant. There's more than one available here.

Andy

[Steve Reece_3]

As others have commented, the use of T4 to collect data is very successful in my experience and getting someone with lots of VMS and hardware experience to look at the results with you could probably pay dividends.

The important thing that you need to consider is what bottleneck are you really looking for? What's the underlying SYMPTOM that you're looking for the CAUSE of.
The symptom could be that the users are complaining of poor performance or that the overnight batch jobs that you're running are not completing in time for users to start work.
The cause of this could be as varied as:
- volume of data has increased so that the overnight job is running perfrectly well but just doesn't have enough time;
- the disk have become fragmented so that the system is spending more time spreading data over disks and reading data from disks so that disk performance appears poor;
- the system could be short of memory so is spending time paging and swapping instead of doing real work for users.

Near 100% CPU can be a good thing or a bad thing - it's good if it means that there's no other bottlenecks and you're getting through the work that you need to do. It's bad if the CPU is spending time managing stuff that shouldn't need managing (like paging, swapping, doing I/Os that don't really need to be done if you had effective caching.
Similarly, disk I/O can mean that it's a badly behaved application that's expecting too much from the disks or it could be that there's too little memory on the box to cache data effectively.
Invariably, when I've been asked to look at client systems that are running like a dog and the client reports that disk performance is poor, there's more than one aspect to it. Look at the thing in isolation and you'll miss other causes. Look at the overall situation and you can get back to a balanced system.

In short, T4 is going to be your friend. Look at all of the data that it can collect and get a helping hand too.

Steve