What do "CPU Time" in JOB-LOG mean ?

[8101]

Hi All,

We have observed that a JOB with same input and load module takes different CPU time, when we submitted it for testing in different instances.

The COBOL program is using DB2 and flat files as input.
The time difference is in Hours,
1st run it took 2 Hrs.
2nd run it took 13 min.
3rd run it took 3 Hrs.

We could not understand the behaviour of the CPU !

Thanks,
Vinodh.

 

[MarcLodge]

If you are processing the same data (are you absolutely sure?) with the same load module, and this gives such widely fluctuating CPU times, then it must be something external to the program.
Has anybody else got a lock on the input files?
Are there any other jobs which are running, which might influence the envirnoment you are running in? If so what are the Db2 locking parameters between the two jobs, and is there some form of contention which is causing DB2 to wait, but not abend. Try looking in the DB2 job log to see if there are any contentions.
Hope this is of some help
Marc

 

[8101]

Marc,
Thanks for your response.

The total number of records in different runs are around 6 million records. That is absolutely right. But the data are surely bit different. However we could not understand the erratic nature of the Job behaviour or CPU time.

The input files are not locked by any other person.
The tables we accessed are dedicated to us. No one else have even tried to access at that time. We have checked in our job details as well. There is NO contention with any other jobs.

The DB2 parameters are not changed in any of the test runs.
What else can be the parameters that would have affected the CPU time in different runs at different instance.
We really couldnot conclude whether the code is efficient or we need to tune.... because of the diff. in CPU times.

Thank you very much.
Vinodh

 

[MarcLodge]

Hi Vinodh,
What I'm not sure of is if you are running the same data in each run. You state that the input is the same, but say that the total number of records in each run is 6m, but I get the feeling that the data is different. Can you clarify whether you are using EXACTLY the same input in each run?
Marc

 

[8101]

Hello Marc,

You are right. The data is different. The input is NOT exactly same. However the total no. of records in each run is "almost" same. When the data is not much changed but the CPU time varying that much is what raise suprise to me.

One observation is out of 4 test runs... only once the job ended with 13 minutes CPU time, other 3 instances it took around 2 HR CPU time. (the 13 minutes is a miracle till now)

I would like to know what are the factors that contribute
the CPU time of a COBOL-DB2 Batch job....
Like volume of data accessed...

Thanks for the quick responce Marc.
Vinodh

 

[gregsimpson]

Vinodh,

I suspect you are still talking about

thread178-401838 something very similar.

Obviosuly you are not running the same data in each run, else why run again. I think what is happening is your input data although always around the same size is different every time.

As you don't have indexes you are potentially doing a full table scan for each record you use as input to your process. If DB2 encounters these records early on in the scan you will use less CPU. However if it happends that "this runs" records are near the end, you will use much more CPU. As your input are random, you are getting random CPU usage over the various runs.

You must get those indexes created to support your query.
Greg

 

[MarcLodge]

Hi again Vinodh,
I hadn't seen the earlier thread, and Greg may well be correct. If you are processing tables without indexes, your processing will not be very swift. That said, I wouldn't have thought that it would fluctuate from 13m CPU to 2H CPU.

Could you let us know if you are processing tables without indexes?

Marc

 

[8101]

Greg, Marc

Thank you very much for your suggestions.
It's a great start for me in this Forum....

Last couple of weeks it's of great help to me to get
your help and opinions.. "at the very right time"

Yes. You both are right. Index is the key which made the difference. The idexes are created by our DBA. Now the performance has improved a lot and also the CPU time was NOT erratic now for the same data.

A Big! Thanks for all your help so far.

I have few more queries (this NOT related to CPU Time...)

1. What OPTIMIZE FOR 1 ROW mean?
In what way it will increase the performance...
Does it picks a Optmize path?
Can we use this in Cursor which looks into table of 5 million records????

2. Say if the index are created on fields f1,f2,f3 on table t1... and if we give select f4,45,f6 from t1 where
f1 ='12' and f2 = ... and f3 = ... and f7 =....
Is this a efficient way? (i.e., the order of where conditions is in sync with the order in which index are created.) Does any other way to frame the where clause??

3. For just addition we are using COMPUTE.
Does replacing COMPUTE with ADD will improve performance

Now the compute is performed lakhs of times in real exec.

As usual your earlier response will help us a lot!!!!

Am having a good learning in this exercis of Performance Tuning which we are supposed to do...

Thanks
Vinodh