Pete,
Thanks you have given somewhere to start
John
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Pete
Hall
Sent: Monday, June 01, 2009 9:08 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Multiple jobs running out of single JOBQ are
very slow
John Allen wrote:
First off I am not even close to a guru on system
performance tuning.
I know just enough to be dangerous
So I am hoping someone here can at least point me in a
direction to get me started on this issue.
I have a JOBQ with Max Active set to 25
Running out of Pool Id 2 (*BASE)
I haven't done this in about 10 years, so take this with a
grain of
salt, but the first thing I used to do is get rid of *BASE.
It forces
everything on the box to run in the same subsystem and share
resources.
The controlling subsystem should be qsys/qctl (chgsysval
qctlsbsd, then
re-IPL).
After that, create additional subsystems as needed to group
similar jobs
together. Interactive jobs can use QINTER. Batch jobs use
can QBATCH.
You can use other subsystems that you create for specialized
loads. ODBC
was always one of my main culprits. The autostart value on
the subsystem
description determines which ones start automatically. You
can customize
the startup program (chgsysval qstruppgm) if needed to
control that (and
lots of other stuff.) Look at the IBM subsystem descriptions
(WRKSBSD)
for some examples. The interactive priority is generally 20.
The batch
priority is generally 50. The class of service determines
the priority
and timeslice. The routing entry determines the class of
service.
Priorities in any given storage pool should all be the same
if possible.
The maxjobs value for a subsystem should be either 1 (single
thread
dependent jobs e.g. overnight processing) or *NOMAX for
interactive, or
the reasonable maximum number the system memory can support
based on
available memory. Timeslice values for interactive jobs are
generally
about 20, for batch jobs about 50, which used to be the
default values /
10. I'm not sure what the defaults are today. Use WRKSHRPOOL
to specify
the starting memory allocations for the subsystems. Take a
WAG and use
performance data data to identify areas that need
adjustment. A separate
*shrpool for each different type of job works well. Turn on
auto tuning.
It really works great unless you have sudden severe swings
in job
loading. Even that, if predictable, is manageable. (I used
to use a day
and night configuration, which adjusted wrkshrpool memory
allocations
via a job schedule entry.) Watch performance at critical
periods
throughout the day, including start of office hours, lunch
time, end of
day, any known high utilization times, etc. The most
important number is
the non-database swapping rate. It's an indication of
program swapping
to disk. It needs to be low, but non-zero (zero just wastes
memory). It
can be influenced by adjusting memory allocations, and
should be more or
less uniform across all storage pools. Also watch the The
CRTPRFDTA and
DSPPRFDTA commands (DSPPRFGPH too) can help organize this.
I've been away from this far too long to be an expert, but I
hope that
gets you started at least.
midrange.com
