Symptom
After the instance start, at a time that roughly corresponds to the
time when the instance profile parameter rdisp/wp_auto_restart expires,
none of the work processes are available because they are automatically
restarted. As the runtime of the instance increases (relative to the
value of the parameter rdisp/wp_auto_restart), the problem no longer
occurs.
Other Terms
rdisp/wp_auto_restart, rdisp/noptime
Reason and Prerequisites
Reason:
After the instance start, all of the work processes have a similar time for the first automatic restart. Under certain circumstances, this may result in all or almost all of the work processes restarting at the same time.
You notice that:
Prerequisites:
Since work processes do NOT restart themselves if they are processing a request (in other words, they are active), the processes desynchronize themselves over time and therefore, the problem is restricted to the time after the instance start.
After the instance start, all of the work processes have a similar time for the first automatic restart. Under certain circumstances, this may result in all or almost all of the work processes restarting at the same time.
You notice that:
- The restart occurs only if the work process is idle (no functional adverse effect in live operation).
- The decision regarding whether a restart should occur is made when a new request is received in the work process. Therefore, if a work process never receives a request for processing (for example, DIA processes with a high number when there is a low load), it is less likely that this will be restarted. You can work around the latter using the parameter rdisp/noptime.
Prerequisites:
Since work processes do NOT restart themselves if they are processing a request (in other words, they are active), the processes desynchronize themselves over time and therefore, the problem is restricted to the time after the instance start.
Solution
Workaround:
Approximately 20 minutes after the instance start in transaction SM50, you can select half of the DIA processes (preferably, the half with HIGH process numbers) and manually restart them using the pull-down menu
"SM50 -> Process -> Cancel Without Core".
Since the automatic restart is executed based on the time of the last restart, you have therefore already desynchronized the processes.
Solution:
If you apply the kernel patch level specified, the process is restarted only after rdisp/wp_auto_restart has expired PLUS a random value between 0 and 900 seconds. Therefore, the first restart is already sufficiently desynchronized. The value of 900 seconds CANNOT be changed.
Note that the processes do NOT restart EXACTLY after rdisp/wp_auto_restart, rather only AFTER the next request has been processed AFTER rdisp/wp_auto_restart expires.
This means that if a system does NOT process any requests, the process does not restart either. HOWEVER, there is the parameter rdisp/noptime (in seconds) that sends a dummy request to ALL work processes and therefore also triggers the check for the work process restart. However, this mechanism removes the desynchronization originally described in this SAP Note because the noptime request comes at the same time for all processes. If the wp_auto_restart time has long since expired, all processes are again restarted at the same time as a result. However, since this occurs in particular if the processes have been idle for a long time, this usually does not affect performance.
UPDATE: SAP Note 1810925 discusses the problem that the parameter rdisp/noptime SYNCHRONIZES the processes again when you restart (see Related Notes). We recommend that you apply the patch level specified in SAP Note 1810925. (End of January 2013).
Approximately 20 minutes after the instance start in transaction SM50, you can select half of the DIA processes (preferably, the half with HIGH process numbers) and manually restart them using the pull-down menu
"SM50 -> Process -> Cancel Without Core".
Since the automatic restart is executed based on the time of the last restart, you have therefore already desynchronized the processes.
Solution:
If you apply the kernel patch level specified, the process is restarted only after rdisp/wp_auto_restart has expired PLUS a random value between 0 and 900 seconds. Therefore, the first restart is already sufficiently desynchronized. The value of 900 seconds CANNOT be changed.
Note that the processes do NOT restart EXACTLY after rdisp/wp_auto_restart, rather only AFTER the next request has been processed AFTER rdisp/wp_auto_restart expires.
This means that if a system does NOT process any requests, the process does not restart either. HOWEVER, there is the parameter rdisp/noptime (in seconds) that sends a dummy request to ALL work processes and therefore also triggers the check for the work process restart. However, this mechanism removes the desynchronization originally described in this SAP Note because the noptime request comes at the same time for all processes. If the wp_auto_restart time has long since expired, all processes are again restarted at the same time as a result. However, since this occurs in particular if the processes have been idle for a long time, this usually does not affect performance.
UPDATE: SAP Note 1810925 discusses the problem that the parameter rdisp/noptime SYNCHRONIZES the processes again when you restart (see Related Notes). We recommend that you apply the patch level specified in SAP Note 1810925. (End of January 2013).
Header Data
| Released On | 29.01.2013 15:55:44 |
| Release Status | Released for Customer |
| Component | BC-CST-DP Dispatcher, Task Handler |
| Priority | Correction with low priority |
| Category | Help for error analysis |
No comments:
Post a Comment