Dynamic work processes enable the work process configuration of the NetWeaver Application Server (AS ABAP) to be modified in accordance with the current specifications while the system is running. This includes restarting new work processes and closing work processes no longer needed.
Purpose
In older releases there was only the CCMS Operation Mode Switching that enabled the work process type to be changed while the system was running. Work processes of dialog type during the day could be assigned type batch at night time. This type switch was not dynamic (controlled by the system), and neither was it possible to start new processes while the system was running.
Dynamic work processes enable a kind of adaptive computing on the one hand, and on the other hand, enable the system to free itself from deadlocks. They can be seen as a supplement to operation mode switching.
Adaptive Computing
The earlier strategy for configuring an application server assumed fixed hardware conditions. The available hardware resources were distributed among the running applications and the profile parameters set accordingly. To activate new hardware resources, the server had to be restarted. The SAP configuration could be easily changed in the profile file.
The concept of adaptive computing is to let applications run on "virtual hosts", where resources can be changed while the system is running (for instance, a CPU can be added.) For this reason the application server must be able to change the fixed hardware conditions dynamically in order to:
Use the available hardware resources to full capacity
Release these resources when they are needed for other tasks
Once more CPUs have been added to a virtual server, the administrator can use these to full capacity by adding further work processes.
Deadlocks
The situation may arise where one work process needs a further work process in order to process a request. In particular when using RFC, dialog work processes reserve further dialog work processes. Deadlocks may occur when RFC cascades are used to parallelize the workload on a server. This problem cannot be solved with conventional configuration, but with dynamic work processes the dispatcher can recognize deadlocks and start further work processes.
Implementation
The procedure to make more work processes available is implemented in two stages:
Reserved (restricted) work processes: In addition to familiar work process types (dialog, background, spool, and so on), there is also the type reserved. The number of initial work processes (as with the other types also) is specified in the profile parameter rdisp/wp_no_restricted. No further reserved WPs can be created while the system is running.
Reserved work processes are always of the dialog type. They are kept free in normal operation and not used until the system identifies a bottleneck and needs additional work processes to remove it.
Work processes started dynamically If the dynamic work processes are active (rdisp/dynamic_wp_check=TRUE), the system can start new work processes up to the limit specified in rdisp/wp_max_no in order to resolve deadlocks. Dynamic work processes can have different types (dialog, batch, update, and so on).
Standard Setting
No reserved work processes are configured in the standard setting (rdisp/no_restricted = 0), but up to two work processes can be started dynamically rdisp/max_wp_no=
RecommendationThis setting is appropriate if deadlocks are only expected in exceptional cases. If there are many applications transmitting a large number of RFCs, we recommend you configure additional dynamic work processes. To do this set the value to the sum of all configured work processes plus the required number of dynamic work processes (see example below).
End of the recommendation.
Configuration
Dynamic and reserved work processes are configured in profile parameters. All of the parameters described below are documented in detail in the system (transaction RZ11). The newly-added profile parameters are highlighted with an asterisk (*}.
CautionThe maximum number of work processes is 600. This means the sum of all work process types plus the possible number of dynamic work processes. The parameter rdisp/wp_max_no is restricted to this sum.
End of the caution.
Parameter Name | Meaning | Unit | Standard value |
|---|---|---|---|
rdisp/wp_no_dia | Number of work processes of type dialog | Whole number (between 2 and 600) | 2 |
rdisp/wp_no_btc | Number of work processes of type batch (background processing) | Whole number (between 0 and 600) | 0 |
rdisp/wp_no_enq | Number of work processes of type enqueue (only on the enqueue instance >0) | Whole number (between 0 and 5) | 0 |
rdisp/wp_no_vb | Number of work processes of type V1 update (time-critical) | Whole number (between 0 and 600) | 0 |
rdisp/wp_no_vb2 | Number of work processes of type V2 update (not time-critical) | Whole number (between 0 and 600) | 0 |
rdisp/wp_no_spo | Number of work processes of type spool (print) | Whole number (between 0 and 600) | 0 |
rdisp/wp_no_restricted* | Number of reserved work processes (see above) | Whole number (between 0 and 600) | 0 |
rdisp/wp_max_no* | Maximum number of work processes including those created dynamically | Whole number between 2 and 600 (must be larger than the sum of all work process types), or DEFAULT | DEFAULT (Sum of all WPs + 2) |
rdisp/dynamic_wp_check* | Activation of the check in the dispatcher, and if necessary of the starting of dynamic WPs (FALSE deactivates the capability of the server to create dynamic WPs) | Truth value | TRUE |
rdisp/max_dynamic_wp_alive_time* | Lifespan of dynamic work processes: Dynamic work processes should be stopped once the bottleneck is removed. If you are not processing a request, the work processes are stopped after this time interval. | Seconds | 300 |
rdisp/configurable_wp_no* | Number of configurable work processes for the Operation Mode Switching. To enable the dispatcher to resolve deadlocks automatically, at least two work processes are reserved for this purpose in the DEFAULT setting. | Whole number between 0 and 600, or DEFAULT | DEFAULT (maximum number of WPs minus a quarter of all additional WPs (reserved and dynamic) but a maximum of wp_max_no - 2) |
Overview
You can see all the work processes currently running in the process overview (transaction SM50, see also, Displaying and Managing Work Processes).
If you select 
List 
Configuration 
and select the checkbox With Info Area, in the header area you can see how many dynamic work processes are possible and whether any are currently running.
List Configuration and select the checkbox With Info Area, in the header area you can see how many dynamic work processes are possible and whether any are currently running.
ExampleIn the system the parameters have the following settings:
rdisp/wp_no_dia = 16
rdisp/wp_no_btc = 3
rdisp/wp_no_vb = 1
rdisp/wp_max_no = 30
Process overview (transaction SM50) could look like this.
End of the example.
The information shown means the following:
Total Number of Processes: Number of work processes currently running
Dialog: Number of configured work processes, number of dialog WPs currently free
Update, Background, etc. : Analogous information for the other configured WP types
Configurable: Value of parameter rdisp/configurable_wp_no: (here DEFAULT, so calculated according to the formula: maximum number of WPs - ((number of reserved WPs + number of dynamic WPs ) / 4): 38-(10/4) = 36 (rounded off)
Dynamic: maximum number of WPs – configured WPs: 30-20 = 10
Blockade Handling: Here you can see whether the dispatcher has created an additional work process for blockade handling (since the start or the last reset). You can see whether the process is still running in the Total Number of Processes. Choose List Reset to reset the display. The number of dynamic/reserved processes will be set to zero and the line disappears from the display.
Posts
Comments (0)
Post a Comment