Scott,
I'm no expert at CUoD, nor do I play one on TV, but given the following statement:
"It appear to be able to go to 280% but I've
never seen it go much above 200%. Our nightly cycle is mostly a single
threaded program stream."
I'd say the answer is no. Since it appears that basically, your nightly cycle is constrained to a
single CPU. Thus you need either a faster CPU, or you need to re-work the nightly job to take
advantage of the multiple CPUs you do have.
Some thoughts:
1) Instead of Updates, report, updates, report...do all the updates and submit reports at the end as
unique jobs.
2) Any massive forest killing reports that could be converted to use SQL I/O instead of native I/O.
Thus taking advantage of SMP? (You do have the SMP licpgm loaded right?)
3) If your files are journaled, make sure you are using commitment control.
Lastly some info from the "Striving for Optimal Journal Performance on DB2 Universal Database for
iSeries"
"5.3.1 Batch job parallelism
We can often increase the throughput and reduce elapsed time by increasing the CPU usage. CPU usage
can generally be increased by making use of batch job parallelism. This means running multiple
concurrent jobs in order to maximize CPU utilization. You can achieve this by restructuring your
runtime environment in order to have multiple copies of your job running at the same time. For
example, if your single job utilizes 25% of available CPU, four jobs should theoretically drive your
CPU utilization to 100% utilization.
Note: You can collect your job's performance data using OS/400 Collection Services (previously called
the Performance Collector). The following are some performance collection types of information that
you can use to analyze the performance of your job:
Job name
User ID
Job number
Job elapsed time
CPU time
Number of physical IO operations
Number of logical IO operations
Total CPU time for all active jobs during your job's runtime
The number of collection intervals
The time length of each collection interval
The items listed above are collected by the OS/400 Collection Services Tool and stored in the file
QAPMJOBL. You can then distribute the input workload (for example, input data) evenly amongst the four
instances of your four jobs. In our banking environment this could be as simple as splitting the
end-of-day program into four copies and asking each copy to process 1/4th of the accounts. For
example, if your input file contains 10000 rows and you have decided to run 4 concurrent jobs, then
the first job could process rows 1 through 2500, the second job could process rows 2501 through 5000
at the same time, and so on."
You might want to check out the whole of section 5.3 Increasing performance.
HTH,
Charles Wilt
--
Software Engineer
CINTAS Corporation - IT 92B
513.701.1307
wiltc@xxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Ingvaldson, Scott
Sent: Thursday, June 19, 2008 5:26 PM
To: Midrange Systems Technical Discussion
Subject: CUoD Expertise needed
We have a 3800 CPW 550-7154 Standard edition. It has three active
LPARs, all uncapped and our production LPAR averages around 60% cpu with
peaks up to about 150%. It appear to be able to go to 280% but I've
never seen it go much above 200%. Our nightly cycle is mostly a single
threaded program stream.
We have received a code for temporary activation of the CUoD and would
like to try it out, the question is, will this help us at all? The
system does not appear to be constrained by CPU, memory(24 GB main
storage) or I/O (avg arm utilization about 4% on 48 mirrored drives.)
Our databases keep growing and we need to shorten the nightly cycle
time, especially at month end.
TIA
Regards,
Scott Ingvaldson
Senior IBM Support Specialist
Fiserv Midwest
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.
midrange.com
