it's essential to manage how long work processes run to ensure system stability
and optimal performance. SAP provides specific parameters to set maximum runtimes for
tasks based on their priority levels.
Let's dive into how you can control this with these dispatcher parameters:
Parameters
1. rdisp/scheduler/prio_low/max_runtime
Short text
Maximum runtime for low priority dialog requests
Parameter Description:
• This parameter limits the time for which a low-priority request can run uninterrupted
in a dialog work process before it is forced to terminate.
Interruptions, that is, activities that could lead to a work process switch (roll-out) (for
example, WAIT statements or RFC calls) each restart the time interval at zero.
• When combined with the parameters for the other priorities (see
rdisp/scheduler/prio_*/max_runtime), it makes it possible to distinguish the
maximum runtimes using the priorities.
• The system assigns low priority to all RFC dialog requests that are triggered by a
background request.
• The intention behind this parameter is mainly defensive.
• It limits the consequences of an activity unintentionally running for a long time: it
means that a hanging request or a programming error cannot indefinitely block a work
process that is intended for low-priority activities.
• Since extremely long runtimes are normal for background requests, and do not
indiciate an error, you should normally choose a very high value for this parameter,
or not set the parameter at all.
• After the maximum runtime has expired, the program terminates at two levels:
o If the program is currently executing ABAP commands, the ABAP processor
terminates the program.
o If the program is hanging in an external command, such as SQL, the entire
work process is terminated after a second time period of a maximum of 60
seconds, and the user context is reset after the process restart.
o An ABAP short dump is generated in both cases
2. rdisp/scheduler/prio_normal/max_runtime
Short text
Maximum runtime for normal priority dialog requests
Parameter Description
• This parameter limits the time for which a request with normal priority can run
uninterrupted in a dialog work process before it is forced to terminate.
• Interruptions, that is, activities that could lead to a work process switch (roll-out) (for
example, WAIT statements or RFC calls) each restart the time interval at zero.
• When combined with the parameters for the other priorities (see
rdisp/scheduler/prio_*/max_runtime), it makes it possible to distinguish the
maximum runtimes using the priorities.
• The system assigns normal priority to all RFC and HTTP dialog requests that are
not directly triggered by user interaction.
• The intention behind this parameter is mainly defensive.
• It limits the consequences of an activity unintentionally running for a long time: it
means that a hanging request or a programming error cannot indefinitely block a
dialog work process that is intended for activities with normal priority.
• Choose a value that allows enough time for correctly-running requests with normal
priority to be processed, even under load.
o After the maximum runtime has expired, the program terminates at two
levels:
o If the program is currently executing ABAP commands, the ABAP processor
terminates the program.
o If the program is hanging in an external command, such as SQL, the entire
work process is terminated after a second time period of a maximum of 60
seconds, and the user context is reset after the process restart.
• An ABAP short dump is generated in both cases
Default Value
60m
3. rdisp/scheduler/prio_high/max_runtime
Short text
Maximum runtime for high priority dialog requests
Parameter Description
• This parameter limits the time for which a high-priority request can run uninterrupted
in a dialog work process before it is forced to terminate.
Interruptions, that is, activities that could lead to a work process switch (roll-out) (for
example, WAIT statements or RFC calls) each restart the time interval at zero.
When combined with the parameters for the other priorities (see
rdisp/scheduler/prio_*/max_runtime), it makes it possible to distinguish the
maximum runtimes using the priorities.
• The system assigns high priority to all dialog requests that are directly triggered
by user interaction (GUI, RFC remote logon through SM51), and to all system
requests (everything that runs in the dialog work process and is not GUI, HTTP,
or RFC).
• The intention behind this parameter is mainly defensive.
• It limits the consequences of an activity unintentionally running for a long time: it
means that a hanging request or a programming error cannot indefinitely block a
dialog work process that is intended for high priority activities.
Choose a value that allows enough time for correctly-running high priority requests
to be processed, even under load.
• After the maximum runtime has expired, the program terminates at two levels:
o If the program is currently executing ABAP commands, the ABAP processor
terminates the program.
o If the program is hanging in an external command, such as SQL, the entire
work process is terminated after a second time period of a maximum of 60
seconds, and the user context is reset after the process restart.
o An ABAP short dump is generated in both cases.
• In the case of HTTP requests, remember that there is a second timeout (see the
subparameter PROCTIMEOUT of the parameter icm/server_port).
• To prevent double timeouts, the default value of this parameter is set slightly lower
than the value of the parameter rdisp/scheduler/prio_high/max_runtime. Remember
this when making changes to the configuration.
Default Value
11m
How to Set Limits
To configure these parameters, follow these steps:
1. Go to Transaction Code: RZ11.
2. Search for the parameter (rdisp/scheduler/prio_low/max_runtime,
rdisp/scheduler/prio_normal/max_runtime, or rdisp/scheduler/prio_high/max_runtime).
3. Set the new value (runtime in seconds) based on system requirements.
4. Save the changes.
The system may require a restart for the changes to take effect.
Relevant SAP Note
To gain further insights, refer to SAP Note 2378706. This note provides details about setting
runtime parameters and their impact on system behavior.
Use Cases
1. Batch Job Management: In scenarios where background jobs (batch processing) are
taking longer than expected, setting rdisp/scheduler/prio_low/max_runtime ensures
these jobs don't block other system activities.
2. High-Priority Updates: Setting limits for high-priority tasks prevents update
processes from monopolizing resources, especially during peak hours.
3. Interactive Sessions: For systems with high user interaction, adjusting
rdisp/scheduler/prio_normal/max_runtime helps maintain response times and a
seamless user experience.
Troubleshooting Common Issues:
1. Long-running Background Jobs: If a background job is frequently terminated due to
the rdisp/scheduler/prio_low/max_runtime setting, consider adjusting the job’s
priority or splitting it into smaller tasks.
2. System Hanging or Performance Degradation: When normal or high-priority tasks
are terminated often, it may indicate underlying performance issues. Check for
database bottlenecks or high memory consumption
3. Frequent Dispatcher Restarts: Incorrectly set parameters may lead to frequent
dispatcher restarts, impacting system availability. Always monitor the impact of
changes and adjust gradually.By fine-tuning these parameters, you can strike a
balance between task completion and system performance
0 Comments