Displaying Detailed Work Process Information

Procedure

1. Choose CCMS ® Control/monitoring ® Work process overview. Alternatively, call Transaction SM66.
2. Position the cursor on the instance and choose Choose. You can terminate the program that is currently running and debug it.

For background processes, additional information is available for the background job that is currently running. You can only display this information, if you are logged onto the instance where the job is running, or if you choose Settings and deselect Display only abbreviated information, avoid RFC. In any case, the job must still be running.

Monitoring Servers and Work Processes

Use

When an operation mode has been switched, you can see in the process overview whether the work process types have been changed correctly.

Procedure

To monitor the work processes on your current application server:

From the R/3 initial screen, choose Tools ® Administration ® Monitor ® System monitoring ® Process overview. Alternatively, call Transaction SM50.

The system displays an overview of the work processes for the server you have logged onto.

The information for each work process is displayed in a line. The Ty. column shows the work process type: for example, DIA is a dialog process, BTC is a background process.

To monitor the work processes on a different application server:

From the R/3 initial screen, choose Tools ® Administration ® Monitor ® System monitoring ® Servers. Alternatively, call Transaction SM51.

The system displays a list of the R/3 servers. To display the processes for a particular server, position the cursor on the line containing the server name, then choose Processes.

Dynamic Work Processes

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=).

Recommendation

This 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 (*}.

Caution

The 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.

Profile Parameters for Work Process Configuration

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.

Example

In 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.

How to Determine the optimum No of Work Process

IF you want to find out the optimum no of work processes there are two ways
1) Goto transaction sm50 and click CPU as shown in figure

or press ctrl+shift+f6 . You will see the cpu total times of the work processes . If you have WPs whose CPU time is very less (Say less than 0:20), you can decrease the number of WPS of that type . If the CPU time of certain type of work process is high, you may decide to increase their no.

2) Another method is to go for transaction Al12 then click all servers as shown


Then you will see the total no of requests for each work process. If all the dialog work process have large no of requests then you can add additional dia wps. If you have less dia wps with less requests , then you can decrease the no of dia wps.
This method is useful in deciding which operation mode to be used at a particular time.

Types of Work Process in Sap

There are five types of work process in sap

Dialog Work process: The Dialog work process fulfill all requests for the execution of dialog steps triggered by an active user. The dialog work process are not used for request which take long time and which use more cpu. Every dispatcher requires at least two dialog work processes. The dialog work process default time is 300 secs. If the dialog work process does not respond in this time, it will be terminated. Also dialog work process are multiplexed to handle large no of user request. Learn more about multiplexing here . You can set the maximum response time of dialog work process from transaction rz11 & set the parameter rdisp/max_wprun_time to time you need. The no of dialog work process can be changed by changing the parameter rdisp/wp_no_dia.

Background Work process: The background work processes execute programs that run without user interaction. At least two background work processes are required per SAP system. More than one background work processes can be configured per dispatcher. Usually the background work process are used for carrying jobs that take long time to finish, like client copy, client transport etc.., Then no of background work process can be changed by changing the parameter rdisp/wp_no_btc . There are two types of background work process. They are A type and B type. A type background work process are used for mission critical jobs. Background jobs of priority a have high priority than B type back ground jobs.

Update Work Process: Update work processes execute update requests. You need at least one update work process per SAP system and you can have more than one per dispatcher. The profile parameter rdisp/wp_no_vb is used to control the no of update work process and rdisp/wp_no_vb2 for not of update work process of type v2. There are two types of update work process. They are v1 and v2. v1 update jobs have higher priority than v2 jobs. v1 jobs are used for critical jobs. There must be at least one V1 update work process in the SAP System. However there can be more than than one.V2 modules describe less critical secondary changes. These are pure statistical updates, for example, such as result calculations.

Spool work process: The Spool work process pass sequential data flows on to printers. Every SAP system requires at least one Spool work process. However, there can be more than one per dispatcher. The parameter to set the no of spool work process is rdisp/wp_no_spo.

Enqueue Work Process: The Enqueue work process administers the lock table in the shared memory. The lock table contains the logical database locks of the ABAP stack. Only one enqueue work process is needed for each SAP system. This is present on the central instance. You can determine or find an central instance by looking the the various work process present in it. For example, only the central instance contains enqueue and message work process. rdisp/wp_no_enq. It is not dynamically switchable.

You can see an overview of all work processes in the application server by calling transaction sm50.