× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Performance Question.
  • From: Glenn Birnbaum <gbirnba@xxxxxxx>
  • Date: Tue, 17 Apr 2001 17:05:56 -0700

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.