Rob--
How to chop up your memory resources is one of the Mysteries of the
IBM i operating system.
We chopped things up years ago, and, since users aren't complaining
about things, we think it worked out OK. And we don't do a lot of
fixing things that work OK.
How do we decide? Usually it's when performance starts to suffer--
repeatedly and predictably.
What we've done is to use shared pools for most of our subsystems.
These are controlled by Help Systems' Autotune. We set general
parameters in Autotune, and let it parcel out the memory. We started
using Autotune before IBM realized it could write its own tuner!
QPFRADJ is set t0 zero on both of our production systems.
Two main exceptions to using shared pools: *INTERACT and *SPOOL.
In addition to printers, *SPOOL is also used by Broderick. Broderick
is an application from way back that shuffles some spooled files
between our systems. Broderick is older than IBM's similar function,
and we've never found a reason to change.
Years (and several releases) ago we learned that IBM was not
recommending enough memory for printers-- and we have a lot of them!
Most of our plants have bar code label printers all over the place,
not to mention printers for packing lists & BOLs, not forgetting the
printers in most departments in the offices. Printing used to bog
down until we allocated a lot more memory to *SPOOL than IBM's
recommendation at the time. I think IBM has updated their
recommendation for *SPOOL memory! Our *SPOOL has a Gig of memory and
MAXACT = 1010.
*INTERACT is used by our 6 interactive subsystems.
One of the 6 is for the 'laser tag' scanners in our warehouses. All
scanners have the same 1st two letters. Work Station Name Entries
let the subsystem acquire those devices. The subsystem for the
scanners is started last during our IPLs. This lets this subsystem
'steal' these devices from any other QINTER subsystem that may have
acquired the devices. I know that IBM says allocating the same
devices to multiple subsystems can have 'unpredictable' results-- but
we've found that the latest subsystem to claim a device with a signon
screen gets it. If you have a signon screen during our IPL, you can
see it being re-allocated to the 'correct' subsystem as the
subsystems are started.
The remaining 5 are QINTER and several close relatives. Interactive
sessions are routed to one of the QINTERs based on their session
name. Session names beginning with letters A-H go to 1 pair of
subsystems; I-Z go to another pair. Some of the subsystems are
lightly loaded.
One reason we did this is because we had "issues" at one time, and
QINTER locked up during the middle of the day, and wouldn't listen to
shutdown commands. Quick fix was to clone the subsystem and fire it
up. This allocated the interactive sessions and users were able to
get back on while we investigated. Since then, we expanded QINTER
into the family of 5.
Another reason-- we found (years ago) that performance is better when
there are multiple subsystems running interactive jobs. Yes, they
all share the same memory, but there are multiple subsystem control
jobs to share the load.
For the other subsystems, there are several that are very hungry for
memory-- subsystems that work through web applications in particular.
We could use some more memory to keep these subsystems happier, but
things are usable as things are.
We've thought about isolating some more functions to their own
subsystems, but this is still in the thinking-about stage.
Most subsystems have *BASE as their first pool, but we've updated the
routing entries in most subsystems to use a 2nd pool. *BASE is kept
as quiet as possible! Most of the 2nd pools are one of the shared
pools. We currently run about 10 shared pools.
QUSRWRK has been isolated into its own share pool. This is most of
the QZDASOINIT jobs.
We like shared pools. This lets use use our memory and not leave
pieces of it hanging around doing nothing!
There may be some things I've overlooked, but this covers the big pieces.
--Paul E Musselman
.
At 12:12 PM +0000 2/11/20, Rob Berendt wrote:
I get that expert caching helps paging a shared pool by the job
types, etc from a high level. But how does one determine whether or
not one should bust jobs or subsystems into their own pools?
Is there then a concern that too many pools may create islands of
underutilized memory?
Select
count(*) as job_count,
SUBSYSTEM,
SUBSYSTEM_LIBRARY_NAME,
JOB_TYPE,
MEMORY_POOL,
SYSTEM_POOL_ID,
POOL_NAME
from table(qsys2.active_job_info(
RESET_STATISTICS => 'NO',
SUBSYSTEM_LIST_FILTER => '' ,
JOB_NAME_FILTER => '*ALL',
CURRENT_USER_LIST_FILTER => '',
DETAILED_INFO => 'ALL'
)) A
group by subsystem, subsystem_library_name, job_type, memory_pool,
system_pool_id, pool_name
order by subsystem, subsystem_library_name, job_type, memory_pool,
system_pool_id, pool_name
;
Creates this output:
https://imgur.com/K5HlDrO
DSPSYSSTS
System Pool Reserved Max -------DB------- -----Non-DB-----
Pool Size (M) Size (M) Active Faults Pages Faults Pages
1 7236.9 3777.7 +++++ .0 .0 .0 .0
2 31944.9 23.5 7987 1.2 319.2 16.4 39.1
3 27705.7 .6 558 22.9 4105.1 15.9 45.6
4 1331.0 1.2 87 .0 .1 .2 5.6
5 64885.3 2.7 2863 33.2 2155.7 39.5 96.4
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
midrange.com
