RE: Performance Question -- MIDRANGE-L

The reason to use a separate memory pool for the SETOBJACC objects is to
make sure it is big enough to hold the files and to prevent parts of these
files from being purged from that memory by job activity.  In other words,
if the subsystem is managing active jobs in the same pool of memory that the
SETOBJACC files have been loaded, you have no easy way of preventing the
system from purging pages of memory that the files may be loaded in if those
pages of memory have not been referenced.  This is exactly what you were
trying to prevent.  

If you want to have a private memory pool in the same subsystem as the users
jobs, then just make sure there are no routing entries that would place jobs
in that pool.  For example, a subsystem could have memory pool 1 out of
*BASE for the subsystem monitor, memory pool 2 which is referenced in the
routing entries to run jobs (could be a shared pool), and memory pool 3
which should have a specific amount of memory allocated that matches the
files sizes and is not referenced by any routing entry in the subsystem.
The SETOBJACC command would then reference memory pool 3 of this subsystem.
This is one subsystem, but the configuration still ensures that the files
are in one memory pool and the programs/jobs executing in another. 

As others have said, this technique sometimes sounds like it would improve
performance, but in practice many times has little effect.  If the files
were really heavily used and only 20mb in size, it's likely OS400 would have
already cache'd those objects.  Since you only need 20mb of memory, it
should be easy to try it out and get some comparsions.......

Good Luck,
Glenn

-----Original Message-----
From: Balaji.Rao@smed.com [mailto:Balaji.Rao@smed.com]
Sent: Wednesday, April 18, 2001 3:18 PM
To: MIDRANGE-L@midrange.com
Subject: Performance Question


As Eric suggested here is some more info about the programs and sizes.
The programs I'm planning to load are RPGLE pgms compiled to run in named
activation group.
The total size of programs and files that'd be loaded using SETOBJACC would
be 16 - 20 MB.

Glenn, Is there a specific reason to load these objects into a substems
private memory pool where no jobs run? why not load em into a memory pool
attached to the users SBS?

Thank you for your help.


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>Prakash,

What we do when we use the SETOBJACC command is create a new subsystem with
enough memory in a private pool to fit the file(s) and access path(s) you
want pinned in memory.  No JOBQs or workstations are defined, so no work
executes within this subsystem that you intend to load the files.  When you
start the subsystem, hopefully enough memory is available to allocate to
the
subsystem without impacting the other processes running on the system (as
Eric points out below, if you steal too much memory to load the files, you
may actually hurt the performance).

As you execute the SETOBJACC commands, you'll receive status messages
informing you of how much memory is required and available.  If the file
placed in memory is primarily read accesses in a random mode, you quite
possibly will see performance improvement.  Updates still need to be
written
to disk, so heavy write and update file activity is less likely to benefit
from this technique.  I wouldn't worry about doing a SETOBJACC on the
program(s).  OS/400 already does a very good job of cache'ing heavily used
programs.  So, I would continue to run the jobs for the group of users in
the subsystem you already have defined.  For overall system performance,
consider using shared pools (but not for the subsystem that will hold the
SETOBJACC files), expert cache, and automatic performance adjustment (i.e.
the normal tuning controls).

I would suggest benchmarking the process with and without the use of
SETOBJACC (and perhaps if memory is constrained, different mixes of
files/access paths used on the SETOBJACC).  I'm sure the list would be
interested in the results.

HTH,
Glenn
----------------------------------------------------------------------------

--------------
>Prakash,

>Be careful with SETOBJACC as you might create more bottlenecks than you
>solve. Unless the files are very small, you might end up using all your
>storage for the files and not have any left over for your user jobs.

>What OS version are you running? Early in V4, IBM introduced the 1TB
access
>path that can improve DB IO for very heavily updated files. Are your
>applications OPM or ILE? Optimized? What is DASD utilization (WRKDSKSTS)?
Do
>you have enough disk arms? Are you using database triggers?

>There are some real performance experts here on the list (not me <g>), but
I
>suspect you will need to give some additional information about these
>programs before anyone can help.

>hth,
>Eric DeLong

>-----Original Message-----
>From: Balaji.Rao@smed.com [mailto:Balaji.Rao@smed.com]
>Sent: Tuesday, April 17, 2001 12:55 PM
>To: MIDRANGE-L@midrange.com
>Subject: Performance Question.


>Hi there,
>We have a group of users who use a particular program repeatedly during
the
>day. This program does a lot of I/O on certain files. Since our users
>started using this program the performance of the entire system has gone
>down. Using DSPSYSSTS we noticed lot of DB and NON DB pages being loaded
>when this program is running. We have a separate subsystem for these group
>of users.
>To tackle this problem we are planning to load this program and some of
the
>most frequently used files into memory pool attached to the subsystem
using
>SETOBJACC hoping to reduce the number of pages getting loaded dynamically.
>Will all the jobs running in this subsystem using this program use the
copy
>of program and files that we loaded??? Will this work at all?????

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---