PROGRESS step taking longer to finish

[Darek]

Here is an interesting puzzle: somewhere between March and August this year, PROGRESS events in DS jobs take 3 times as long as they used to, including the final "job finished". Any idea what might be causing this issue? Antivirus is off. Disks on SAN.

OLD

Code Select Expand


[PROGRESS   - 22:00:54] Done - 0 00:00:13 elapsed
jobstream -- completed (01-Mar-2007 22:00:54)

NEW

Code Select Expand


[PROGRESS   - 20:01:48] Done - 0 00:00:31 elapsed
jobstream -- completed (03-Sep-2007 20:01:51)


OLD

Code Select Expand


[PROGRESS   - 22:00:48] Procedure Node 2 'JOB_PRE_P'; executing (pid 3328)
[USER       - 22:00:53] from Procedure Node 2 'JOB_PRE_P':


NEW

Code Select Expand


[PROGRESS   - 20:01:31] Procedure Node 2 'JOB_PRE_P'; executing (pid 3176)
[USER       - 20:01:46] from Procedure Node 2 'JOB_PRE_P':


[MFGF]

Hi,

A couple of other things that might be worth you looking at:

1. Is the slowdown caused by the database your catalog tables reside in.  When was the last time it was maintained?

2. Do you have the audit options switched on for your jobstream, and if so, how large are the audit tables in the catalog database?

3. Where are the log files getting written to?  Is the disk in question getting full so that each log file is fragmented?

By the looks of things, the whole jobstream now takes longer, but it might be worth checking if this is caused just by the one procedure node, or if every node in the jobstream now takes longer than it did.  Try turning on detail logging temporarily - this may give you more information to work with.

The other thought is that something else on the server may be running in competition with your jobstream and starving it of resources?

Happy hunting!

MF.

[elealos]

I agree that additional logging detail would help  to collect more information. You can also use the audit feature from the designer interface to trace through which nodes/builds are taking longer, and what the trend is. 

[Darek]

We've ended up reporting it to Cognos Product Development. They are looking into it. For now, having DS separate from SQL resolves the issue.