Technical Monitoring - How to handle Long-Jobs in Dialog Response Time

[Private_Member_19084]

Hi experts,

in Technical Monitoring we are monitoring the response time of R3.

Durring the day everything is fine, as on all instaces a lot of users are on and we have always a good average.

But durring the night I always face the problem, that not many users are working and some big (long) jobs are running.

After the jobs are finished, I always get an alert that the response time was to high.

So my question is, does anybody know how to handle that thing?

I am already working with Counterthreshold (3times in 20 minutes) but I still get somes times the error.

Especially after MRP-Run with parallel-processes.

Maybe somebody have a good idea for this.

I don't want to change the limit for the night, I would prefer if I can make the check without considering the job-time.

Kind regards

[divyanshu_srivastava3]

Hi Christian,

The high response time can be because of multiple factors, especially your DB and it's related memory buffers, and number of cores on your machine. If you make certain adjustments to your database parameters, provided you have enough resources at your end, you can improve the dialog RT.

Also, you should check concurrent jobs running at night, including backup, which could be utilizing lots of resources and queries that are doing sequential/direct reads.

If you get EWA reports for your system, then you can tune as per the recommendation and further take it using standard SAP transaction like ST03N.

For a rough understanding: have a look at Response Times: Rough Guide - Workload Monitor - SAP Library

Regards,

Divyanshu

[divyanshu_srivastava3]

If you are OK with system configuration, then Vivek has just provided a way to handle such cases and avoid such alerts.

[Vivek_Hegde]

Hi Christian,

For such scenarios you can set up Work Modes, Peak Business Hours and Non Peak Business hours, You can have different thresholds at template level for these working hours. This should solve your problem.

Regards,

Vivek