Help on interpreting a graph from CA adviseIT (dcps)

[Ken Robinson]

Please see the attached jpg showing the graph. We need help figuring out what the "OTHER" is for the gold line. It's labeled as "ISTK+MPSY+OTHER".

Thanks in advance.

Ken

[labadie_1]

Hello

It would help to know your Vms version and your hardware, and the number of Cpu on your Vms node.

Is this node a member of a Cluster ?

Is the Cpu 0 saturated ?

[labadie_1]

And of course, you are talking about Psdc, no dcps (a symbiont)

:-)

[Ken Robinson]

Sorry about the wrong abreviation... :-)

OpenVMS 7.3-2
Standalone system
Alphaserver ES40, 4 cpus
6 Gb Memory

I'll have to check of the status of CPU 0.

Ken

[Hein van den Heuvel]

Ken,

Those labels are a deliberate, private, choice. This did not come with the product, but someone set that up for you in your environment. Backtrack your scripts and you'll fine an explanation. We here can only speculate.

OTHER could be KERNEL and EXEC or SUPERVISOR mode time. The number appear low (high is 6%?) What is the problem you are trying to solve? Just an explanation for the graph data/labels, or is there a real problem which triggered you looking at the graphs.

Go into Advice and pull your own graphs?

fwiw,
Hein.

[Ken Robinson]

I've been looking through the parameters for generating the graphs, trying to find the definitions.

Yes, we're trying to solve a performance problem on an a new release of our application. The application is very sensitive to transaction throughput and the periods of slower throughput correspond to where the gold line on the graph peaks. We're also using T4 to try to pinpoint the problem.

Ken

[Hein van den Heuvel]

>> Yes, we're trying to solve a performance problem on an a new release of our application.

Ok, that helps.

>> The application is very sensitive to transaction throughput and the periods of slower throughput correspond to where the gold line on the graph peaks.

Are we really talking throughput or perhaps response time? What I mean is, we sometime see applications peaking work-to-be-done resulting in low response time.

Here, may we assume that the CFTST1_xxx curves correspond to cpu time for application code doing 'real work', so more is better? And reading further, it looks like a 3 minute pattern with 1 minute 'good' busy and 2 minutes 'bad' overhead?
Is there no good work to be done in those 2 minutes while the gold line goes up? Or are the good guys asking for bad services, slowing their work to a tricle? Are they all fighting over a lock?

>> We're also using T4 to try to pinpoint the problem.

Use the CORRELATE button.
Focus on LOCKs and IO.
Is this application using a database of sorts? (Oracle, Rdb, RMS). Network? Server tasks (looks like) ?

Good luck,
Hein van den Heuvel
HvdH Performance Consulting

[Robert Gezelter]

Ken,

With T4, you may also want to collect the data at a higher resolution of time, and then "drill down".

Correlate is an excellent tool for identifying connections. However, it is important to first limit the correlation to the time span of interest.

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

[Peter Zeiszler]

Do you also use shadow sets? That can introduce higher interrupt & delay of i/o while merges/copies are occuring.

If you have the data - check under display top - look at images and user.
Look at top CPU and see if you have mp_synch issues.