On 6/14/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:

I opened an incident with Velocity this morning and still haven't heard back 
from them.

Please look for those critters eating out of your inbasket... ;-)
I know we responded to this a few hours after you opened the issue,
asking you to upload the reports of a day (instead of asking you
numbers one at a time). If it's high over shorter periods you might
want to upload an hour of history data for us to look at.

Are there any ESAMON users out there who know which screen I can use?

This is probably less entertaining for those who don't have our
products. My apologies.

It is uncommon for CP to have a lot of overhead that is not charged to
users, so there isn't an obvious place where we show that. But you
could start at ESACPUA for example to verify that it is indeed CP
doing things for users (user overhead) or doing things for itself
(system overhead).
Things "for itself" is for example scheduler, accounting, monitoring,
etc. Some of that involves taking samples of all users and devices,
and is sort of independent of the total usage (so it stands out on an
idle system). I would not be alarmed if I saw 1-2% of a CPU used by
system overhead. And because there is some "master only" work you
might see the master CPU use a bit more. At some z/VM level I believe
VSWITCH was also in this, but I am told it currently should be charged
to the VSWITCH controller userid. There's lots of system metrics we
would look at to understand what's making this higher than normal.
Things "for users" is instruction simulation (diagnose, IUCV) and I/O
for example. If that's high you normally spot one or two users with
high numbers, and there's lot of per-user metrics that help understand
why the user is causing that. It's not always enough to just look at
T/V ratio, but you also want to relate that to total usage (for a user
at 0.1% of a CPU, I am less upset about T/V ratio of 2 than when he
runs at 100% of a CPU).

Please send in some data so we can assist you in looking for the cause.

Rob
--
Rob van der Heij
Velocity Software, Inc
http://velocitysoftware.com/

Reply via email to