|
Thank you. That made sense. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com "Don Tully" <dtully@xxxxxxxxxx> Sent by: midrange-l-bounces+rob=dekko.com@xxxxxxxxxxxx 11/23/2004 12:32 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? Picture this scenario. 1 Some interative users pressing enter once per minute. 2 Some long running job running in a jobq. Interactive user presses enter and pages are brought into memory. Job goes into long wait (1 minute) Batch job is running and it systematically eats up the memory pool. Kicking out old pages based on last used time. The interative jobs pages will always get displaced to disk before the 1 minute is up. When the interactive job is again activated, it must retrieve it's pages from disk and thus the system has more work to do and response time suffers. Now the same scenario with two separate pools. The batch job competes with only it's own pages and does not touch interactive pages. Interactive user has much better response. System actually can do more work. That is how it should work with like jobs competing against themselves. Don Tully Tully Consulting LLC -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of rob@xxxxxxxxx Sent: Tuesday, November 23, 2004 11:05 AM To: Midrange Systems Technical Discussion Subject: Re: Why separate pools? Now it's getting to the point where I really need to digest this information My interpretation of what you said is that when one pool pages, it only pages pages out of it's memory pool. For example, if interactive pages out a few pages, it won't affect the pages of memory that a set of jobs in batch might be using and successfully sharing a file. Right? Do people like SSA or Software Plus actually write applications to take advantage of this? Wouldn't the separate memory pools inhibit applications in batch from sharing memory pages containing data that interactive jobs might be able to use? Doesn't QPFRADJ, and it's genre, alter activity levels also? Could that mean that I am tying up CPU for one pool that might be better used in another? If I am dynamically changing the activity levels, why not lump them all together and get a faster leveling out? Time slices could still be controlled by subsystem, thus giving different time slices to batch vs. interactive. Having them in a separate pool is not required to have different time slices. 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@xxxxxxxxxxxx 11/23/2004 11:44 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? 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. -- 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
