Re: Why separate pools?

[Alexei Pytel <pytel@xxxxxxxxxx>]

Page frame is a page-size chunk of main storage.
Work in different pools compete for different sets of page frames. This 
allows granular control over different types of work.
Another benefit of the separate pool is when many jobs are likely to 
reference same objects (e.g. files) - this may increase the probability 
that these objects will stay in main storage and may actually reduce 
overall paging.

Also, storage pool is not only memory management. It has activity level, 
which allows to manage CPU contention as well.


    Alexei Pytel
always speaking for myself only




rob@xxxxxxxxx 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
11/23/2004 10:07 AM
Please respond to
Midrange Systems Technical Discussion


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Why separate pools?






Ok, now we are getting somewhere.  Competing for page frames.  What does 
this mean?

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





Alexei Pytel <pytel@xxxxxxxxxx> 
Sent by: midrange-l-bounces+rob=dekko.com@xxxxxxxxxxxx
11/23/2004 10:33 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Why separate pools?






Separate pools are recommended when different work has different 
performance requirements.
This prevents them from competing for the same page frames.
If there is no difference in how different work should be treated, I see 
no complelling reason to have separate pools.
I still think that keeping non-system work away from *BASE pool is a good 
idea.


    Alexei Pytel
always speaking for myself




rob@xxxxxxxxx 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
11/23/2004 07:04 AM
Please respond to
Midrange Systems Technical Discussion


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Why separate pools?






What benefit is there to separating resources into distinct pools?

The problem with doing the CHGSHRPOOL to increase one pool is I have to 
figure out which other pools I need to do it on to reduce it's size.  For 
example, as a default Domino runs it's stuff out of base.  Now is the 
memory I need in *INTERACT, *SHRPOOL, etc?  Which one(s) do I reduce to 
put memory into base?
By the way that was 500mb per each Domino server.  11 * 500 = 5.5GB.  One 
alternative is to not fire them up at once, but to put a 5 minute delay in 



between each.

Maybe there is some benefit to an alternative product, but I am still 
struggling with the first question at top.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





Vernon Hamberg <vhamberg@xxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
11/22/2004 08:41 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Why separate pools?






Rob, a couple ideas, as QPFRADJ is relatively slow to respond. There is 
benefit, usually, to separating resources into distinct pools. And it is 
usually, IMO, a good idea to get non-system activity out of *BASE, which 
has a lot of stuff in it.

1. Do a CHGSHRPOOL before each startup. Set the size to the 500 meg. Then 
let QPFRADJ go from there.

2. Get AutoTune from help Systems. It has much more control for you. You 
can have it be more aggressive for some pools, and you have some control 
over time-of-day configuration. Of course, it isn't free. QPFRADJ does a 
pretty good job much of the time, but sometimes you need more. They also 
have LPAR balancing stuff, IIRC.

Vern

At 03:19 PM 11/22/2004, you wrote:
>Since many people are setting QPFRADJ at 2 or 3 I think this begs the
>question:  "Why use separate memory pools?"  QPFRADJ is supposed to
>balance memory between pools.  However IBM puts some limits on it to make
>sure that not everything swings one way or the other too radically.  This
>causes a problem when you do have a major job shift and you do want a 
more
>radical shift.  If I am using QPFRADJ in this manner that why not just 
put
>everything into one or two pools?  I could still have numerous 
subsystems,
>(if that buys me anything), but why not run them all through the same
>pool(s)?
>
>For example, if I start up my eleven Domino partitions on the machine,
>each with a recommendation of 500mb, you know how long it takes for
>QPFRADJ to finally balance out???  But if I were running them in the same
>pool as QBATCH, QINTER, etc the memory would be available instantly.
>Processor doesn't seem to be a constraint on our machines.
>% CPU used . . . . . . . :       15.4
>Sys      Pool   Reserved    Max  ----DB-----  --Non-DB---  Act-
>Pool    Size M   Size M     Act  Fault Pages  Fault Pages  Wait
>   1    1541.48    476.43  +++++     .0    .0    3.1   3.1   75.5
>   2    4654.24     44.66   1156     .6    .6   19.2  60.7   6859
>   3    6019.41       .19    458     .0    .0   13.8  25.8  170.0
>   4    5903.89       .02     80     .0    .0     .0    .0     .0
>   5     183.01       .03     46     .0    .0     .0    .0   75.5
>Memory does.
>Seems a shame to have a big chunk tied up somewhere when other processes
>could be using it.
>
>
>Rob Berendt
>--
>Group Dekko Services, LLC
>Dept 01.073
>PO Box 2000
>Dock 108
>6928N 400E
>Kendallville, IN 46755
>http://www.dekko.com
>
>--
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
>To post a message email: MIDRANGE-L@xxxxxxxxxxxx
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/mailman/listinfo/midrange-l
>or email: MIDRANGE-L-request@xxxxxxxxxxxx
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.

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


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


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


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