Re: Putting a Cap on QZDASOINIT CPU % ?
- From: "Stefano P." <procstef@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 29 Nov 2007 07:28:57 +0100
Hi All,
Hi :-)
We run JDEdwards OneWorld on our iSeries servers, but also have
various data mining and query users hitting the JDE databases with
SQL. We find that these SQL's can really hog the system and degrade
performance for the JDE users - particularly when the query is not
well designed or has nested subqueries etc. It's not uncommon for a
couple of QZDASOINIT jobs to grab 25% CPU each.
In my experience (systems from V4R3 to V5R4), it's quite usual to have such a cpu consumption per job for an sql query;
the problem arise when you have many of these jobs running together :-|
And, that's more, those query consume more cpu and disk resources when there is lack of appropriate indexing...
Is there any way to cap CPU consumption for a class of jobs?
You may change the job description for those jobs, giving them a different class (with different time slice and run priority);
as those are "sql" jobs, you could benefit from moving them in a separate memory pool too.
This is a work management issue...
I don't remember exactly but, as far as I remember, job description and class for QZDASOINIT jobs is quite aggressive...
Is there
any other way to tame these rogue queries?
I would (and am about to - on the systems that I control) work on "work management" (class, jobd and memory pool) on one side and on query attribute on the other.
Even turning the run
priority down seems to have little effect.
I suppose it has no effect because you change priority after having seen that job running (too much):
at this time the access plan it's already started.
From an "sql point of view", you could decide to "change the query attribute" of those jobs using CHGQRYA:
you may both use a "less aggressive" qaqqini and limit resources use.
Imho, the simpler way to change query attribute for every QZDASOINIT job would be by mean of the routing step in the subsystem definition, something like
CHGQRYA bla bla bla
TRFCMD (I suppose to QCMD)
(sorry, I cannot check for exact values on the systems in this moment).
As those jobs are sql queries, check for the existence of the appropriate indexes ;-)
Thanks for any tips,
JohnO
HTH
Stefano P.
--
"Niuna impresa, per minima che sia,
può avere cominciamento e fine senza queste tre cose:
e cioè senza sapere, senza potere, senza con amor volere"
[Anonimo fiorentino, XIV sec.]
(togliere le "pinzillacchere" dall'indirizzo email ;-)
.
- Follow-Ups:
- Re: Putting a Cap on QZDASOINIT CPU % ?
- From: JohnO
- Re: Putting a Cap on QZDASOINIT CPU % ?
- References:
- Putting a Cap on QZDASOINIT CPU % ?
- From: JohnO
- Putting a Cap on QZDASOINIT CPU % ?
- Prev by Date: Re: iSeries HMC
- Next by Date: Determine caller in SQL Trigger V5R4
- Previous by thread: Putting a Cap on QZDASOINIT CPU % ?
- Next by thread: Re: Putting a Cap on QZDASOINIT CPU % ?
- Index(es):
Relevant Pages
|
