SAP R/3 форум ABAP консультантов

[admin]

Note 39412 - How many work processes to configure

Symptom
This note answers the following questions:

• How many work processes must and may be configured?
  
• What number makes sense?
  
• How can you see which processes exist and what they do?
  
• How do you set the number?

Other terms
RZ04, RZ10, SM63, SM50, SM51, SM66

Solution
Definition: In this note, "server" is a synonym for "instance".

Technical conditions:
DIA (dialog):
Number of processes: At least the number of all configured non-dialog work processes on this instance (see Note 90631)

UPD (update):
Number of update servers: Update must occur on at least one server.
Releases 2.1 and 2.2:
Only configurations with one update server are supported. The name of this server is defined by the system parameter rdisp/vbname. At least one UPD process must run on this server.
In Releases 2.1 and 2.2 several update servers should be used only if absolutely necessary (performance).
The parameter rdisp/vbname defines where the update requests must be sent for every server. At least one update process must run on each of update servers. Also refer to Note 7209.
The following applies to Release 3.0:
Several update servers are permissible. There must be at least one update process running somewhere in the system. The assignment is not carried out via rdisp/vbname, but dynamically.
If several code pages are used at the same time in one system, there are further restrictions (see notes under key word "MNLS").

UP2 (update U2 - as of Release 3.0):
If there are UP2 processes in the system, U2 update (update low priority) is only possible in these processes; the UPD processes are then reserved for U1 (update high priority).
If there are no UP2 processes, the UPD processes take over both U1 and U2.
Hence, UP2 processes do not have to exist. However, delays can occur for the U1 update if there are no UP2 processes. If you decide to configure UP2 on an instance, we recommend to define at least TWO UP2 on such an instance.

BTC (background):
Number of processes: at least 1 in each system, during the upgrade, at least 2.
Reservation of processes for job class A:
If n background processes are running, a maximum of n-1 processes may be reserved for class A jobs, as jobs with class B and C would otherwise be blocked (see Note 36280).

ENQ (Enqueue):
Number of servers: there is exactly one enqueue server in the system (system parameter rdisp/enqname)
Number of processes: One ENQ process must be running on the enqueue server. Only in certain special cases (extremely large systems) can it make sense to have more than one ENQ process running (on the same instance).

SPO (Spool):
Number of processes per system: as many as required, at least 1
Number of processes per servers:
For Releases 2.x/3.x: a maximum of 1
For Releases as of 4.0A: as many as required
See Note 108799 to decide how many spool work processes should be configured.

Restrictions:
Spool processes cannot be switched on and off when switching operation modes.
Up to and including Release 2.1J and 2.2D: if several servers of the same system are installed on the same host, one spool work process may run on a maximum of one of these servers.

Summary:
From the above, the following theoretical minimum configurations result:
for a central system: 4 DIA, 1 UPD, 0 UP2, 1 BTC, 1 ENQ, 1 SPO.
for a dialog server: 2 DIA, 0 UPD, 0 UP2, 0 BTC, 0 ENQ, 0 SPO

How many work processes are useful?

• If there are too few processes of one type...
  ... requests (dialog steps, updates, background jobs) must wait for free work processes. The ideal is a configuration in which at least one work process is always free. With transaction SM50, you will see that the dialog work process with the highest number uses almost no CPU time. (Equivalent: If I want to telephone from A to B, I do not want to wait. Thus, the lines should never be 100% busy.)
  
• If too many processes are configured...
  ... swap space is consumed, and the system may become slightly slower due to operating system paging. Thus, if you have limited memory resources and the machine is heavily loaded, it may make sense to keep the number of processes not unnecessarily high. Dialog users or background jobs will then have to wait for free processes, but that is less of a problem than if the entire system is slow.
  
• If the machine is very powerful...
  ... it may make sense, to install several instances rather than one (see Note 21960) or even better change over to a 64-bit operating system.
  
• As the demands on a server can vary, it often makes sense to define different operation modes for the entire system.
  Example: Daytime operation - many dialog processes; Nighttime operation - many background processes
  The total number of work processes (DIA+UPD+UP2+BTC+ENQ+SPO) may not change during the switch; this applies to every server. The number of spool processes (SPO) must also remain constant.

How do I see which work processes exist and what they do?

Local:
Tools -> Administration -> Monitor -> System monitoring -> Processes (Transaction SM50)

Global:
Tools -> Administration -> Monitor -> System monitoring -> Server -> <Double_click> (Transaction SM51)
or:
Tools -> Administration -> Computing center -> Management System -> Control -> All Work processes (Transaction SM66, the selection of processes is adjustable)
To see the utilization of the services (dialog, update): ST03 - > Performance Database -> Task Type Profile

System parameter setting:
The number of work processes is initially predefined by the following system parameters:
rdisp/wp_no_dia
rdisp/wp_no_vb
rdisp/wp_no_vb2
rdisp/wp_no_btc
rdisp/wp_no_enq
rdisp/wp_no_spo
By defining the operating modes, you can dynamically change the distribution of work processes to services. The reservation of background work processes for job class A is also carried out exclusively by defining the operation mode.

For the system parameters, there is an online documentation available (see Note 31395).