Re: Why not *SHRPOOL1? -- MIDRANGE-L

Details inline - a couple things come to mind - when the query was first run it was using the smallest transfer block size (4k). When run in the shared pool, it could have gone as high as 128k.

Secondly, if there was not much time between the runs, much of the data could have still been in memory, so there was effectively no IO for that data. A fair test would have had to CLRPOOL and/or SETOBJACC *PURGE for relevant data files.

Vern

>Just curious, what is the paging setting for these pools?
=
System    Pool    Reserved    Max   Paging
 Pool   Size (M)  Size (M)  Active  Option
   1     2587.68    656.50   +++++  *FIXED
   2     2582.59     55.16     530  *FIXED
   3      168.98      <.01      80  *CALC
   4      117.75       .00      20  *FIXED
   5     9542.97       .23     227  *FIXED

At first blush, with the stipulation that users will be allowed to execute intense queries interactively, the *FIXED setting for paging option limits IO transfers to 4k pages.This could have a very deleterious effect on sequential access, especially. And IO is the main bottleneck, not CPU.

-snip-

>Also, you have to have at least 3 pools - including *BASE. And probably
4,
with *SPOOL.
=You're probably right, we would need 3 pools:  *MACHINE, *BASE and
*SHRPOOL1.  You could probably modify the subsystem description for QSPL
to use one of these three pools - *SHRPOOL1.  (Why preallocate memory that
might be better utilized elsewhere?)

Using Expert Cache (paging option *CALC) has great benefits. But when work in a pool is not consistent, it can't do so well. That is another point in favor of separating distinct kinds of work.

-snip-

>There's also a priority for shared pools, I assume for which gets memory
or
activity levels first.
=I see that priority in WRKSHRPOOL.  And the help for it discusses it's
relationship with QPFRADJ.  Just doesn't say if your assumption has any
bearing.  Rather vague.

Yeah, I assume it means that the lower numeric priority is assigned resources before a higher numeric, all other things being equal. AutoTune has a similar scheme.

>Also, with so many activity levels in *INTERACT, it may take longer to
get
things going.
=At what level does that come a factor?

This was a stab in the dark, to stimulate others if they have any idea here. :-)

>Now, if by experience witht the app, you have an idea how much it needs,
do
a CHGSBSD to adjust the pool size first.
=The problem is that with 517 users currently signed on, and 472 currently
running batch jobs (according to DSPSYSSTS at basic level - how it
interprets a job as batch I don't know - there are only 25 jobs in the
QBATCH subsystem), 406 WRKJOBSCDE jobs, several totally independent
divisions we gave up trying to manually figure out when to transfer memory
from one shared pool to another, hence that is why we turned on QPFRADJ.
In days of old we used to have a job called NIGHT and a job called DAY
which were scheduled to transfer memory from one pool to another.

Exactly - and I think AutoTune gives you more flexibility overall. The dynamic pool feature, which creates a new pool when needed and returns it all to main memory, very nice. Also, min/max sizes for all types of pools, not just shared pools. And YOU decide how often it monitors the system.

Rob Berendt