Re: Job not not getting its fair share of CPU?? -- MIDRANGE-L

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?