Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

ABAP Debugging - impact on system performance?

0 Likes
1,499

Hello,

What is the real impact on system performance by doing ABAP debugging?

We monitor CPU and memory consuption and the impact doesn't seem very relevant, besides that Basis team affirms that it is the cause of all system performance problems...

Thanks a lot!

Hello,

What is the real impact on system performance by doing ABAP debugging?

We monitor CPU and memory consuption and the impact doesn't seem very relevant, besides that Basis team affirms that it is the cause of all system performance problems...

Thanks a lot!

2 REPLIES 2
Read only

0 Likes
907

Hi ,

Debugging does impact the system performance. The shared memory area gets eaten up by the user work process who debugs and hence the other work processes could suffer. We have had this issue in our production system many times and we do debug in production only if it is very critical.

rgds,

raj

Read only

Former Member
0 Likes
907

If you look in SM50 while a debug session is running you will see that the debug holds a dialog process while the debugging is in process, rather than the transaction simply using the dialog process for a short time. With multiple debugs it would be possible to reduce the number of available dialog processes to the point where system processing was seriously affected - effectively a "Denial of Service" type attack within SAP ... However SAP have thought of this and issue an error with the following text when you try to get too many debug sessions.

Andrew

Message Details:

-


No exclusive debugging mode available

Message no. TPDA350

Diagnosis

In "Non-Exclusive Mode", the ABAP Debugger was unable to reserve a work process exclusively for this debugging session. The reason for this is that all available work processes were already in use with other debugging sessions.

Restrictions in "Non-Exclusive Mode":

For every Debugger interaction, a database commit must be triggered. As a result:

- You cannot debug between "SELECT ... ENDSELECT" (short dump in Debugger)

- If the debugging session is cancelled, the database content can become inconsistent.

Since there can be no database inconsistencies in production systems, the "Non-Exclusive Mode" is not possible there. Instead of starting the Debugger in "Non-Exclusive Mode", the system triggers the short dump "DEBUGGING_IMPOSSIBLE".

The number of work processes exclusively available for debugging in production systems is defined in the profile parameter for the number of dialog work processes as follows: "rdisp/wp_no_dia / 2"

In non-production systems, this number is set using the profile parameter "rdisp/wpdbug_max_no". It is recommended that "rdisp/wpdbug_max_no" is roughly equal to "rdisp/wp_no_dia / 2". On the other hand, the default value "rdisp/wpdbug_max_no = 1" is almost always too low.

Procedure

In the meantime, a work process may have become free for exclusive use by the Debugger, so that you could try to switch to "Exclusive Mode" by choosing "Debugger -> Exclusive Debugging Mode On" from the menu.