Joined: 09 Nov 2010 Posts: 27 Location: SHENZHEN CHINA
Hi, friends,
Recently I am engaged in batch performance tuning, but I was really confused by the DFSORT MERGE tool, since it works worse than COBOL program, even worse than sort in some cases(hiperspace is enough for sort).
I can guarantee input files in order individually, will MERGE tool take extra time to check the order of every input file ?
Once I suppose the performance difference between SORT and merge is N*LOGN vs N, is it right?
The maximum available resource for me: main storage: 28G, mips: 2600.
and there're 2 million records in each SORTINnn dataset.
the cpu time for this step is 3.9 minutes, excp 301K, elapse time 10 minutes.
with COBOL program read, compare, and write,
the cpu time for this step is 2.5 minutes, excp 680K, elapse time 6 minutes.
Joined: 09 Nov 2010 Posts: 27 Location: SHENZHEN CHINA
Hi, dick,
the MERGE process implemented by COBOL just like the MERGE illustration showed in DFSORT Application Programming Guide (Figure 14),just read and choose the record whose key is the minmum one.
2600 MIPS is the highest limit for my testing environment, there's also some other jobs being executed.
As to storage, I guess the sort performance will be affected by main storage, if sort possess enough main storage, there's no need to swap intermediate sorted result back to disk.
I'll try to copy and post the JCL log messages from my performance tuning environment.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Quote:
As to storage, I guess the sort performance will be affected by main storage, if sort possess enough main storage, there's no need to swap intermediate sorted result back to disk.
Well, there is some truth here, but this truth should not be as significant when doing a MERGE. . .
Lots of storage can help speed up a SORT because things may be done in-core instead of with i/o (as you mention).
It will still be most helpful if the information from both the MERGE and the COBOL runs are posted.