ST12 performance tuning background job

[Former Member]

I would like to trace a program which will run about 3 hours. In ST12, I cannot run the program in "current mode" since the execution time is too long. How can I still use ST12 to trace the program execution when the program execute is submitted as background? Pls advise the detail configuration needed in ST12.

Thanks very much for your help!

PS: I tried to use "trace for" user instead of "current mode", and set the tasktype to "BT", when I press "start trace" and start the program background job in another session, seems nothing can be traced...

Edited by: Wing Yin, Anthony TANG on Aug 7, 2009 6:10 AM

[former_member192616]

Hi,

did you set up the trace on the same server where you background job was running?

3 hours is quite long... not possible to trace the whole execution.

With ST12 / SE30 (ABAP Trace) you can trace at maximum 4293 seconds. For ST05 i don't know no other limit then file size.

However you should not take such big traces.

Start with analyzing the STAD record in order to understand where the time is spent (CPU time, DB time, RFC + CPIC time, ...).

For CPU time you can continue with ST12 / SE30, for DB time you need ST05 and for RFC + CPIC time you can check the RFC Subrecords in STAD to see the 5 most expensive RFC calls (destination and FM).

In case of DB time a SQL Cache reset before the job execution and a delta analysis after the execution could help as

well if there is not too much other DB load on the system.

You can take some samples with traces. Start n traces with a few minutes duration and check the results agains STAD (overview). E.g. if according to STAD most of the time is spent in DB time but your sample trace shows mostly CPU time,

your sample is probably not a a good sample (not showing you a part where most of your time is spent).

Other than that, if your Batch Job is your program, you cann add some mesages to the job log to narrow down what part

of the programm consumes time (data selection, data processing, ...) . Another option is to evaluate if you can reduce the

processed data volume to take a trace in order to find out expensive parts of the program. This of course can change the

execution (e.g. of SQL statements) significantly.

You see analyzing long running batch processes could be a challenge

Kind regards,

Hermann

[former_member285005]

Hi,

While 3 hrs is too long a time to trace, it amount of the trace captured depends on the activity that is being monitored. You can trace a backgroud job by releasing the job and then switching on the trace for the process used by the job. Thanks

Regards,

Pramod

[Former Member]

Try analysing with a subset of the data (limit the data being processed by restricting it with the criteria you enter on the selection screen).

If possible share your code with us so that we could point out potential areas of improvement.

[Former Member]

While I agree with others that 3 hrs is too long for a trace and the trace file will get big but You do have an option to first do a SE30 for a background process. You will find how to do that by searching the forum for "SE30 in background". After you have the se30 analysis you can find out problem routines and try to optimize them.

[former_member194613]

an analysis is not something which you run in the night and then you check it in the morning, this give you useless results.

First try to make you job smaller, reduce the selection interval or whatever process less in less time, try to go down to 30min.

Or do it, and monitor it with the SM50, what is going on, start debugging just by chance, probability will lead into the routine which are most expensive. (Monte-Carlo Analysis)

Run SE30 in parallel, in several steps. The SE30 can not trace 3 hours because the time field is an integer and too small.

But do it in 2 or steps, one per hour. Use aggregation by call position.

The ST12 uses the SE30.

Siegfried

[Former Member]

First check with ST03N(select task type as background), whether the high response time is from CPU or from DB.

1. If its an DB then check with ST04, here you can filter by program and check the execution plan.

2, If its an CPU then the maximum problem would be in internal table processing which includes Read table. Activate ABAP trace by SE30/ST12.

Regards,

Vadamalai A.