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