|
Steve, I thought that time slice was a function of the class/routing entry/subsystem description and not the WRKSHRPOOL. Therefore if you had interactive, and batch, jobs running in the same shared pool they would still have different time slices based on their origination. Wouldn't they? And yes, we do encourage people to submit to batch as much as possible. One thing nice about a 12 way processor, no one job ever exceeds more than 1/12 or 8.3% of the CPU. But that's tangential to memory management. Rob Berendt -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin "Steve Landess" <steve_landess@hotmail.com> Sent by: midrange-l-bounces@midrange.com 01/27/2003 01:07 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? Rob - I am assuming that you use *SHRPOOL1 mainly for batch subsystem(s)... I have been involved in performance tuning/work management for 20 years. A good reason to _not_ use *SHRPOOL1 for the QINTER subsystem is that you shouldn't have batch and interactive jobs running in the same memory pool. Batch work (like running a query, which is generally processing blocks of data from the disk) need a longer timeslice to get any meaningful work performed before they reach end of timeslice and get kicked out of the processor. Interactive jobs generally need a much smaller timeslice to get the work done (press <Enter>, a little processing, redisplay screen). If your user(s) are running queries interactively, that is _not_ good for running in the *INTERACT memory pool - it causes the machine to thrash. Wouldn't it be better to have the user(s) submit the query to run as a batch job (in the batch subsystem that uses *SRHPOOL1)? Or possibly have another interactive subsystem for the power users who run query interactively, that has its own memory pool, (along with a class id that makes their jobs run like batch jobs (Timeslice(5000), runpty(50))? There are various ways to get their interactive sessions to run in another subsystem...use TFRJOB, named workstation sessions with workstation name entries (or generic workstation name entries), routing entries, etc. You can end this subsystem in the evening, giving the memory back to the *BASE pool... Steve Landess Austin, Texas (512) 423-0935 ----- Original Message ----- From: <rob@dekko.com> To: "Midrange Systems Technical Discussion" <midrange-l@midrange.com> Sent: Monday, January 27, 2003 8:10 AM Subject: Why not *SHRPOOL1? > On our 840 12-way we have system value QPFRADJ set to "2=Adjustment at IPL > and automatic adjustment". And we have the following pools: > System Pool Reserved Max > Pool Size (M) Size (M) Active Pool > 1 2618.98 655.60 +++++ *MACHINE > 2 6307.05 55.12 530 *BASE > 3 3935.35 <.01 80 *SHRPOOL1 > 4 303.44 .00 20 *SPOOL > 5 1835.15 .20 227 *INTERACT > > Actually, this does a pretty good job. However, if you start this big > whopping job in one subsystem, or the other, then it takes awhile until > QPFRADJ switches memory over. In the Rochester lab (just last week) we > had a Query take 3 minutes until we switched QINTER to run in *SHRPOOL1. > They were still scratching their heads to figure out how often QPFRADJ > adjusts. After the switch it took only a very few seconds. > > So now my boss asked me a good question. Why don't we just use two pools: > *MACHINE and *SHRPOOL1? And avoid that time lag of QPFRADJ. > > Questions and comments appreciated. > > Rob Berendt > -- > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > Benjamin Franklin > _______________________________________________ > 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. > _______________________________________________ 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.
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.