Re: Where is all that CPU going?

This may be a 'nothing' but is there any blocking in the CL? (i.e. NBRRCDS parm) A couple years ago I got a question from a customer who had this very same problem with a job. They had a 16 way 570, disk in the many TB range, and buckets of memory. Job 'ran a reallly long time'. Paging numbers like those here were very very large. Turns out they had blocked the I/O on a file that they were reading by key. Originally this was OK because they were reorganizing the file by that key each weekend. However they stopped doing the reorg 'some time ago' and performance of the job just got worse and worse ever since. Simply removing the blocking cut run times by 80%.

- Larry

On 10/28/2010 9:03 AM, Charles Wilt wrote:

James,

Is the is the nightly refresh that takes all night _AND__ all day?

I'd agree that seems to long. 19 million records isn't all that many.
Especially for a box the size you're dealing with. (though 16GB
seems awfully low when you've got 4TB on 53 disks)

Honestly, I'd expect to to run in less than 1hr....but that assumes
the job has the box to itself; plus I always under estimate :)

Assuming the CPU isn't going to 100%, I'd bet you're doing more I/O
than you expect.

Performance tools could tell you exactly where the time is being spent.

If you rather waste time looking at the code, look to see if a READ
and manual check of the keys is being done somewhere instead of a
READE. READ with a manual check could allow the program to work
properly, but end up reading the entire file every time instead of
just a block of records you intended. I've seen that happen
before....

You might try looking at the file I/O details shown by 14-Display Open
files of WRKJOB.

HTH,
Charles