39412 SAP OSS Note - How many work processes should be configured?

This note answers the following questions:


,,How many work processes must and may be configured?


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


,,How do I set the number of work processes?






Cause of the problem and Pre-requisites

*






Solution instructions

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


Technical conditions:


,,DIA (dialog):


,,Number of processes: There must be at least as many processes as the


total of configured non-dialog work processes on this instance (

also see Note 934109).


,,If a J2EE instance (dual-stack instance) exists, the minimum number of


DIA processes must be 5.

,,UPD (update):


,,Number of update servers: The update must occur on at least one


server.

,,Release 2.1 and 2.2 :


,,Only configurations with exactly one update server in the system are


officially 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 for each server where the update requests must be sent. At


least one update process must run on each of these update servers.

 Also refer to Note 7209.


,,The following applies to Release 3.0:


,,Several update servers are allowed. There must be at least one update


process somewhere in the system. The assignment is not carried

out via rdisp/vbname, but is carried out dynamically.


,,If several code pages are used at the same time in one system, there


are further restrictions (see the notes under the key word "MNLS

").


,,UP2 (update V2 - as of Release 3.0):


,,If there are UP2 processes in the system, a V2 update (an update with


low priority) is possible only in these processes; the UPD proc

esses are then reserved for V1 (an update with high priority).


,,If there are no UP2 processes, the UPD processes take over both V1 and


V2.

,,As a result, UP2 processes do not have to exist. However, the V1


update may be delayed if there are no UP2 processes. If you decide t

o configure UP2 on an instance, we recommend that you define at least


TWO UP2 on such an instance.

,,BTC (background):


,,Number of processes: at least 1 in each system, at least 2 during the


upgrade

,,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. Otherwise, jobs with class B and

C would 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 run on the enqueue server.


It may make sense only in certain special cases (extremely large

 systems) 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 server:


,,The following applies to 2.x/3.x releases: a maximum of 1


,,The following applies to Release 4.0A and above: 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 between


operation modes.

,,The following applies to releases up to and including Release 2.1J and


2.2D: If several servers of the same system are installed on t

he same host, one spool work process may run on a maximum of one of


these servers.

,,To summarize:


,,The following theoretical minimum configurations result from the above


information:

,,for a central system: 5 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. Ideally, you should use a configuration in w

hich at least one work process is always free.


,,Kernel releases UP TO BUT NOT INCLUDING 720:


,,When you use transaction SM50, you will see that the dialog work


process with the highest number uses almost no CPU time.

,,Kernel release FROM AND INCLUDING 720:


,,Requests are distributed more or less evenly, so the CPU time in


transaction SM50 is no longer conclusive. However, you can use the s

erver information queue information in the SM51 "Goto" menu to determine


the maximum number of requests in the DIA queue since the ins

tance start. A large number of requests denotes a temporary "traffic


jam". The performance of the computer dictates what value is actu

ally considered to be a large number of requests. You can find more


information about the periods for which there was a high value in

"dev_disp". See SAP Note 1148690. (Similarly: If someone wants to


telephone from A to B, they do not want to wait. Therefore, the line

s should never be 100% busy.)


,,If too many processes are configured...


,,... only swap space is consumed, and the system may become slightly


slower due to operating system paging. Therefore, if you have lim

ited main memory resources and the machine is heavily loaded, it may


make sense to use a relatively small number of processes. Dialog

users or background jobs will then have to wait for free processes, but


that is less critical compared to the entire system slowing do

wn. For more information, see Note 9942.


,,If the machine is very powerful...


,,... it may make sense, to install several instances (see Note 21960)


or to change over to a 64-bit operating system (an even better s

olution).


,,Since the requirements for a server may 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) must not


change during the switch; this applies to each server. The numb

er 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 -> Process


Overview (transaction SM50)

,,Global:


,,Tools -> Administration -> Monitor -> System Monitoring -> Servers ->


<(><<)>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), choose the


following: Transaction 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 backgro

und work processes for job class A is also carried out exclusively by


defining the operation mode.

Online documentation is available for the system parameters (see Note


31395).

RZ04, RZ10, SM63, SM50, SM51, SM66