Re: Job not not getting its fair share of CPU??

Chuck,

I have concentrated on the SQL and I think the immediate issue has bee
corrected...

Basically, besides my own curiosity the only reason I was asking about
the WM weirdness was to see if there was some documented reason I
could use to push for a better WM setup... ie. splitting up our 700+
users into multiple subsystems.

Charles



On Mon, Jul 26, 2010 at 6:00 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

  I would suggest pretending never having heard about any weirdness
with the work management, and to instead concentrate on the SQL,
since the former WM issue seems more likely to have been a myth than
reality.  While I recall an issue with jobs being /winners/ in
obtaining locks despite having a priority which would normally have
precluded the access by the job more often than not, I do not recall
any failures to properly /slice/ across all jobs of the same
priority.  The latter effect would almost surely have been exposed
by performance testing.  The former [the contention issue] was
noticed in actual customer use [ugh] versus performance testing, as
a side effect of a mid-release change which did not see a full suite
of performance testing.

  Are the queries embedded or dynamic?  For the last SQL in a job,
explain the "same" query for some of the jobs; for at least one job
with "decent performance" and at least one job without.  Possibly as
the available memory decreases, the optimizer might change the
access plan with a less aggressive memory strategy, effecting worse
performance.  Depending on how\where the plan is [or is able to be]
stored, then I suppose some jobs might utilize one plan and other
jobs utilize another version.... perhaps for the poor performing
jobs, that is a plan being rebuilt each time, e.g. because the
updated plan can not be saved into the object which had the plan
created earlier in the day with the more aggressive memory
utilization.  That supposes whatever triggers a decision to rebuild
the access plan rebuild in a slower performing jobX, may not be
getting triggered similarly in the jobs seeing the better
performance.  I am not sure what about plan validation might cause
that, except possibly any job for which the plan was located via a
pseudo-closed cursor may tend to use the same plan [i.e. by
overlooking some attributes in plan validation] whereas a job which
does a full-open may be more thorough in its review of the run-time
environment while validating against the stored plan.

Regards, Chuck

On 26-Jul-2010 12:44, Charles Wilt wrote:

I've got about 5 users, each running the same screens over the
same data.  One set of users is getting decent performance, while
the other set of users is not.

Job run priority, time slice, class, etc are the same.

Some days a particular user was one of the ones getting good
performance, other days not.

Talking to the user's manager, one comment stood out...the users
getting good performance (that day) had gotten an early start.

I seem to vaguely recall reading/hearing something about work
management issues that could be caused by  large number of
"identical" jobs running in the same subsystem and that the lower
numbered (named?) jobs would tend to get the resources.  The
users getting good performance where getting twice (10-20%) of
the CPU vs. the users getting bad performance (5-10%)

The issue started after our full backup and IPL on the weekend of
the 19th.  Since the screens having the issue made use of SQL
for searching my guess was that a very useful system maintained
temporary index was deleted at IPL.  Actually, I think I've
figured out the missing index and have since created it.  So CPU
usage is down and I'm waiting to hear from the users.  But I'm
curious as to why some users saw good performance and others
didn't.

If my memory is correct regarding the problem of "identical"
jobs, that could explain the difference in the users job
performance for the users running this one particular set of
screens given that all 700+ of our interactive users run in one
subsystem using the same priority, time slice, ect.

Can anybody confirm my recollection or otherwise shed some light
on this?

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.