RE: Why separate pools?

[rob@xxxxxxxxx]

Starting to sink in.

And since we loaded WAS last week - this could really come into play.

Thanks everyone for bearing through with me.  I just like to question the 
status quo sometimes.  It's starting to click.

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





"Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
11/23/2004 01:58 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?






As you've been hearing, Rob, separate pools make sense primarily in the
case of separate work loads.  Typically, a given machine might have two
or three "user" pools (plus there's always the system pool, where the OS
keeps its most important bits): one for interactive, one for batch, and
maybe a tiny one for spooling.

The interesting thing about the iSeries (and it's been this way since
the CPF days) is that if you have 50 users signed on to order entry in
the same pool, only ONE copy of the OE program is loaded.  Each user
gets their own space for data (which these days is the F specs and D
specs plus miscellaneous bits), but the program itself is only loaded
once.

This does NOT work across memory pools.  If you have two users in two
different pools running order entry, you have two copies of the program
AND the data.  So running like jobs together in the same pool is really
good advice.

A last bit on this: Java does NOT work and play well with typical OS/400
work.  For whatever reason, if the JVM is subject to paging, performance
suffers horribly.  Thus, if your JVM and your interactive users share
the same pool, nobody wins.  It is always best to hack off a chunk of
memory into a pool and give it directly to any Java jobs (especially
WebSphere).

Joe


> From: rob@xxxxxxxxx
> 
> Thank you.  That made sense.

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