High processing time in STAD

[Former Member]

Hi,

we now have a problem in production where at some times during the day, the response times of transactions on a particular application server get much higher than the normal.

We have looked at stad (workload) at these times and noticed an increase in processing time but not in cpu time.

We looked at the machine statistics and nothing was out of order at those times. (cpu, network, etc).

What is also strange is that we have other application servers running on the same machine which do not have the problem.

The question is how can we find out in which component is this processing time taking place ?

In what components can processing time happen ?

Thank you.

[Former Member · Accepted solution]

Hi Thierry,

As you were saying that this happenend only for 3 minutes and it doesnot happen again,

I would suggest you to anlayze as follows:

Open sm50 screen at the time of this problem occurance and keep on refreshing the screen so that you can see whats happening actually.

At the same time open st06 and monitor top cpu's, here you can see whether CPU utilization is high or normal. And also u can see the users who are responsible for this.

And regarding the Abap trace u cannot trace for all the users at a time, eventhough you are using * near the username field.Only for one user u can trace.

so based on the above sm50 and st06 you can investigate what is happening and you can trace based on that particular user.

Hope this helps.

Thanks,

Kiran

[Former Member]

Hi Thierry,

In Stad if we see Processing time is much higher than the CPU time,

there may be some lost time.

You can confirm this lost time as follows:

Perform ST05 or ST12 trace for any particular transaction and you can

see the Detialed trace list. Search for the particular time stamp

for which STAD has been opened in the detailed trace list.

Difference between the two consecutive time stamps should be equal to the

value in the duration column. If this is not equal, means some lost time

is there.

Inorder to find where this lost time has occured, go to the transaction

SQLR and for the same time and date( which you entered in STAD). If you click on the

Summary tab, then you can see the SQL Trace Records with Longest Non-Database Times (Gaps).

You can tune the programs listed in this table.

Note: STAD and SQLR data won't be available for more that 24 hours, so better have the data copied in HTML format.

There may be some kernel bug also for this difference in the CPU and processing time. But as per your message, other application servers are fine.

If you need any help kindly attach trace files and stad record files to this message so that will try to figure out the exact problem.

Please dont forget to check the kernel level of your system before performing the ST05 trace.

For 700 release minimum patch level should be 145

For 640 release minimum patch level should be 193.

If your system kernel patch is not updated, kindly update it and do the trace to avoid system crash.

Hope this helps.

Please feel free to contact.

Regards,

Kiran

[Former Member]

Thank you for your reply.

We've had the problem again today. It lasts about 3 minutes and then dosn't happen again.

I don't think it is something specific to a transaction or program because when it happens, it affects many different programs. I tried to do the traces you mentionned and I don't see gaps. Also, if I trace all users, I don't get the ABAP trace.

We've checked oracle, cpu and networks and find nothing.

The strange thing we find is that only one of our application servers has this problem. We have arround 16 servers and it is the only one that has these slowdowns.

Thanks.

[Former Member]

Hi

Check if any resource intensive background job is scheduled at that time.

Also through STAD you can check all the transactions executed during that period.

Regards

Rahul

[Former Member]

Hi,

by looking at what was actually happening during the system slowdowns, we now beleive that it is a load balancing problem. We noticed that when this happens , arround 500 new connections are sent to our this application server. We were using the load balancing by quality and response time calculation. We have a lot of RFC connections in that app server which are not taken into account when doing the calculation. We are now going to try putting the round robin load balancing method to see if it solves our problem.

Thanks for your help.

Thierry