Performance Question

[Balaji.Rao@xxxxxxxx]

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