Re: Performance Question

>>>>>>>>>>>>>>>>>>>>>>
Hello everybody,

Here are some interesting facts about the performance issue I've asked you
guys for help. Thanks to all you guys who have put forth your ideas.

I mentioned that I noticed lot of Non DB Page faults in the memory pools
running the jobs that execute the program in Question. Since this program
gets called frequently by many jobs, my guess was that pages of this
program are being swapped in and out of memory causing the high Non DB page
faults(that expalins why I turned to SETOBJACC).
It turned out that the main culprit was the static storage that this
program used, which was close to 68Mb. Which means every time a job
executes this program it has to allocate 68Mb and clean up once it ends.
And the Non DB page faults probably were the swapping of this static
storage pages. This program is DSM program and the Data Structures(Multiple
occurence), Arrays and Program Vars required to implement everything from
Simple screen to multiple subfiles in one screen were defined statically.
Which answers the 68Mb static storage.
We modified the program to allocate storage for most of the big Data
structures dynamically and not to mention only the required amount(instead
of the maximums) and cut down the static storage to 22Mb. This made a
significant impact on the response time of the program. The amount of
impact varied from one machine to another depending on the size of the
processor, memory and # of jobs.

68Mb of static storage per program does not seem a lot considering 1-2Gb of
main memory on an AS400 but that made a lot of difference. Along with
cutting down the static storage, we also implemented SETOBJACC and loaded
all the frequently used programs and files into a private pool. But the
main performance booster was the static storage.

In case you guys are interested, static storage used by a program appears
on the second screen in DSPPGM command.

Thought you guys would be interested to know.



----- Forwarded by Prakash Reddy/SMS on 04/18/01 04:18 PM -----
                                                                                
                                   
                    Prakash Reddy                                               
                                   
                                         To:     MIDRANGE-L@midrange.com        
                                   
                    04/18/01             cc:                                    
                                   
                    01:09 PM             Subject:     Re: 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 message and any included attachments are from Siemens Medical Solutions 
Health Services Corporation and are intended only for the addressee(s).  
The information contained herein may include trade secrets or privileged or 
otherwise confidential information.  Unauthorized review, forwarding, printing, 
copying, distributing, or using such information is strictly prohibited and may 
be unlawful.  If you received this message in error, or have reason to believe 
you are not authorized to receive it, please promptly delete this message and 
notify the sender by e-mail with a copy to CSOffice@smed.com.  Thank you
+---
| 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
+---