Re: Why not *SHRPOOL1?

>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.

= Vern, now that's the biggest concern yet as to why not *shrpool1.
Any comment from others on that?

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 




Vern Hamberg <vhamberg@centerfieldtechnology.com>
Sent by: midrange-l-bounces@midrange.com
01/27/2003 03:02 PM
Please respond to Midrange Systems Technical Discussion
 
        To:     Midrange Systems Technical Discussion 
<midrange-l@midrange.com>
        cc: 
        Fax to: 
        Subject:        Re: Why not *SHRPOOL1?


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


_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo.cgi/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.