Re: Where is all that CPU going?

[DrFranken <midrange@xxxxxxxxxxxx>]

 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