× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.