Request: How are background jobs distributed to the servers?
Other termsTarget server
Reason and PrerequisitesThere is some ambiguity as to what is processed when and where. Jobs are hanging in the status 'released'.
SolutionProcessing of jobs with a predefined start time:
On every server with at least one background work process, a background processing scheduler runs periodically (the period is defined by the parameters rdisp/btctime): On every run, this checks whether background work processes are free on its application server. If this is the case, pending jobs are selected from table TBTCS (job queue) and are distributed to the processes according to the following criteria (in order of priority):
- 1. Jobs with class A have priority over jobs with class B, which has priority over class C.
- 2. Jobs that are especially scheduled for this server have priority over jobs of the same class that are not scheduled for a particular server.
- 3. If two jobs are equal after having applied the criteria mentioned above, jobs with a longer waiting time have priority. This gives a maximum job throughput per hour per server (only for short-running jobs) of:
Jobs/Hour = No. of background processes * 3600 / 'rdisp/btctime'
The background processing schedulers work independently of each other. If a background work process is free on more than one background processing server, the server chosen is the one whose background processing scheduler is randomly activated first.
- Job with target host: The target host is checked immediately, to see whether at least one background work process is free for the required job class. If so, a request then is sent to the host to start the job immediately. If no work process is free, the job is put in the job queue with the current date/time, in the same way as any other job with a predetermined start time.
- Job without target hosts: A host is randomly chosen from the list of all available hosts where free background work processes are available for the required job class. If no free work processes can be found, the job is also put in the job queue with the current date and time.
- If an event is triggered in the SAP system, the event scheduler is immediately started. The event scheduler runs on a particular application server (see below). It selects all jobs that have been waiting for the triggered event. The event scheduler can only start jobs on the server on which it is running. If there are insufficient background processing resources on this server, the system changes the remaining jobs to time-controlled jobs.
Even jobs that have a different target server are changed to time- controlled jobs.
There are three ways of triggering an event in the SAP System. When an event is triggered, the server on which the event scheduler is running is also specified (explicitly or implicitly):
1. BP_EVENT_RAISE function
The TARGET_INSTANCE parameter specifies the server on which the event scheduler is running. If this parameter is empty, the event scheduler runs on the server specified in the rdisp/btcname profile parameter. In this case, the profile parameter is analyzed on the server on which BP_EVENT_RAISE was called.
2. Transaction SM64
The system calls BP_EVENT_RAISE internally with an empty TARGET_INSTANCE parameter (see 1).
In future releases, it may be possible to specify the TARGET_INSTANCE parameter.
3. sapevt program
This is a program written and executed in C; it is located by default in the same directory as the kernel executables. If an event is triggered using sapevt, the event scheduler runs on the application server that has been active for the longest time.
- Both start conditions are executed using events, so the system behaves in exactly the same way as with event-started jobs.
- When defining operation modes (RZ04), you can reserve one or more background work processes for jobs with class A.
This is done as follows: RZ04 -> "New operation mode" -> save -> doubleclick on the name of the operation mode -> "New instance" -> "Current settings" -> cursor to "Job-Cl.-A" -> "More" -> save.
The individual background work processes will still be equal. Reserving n background work processes for jobclass A means that jobs of class B and C will only run on this server if there are at least n+1 free background work processes.
The number of background work processes reserved for job class A must of course be smaller than the total number of background work processes (shown on the same screen); otherwise jobs of classes B and C won't run. The new operation mode can only be activated if it is scheduled with Transaction SM63.
- Note concerning the workload:
Since the job schedulers run independently on each application server, a job WITHOUT a target computer can be taken from any scheduler and run on the corresponding application server. Thus, the workload is distributed equally on all servers.
Each scheduler distributes as many jobs as there are background work processes on the corresponding application server. When the scheduler is running, the system load on the respective application server is not considered. Therefore the number of configured background work processes should not cause any performance problems - even if all background processes are used
No comments:
Post a Comment