Re: Putting a Cap on QZDASOINIT CPU % ?
- From: JohnO <johno1234@xxxxxxxxx>
- Date: Thu, 29 Nov 2007 15:10:20 -0800 (PST)
On Nov 29, 7:28 pm, "Stefano P." <procs...@xxxxxxxxxxxxxxxxxxxxxxx>
wrote:
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 ;-)
Thanks Stefano!
There is a slight complication - the JDE clients also connect to
QZDASOINIT for their queries. They are 'good guys' and rarely cause a
problem. We want them to have fast response so they should get top
priority. It's just the QZDASOINIT's serving requests from particular
ip addresses or particular user profiles (the data miners) that I want
to slow down.
.
- Follow-Ups:
- Re: Putting a Cap on QZDASOINIT CPU % ?
- From: Dieter Bender
- Re: Putting a Cap on QZDASOINIT CPU % ?
- References:
- Putting a Cap on QZDASOINIT CPU % ?
- From: JohnO
- Re: Putting a Cap on QZDASOINIT CPU % ?
- From: Stefano P.
- Putting a Cap on QZDASOINIT CPU % ?
- Prev by Date: Re: Lexmark 25XX
- Next by Date: Re: Putting a Cap on QZDASOINIT CPU % ?
- Previous by thread: Re: Putting a Cap on QZDASOINIT CPU % ?
- Next by thread: Re: Putting a Cap on QZDASOINIT CPU % ?
- Index(es):
Relevant Pages
|
