Parallel Processing © SAP AG Parallel Processing.

Parallel Processing © SAP AG Parallel Processing

Content Why ? How ? Possible Problems
Strategies of Parallelization Distribution of processes on several application servers Possible Problems Locking Deadlocks System resources Using parallelization and workload distribution in own programs © SAP AG Parallel Processing

Sequential Work Only one work process is used while other processes are not involved Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 2 Work Process 3 Work Process 4 Sequential (synchronous) processing of work packages means that one process is performing all the work. A work item must be fully processed before the processing of next one can be started. Other processes that are ready to work are not used, available capacities are ignored. © SAP AG Parallel Processing

Parallel Work Many processes are working at the same time
Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 1 Work Process 2 Work Process 2 Work Process 2 Work Process 2 Work Process 2 Work Process 2 Work Process 2 Work Process 2 Work Process 2 Work Process 2 Work Process 2 Work Process 3 Work Process 3 Work Process 3 Work Process 3 Work Process 3 Work Process 3 Work Process 3 Work Process 3 Work Process 3 Work Process 4 Work Process 4 Work Process 4 Work Process 4 Work Process 4 Work Process 4 Work Process 4 Work Process 4 Work Process 4 Parallel (asynchronous) processing means that the workload is distributed into several packages that are processed by several processes in the same time. These processes are working independently. All available capacities are used in order to achieve a minimal total processing time. © SAP AG Parallel Processing

Parallel Processing for mass data processing
Example Request: process 500 IDOCs with avg Line Items in POS-Upload within 8 hours System environment: 1 DB-Server, 5 App.-Servers with 4 CPUs each avg. time for processing: about 10 minutes per IDOC estimated time with sequential processing:  about 80 hours Use the available capacities of your hardware and run 20 processes in parallel. Estimated time:  about 4 hours © SAP AG Parallel Processing

Advantages Parallel Processing is the key
to achieve a higher throughput to minimize the required time until full completion of work to use the available hardware capacities © SAP AG Parallel Processing

Example for a Process Chain
Each part must be finished completely before starting the next one ( total time  t1 + t2 + t3 + t4) Reduce processing time of each single part to reduce the processing time of the whole chain IDOC processing Replenishment Order ..... t1 t2 t3 t4 Time © SAP AG Parallel Processing

Load distribution on several processes (1)
Start and define parallel processes manually Divide your work completely into several packages (e.g. by number intervals or site groups) beforehand Multiple start of a report with different parameters in Background or as Batch Batch Process 1 Batch Process 2 Batch Process 3 Batch Process 4 Batch Process 5 There are different strategies to distribute the workload across several processes In this case, the complete workload is divided into packages by certain formal attributes (e.g. number range, IDOCs from certain shops etc.). Some batch or background processes are started to process this data, so that the work can be scheduled at a time with minimal expected workload on the system (there is no possibility to take the current system load into consideration). Defining packages of almost equal workload using this strategy is not easy, so that the processing of some packages might take much more time than other ones. In order to avoid this, you would always have to perform a previous analysis for the distribution of the work items. But this requires time and efforts by the user. Furthermore, it is not possible to react on unforeseen delays or to take varying performance of different servers into consideration (based on additional load or technical reasons). © SAP AG Parallel Processing

Start one report that starts other processes with fixed packages Hand over all work to a report The report divides it completely into suitable packages (e.g. same number of IDOCs) Further processes are started with fixed packages Dialog/Batch Process 1 The complete data is handed over to a program that defines several work packages. The data is examined in order to define packages with almost equal expected workload, but this takes time. These packages are distributed to other processes that are started by the original program. There is no possibility to react on unforeseen delays or to take varying performance of different servers into consideration (based on additional load or technical reasons). Dialog Process 2 Dialog Process 3 Dialog Process 4 Dialog Process 5 © SAP AG Parallel Processing

Workload Balancing (1) Static distribution beforehand can not consider the real workload. Therefore, time and resources might be wasted before follow-on processes are started. 17 18 19 WP 5 13 14 15 16 WP 4 9 10 11 12 WP 3 5 6 7 8 WP 2 1 2 3 4 WP 1 Distribution of work items according to formal attributes like numbers can cause an unbalanced workload: Work Items with extended processing time can increase the total time until completion of work. Several work processes are not used for a rather long time. Throughput (t) ~ Sum of active time until t time T1 = Time until Completion Goal: minimize T1 T1 waiting active © SAP AG Parallel Processing

Dynamic Workload Distribution Hand over all work to a report The report starts other processes and distributes the work in small packages dynamically (next item after completion of previous) “Distributor” Dialog Process 5 Dialog Process 1 All the data is handed over to a distributor program. It starts several other processes with smaller packages of the data. If a work process has finished its work, the distributor restarts it with a new package. The distributor must not process the data itself. Otherwise it might be busy and not ready to hand over the next item when a process has finished its work. This is a problem of the current version of the standard report for IDOC processing (RBDAPP01). The problem can be solved by applying OSS note This method of workload distribution has a good chance to achieve an (almost) equal load for all processes and no waste of system capacities. Dialog Process 2 Dialog Process 4 Dialog Process 3 © SAP AG Parallel Processing

Workload Balancing (2) Dynamic distribution at runtime is oriented to the real workload and so has a better chance to lead to an equal distribution, a higher throughput and thus reduces the time until full completion. 5 7 10 18 WP 5 4 9 11 15 19 WP 4 3 6 12 13 17 WP 3 2 8 16 WP 2 1 14 WP 1 Distribution of work items oriented to the real processing time can achieve a better workload balancing. Small packages (especially at the end of the processing) help to to achieve this goal! The time until completion of work (T1) is reduced. time T1 (now) T1 (before) waiting active © SAP AG Parallel Processing

Workload Balancing (3) The workload distribution can be optimized by processing work items with highest expected workload first. But the improvement must be weighed against the additional effort for analysis and sorting of the work items. WP 5 6 4 15 18 10 2 5 3 WP 4 17 11 9 16 WP 3 8 7 13 12 WP 2 1 14 19 WP 1 The distribution can be optimized, if work items with the highest expected runtime are processed first. This can be important, if work items cause a very different workload. But analysis and sorting takes time. It must be checked if this additional work is justified by the improvement of the throughput. If all work processes are busy almost until completion of work => The time until full completion of work is minimized and no hardware capacities are unused. time T1 (now) T1 (1st improvement) T1 (1st approach) waiting active © SAP AG Parallel Processing

Benefits of dynamic workload distribution
Even distribution of work packages Oriented to the real processing time not to formal attributes like number ranges or number of work items. Balanced workload distribution minimal impact of unforeseen delays in processing of several work items Note: the program must be designed appropriately (contrary to the other strategies) not all programs are yet designed like that, but currently many transactions are reworked to support this kind of workload distribution. Define small packages, so that a higher processing time for one or some of the final work items does not increase the total time to complete the process too much. © SAP AG Parallel Processing

DON’T Application Server Application Server Application Server
Process Process Process Process Process Process Process Process Process Process Process Process Process Process Process Process Process Process Process Process Process Process Process Process Don’t overload an application server by using all available work processes while other servers have no work. All application servers should be used equally. In this case there are no free work processes on the first Application server but all the other servers are hardly used. This is valid mainly for dialog work processes. You must always keep some free dialog work processes (for monitoring or RFCs inside the programs). You can use all batch processes in order to use the hardware capacities (other batch jobs will then be delayed, of course), but switch to other servers before you have to wait in a queue. Process Process Process Process © SAP AG Parallel Processing

DO Application Server Application Server Application Server
Process Process Process Process Process Process Process Process Process Process Process Process Process Process Process Process © SAP AG Parallel Processing

Note: Workload distribution on application servers (1)
Static load distribution... Definition of background job (SM36) You can create several jobs for the same report but with different select options. It is possible to define the target host on which the scheduled background job will be executed. Default processor is the local host (application server) which was used to define the job. Jobs will be started independently of the current system load at runtime as BTC, but scheduling to a time with expected low data load is possible. © SAP AG Parallel Processing

Note: Workload distribution on application servers (2)
Dynamic load distribution... Usage of Logon Groups (Transaction SMLG) Logon Groups were originally used to distribute the load of all users across the available application servers based on figures such as response time and server load. Logon Groups can be used to schedule background jobs which will produce several dialog work processes (DIAGS) running in parallel. Resource determination for parallel running DIAGS is based on the current system load. The quotas which are used to determine the available resources are fixed. © SAP AG Parallel Processing

Note: aRFC: Resource determination Logon Group
CALL FUNCTION ... DESTINATION IN GROUP ... STARTING NEW TASK 'ABC' Use quotas? yes Group A Message-Server ? Instance 1 Instance 2 Dispatcher-Queue Dispatcher-Queue 1) At least 3 free dialog work processes 2) less than 10 % ongoing requests in the wait queue (Non configurable..) WP1 WP2 WP1 WP2 The server in question has at least three free dialog work processes: This restriction means that at least two dialog work processes remain free for other work in any server that is used by a parallel processing job. The job can start a task in a dialog work process only if two other dialog work processes are currently free in the application server in question. The dispatching queue of the server in question is less than 10 percent full: This restriction prevents a parallel processing job from using a server that is already quite busy. ... ... WP3 WP3 © SAP AG Parallel Processing

Workload distribution using aRFC server groups
Usage of aRFC Server groups ARFC Server Groups can be used to occupy several dialog work processes (DIAGS) on several R/3 instances for parallel processing. The resource determination is performed at runtime and is based on the current system load. The quotas which are used to determine the available resources can be configured separately for each instance. NOTE: The quotas are valid for the R/3 instance and are NOT related to a Server group! © SAP AG Parallel Processing

ARFC: Resource determination aRFC serv. group
CALL FUNCTION ... DESTINATION IN GROUP ... STARTING NEW TASK 'ABC' Use quotas? yes Group B Message-Server ? Instance 1 Instance 2 1) Dispatcher queue: usage rdisp /rfc_max_queue % and 2) At least rdisp/rfc_max_own_used_wp free dialog work processes 3) At most rdisp/rfc_max_login % of allowed logins Dispatcher-Queue Dispatcher-Queue WP1 WP2 WP1 WP2 There are several quotas defining if a server can be used for a RFC: Number of free dialog work processes Portion of user-related dialog work processes Portion of ongoing requests in the dialog queue Portion of logons to the system Portion of your own logons in the system Portion of used communication entries . ... ... WP3 WP3 © SAP AG Parallel Processing

ARFC Server Group Quotas (RZ12)
percentage absolute value From Release 4.5A: Max Request in queue (Profile parameter : rdisp/rfc_max_queue) Quota for the number of maximum requests in the dialog queue. (Default value: 5 %) Max. No of Logons (Profile parameter : rdisp/rfc_max_login) Quota for the number of logons in the system (Default value : 90 %) Max. disp. of own logons (Profile parameter : rdisp/rfc_max_own_login ) Quota for the number of own logons in the system (Default value : 25 %) Max. no of WP used (Profile parameter : rdisp/rfc_max_own_used_wp) Quota for the number of dialog work processes used in the system. (Default value : 75 %) Max. no of free WPs (Profile parameter : rdisp/rfc_min_wait_dia_wp) Number of dialog work processes that should remain free for other users.(Default value : 1 ) Max no. Comm. Entries (Profile parameter: rdisp/rfc_max_comm_entries) Quota for the number of communication entries in the system. (Default value: 90 %) The quotas defined in this transaction are valid only temporarily (until shutdown of the application server) and should be used for test purposes. They must be entered in the instance profile for permanent validity. The quotas are instance specific, the server group used during the configuration in RZ12 is NOT considered (i.e. the settings that were defined for an instance via server group A are also valid if the instance is used as a member of server group B)! In Rel. 4.0B you must use report RSARFCLD for the configuration. © SAP AG Parallel Processing

Locking Several processes can block each other by database locks, enqueue locks or semaphore locks (here: a database lock). Update record 1 Commit WP1 Update record 1 Commit WP2 Update record 1 Commit WP3 Database locks are set by, for example, the SQL commands insert, select for update and update Any delay until releasing the lock by a COMMIT WORK can increase the runtime of other processes waiting for this release. So keep locks as short as possible, especially on objects of central importance for the system. IMPORTANT: A program statement requiring a database lock is potentially waiting until the requested lock is released by the lock-holding process. It only returns, when the request was successful (Exception: some databases cancel one of the processes, sending a “deadlock” error message. But this is not a “real” deadlock situation as described later). An Enqueue request however always returns immediately. and the return code tells about success or failure. A failing request usually does not cause a delay, but a functional reaction by the program (usually: abort). In this case, locking problems do not cause additional runtime, but the failing of a certain part of the work items (e.g. Goods issue for deliveries). Time Lock on Record 1: Work process must wait for the release of the lock Work process must wait for the release of the lock © SAP AG Parallel Processing

Database Lock Monitor (DB01)
Screenshot of a system blocked by database locks. All update processes were blocked except one (PID ) Database locks are set by, for example, the SQL commands select for update and update. Several exclusive lock waits can reduce system performance dramatically. To detect exclusive lock waits, use the Database Lock Monitor: use Transaction DB01, or from the R/3 initial screen, choose: Tools ® Administration ® Monitor ® Performance ® Database ® Exclusive lock waits. If a long exclusive lock wait occurs: Monitor the program which is holding the lock, using, for example, the Database Process Monitor (Transaction ST04; ORACLE session). Is the program executing expensive SQL statements after setting a database lock? As rule of thumb, all expensive SQL statements should be executed before setting the first lock. Find out the user holding the lock so that it can be released. If this is not possible, delete the lock so that other users can work. This will roll back the transaction of the lock holder. The transaction may need to be repeated. For example, the seller may need to take the order a second time. Database locks are generally released at the end of a dialog step or by an explicit commit. © SAP AG Parallel Processing

Example: Locking on Number Range Table NRIV
The Number Range Table NRIV is an object of central importance for the whole system: The unique ID-Numbers for new objects are taken from there (distinct ranges for different types). Uniqueness must be guaranteed even if several processes access a number range at the same time. Locking problems can decrease throughput. Keys of Database table NRIV: CLIENT MANDT OBJECT NROBJ (e.g. MATBELEG) SUBOBJECT NRSOBJ (used at several objects) NRRANGENR NRNR (several intervals can be defined for the same object) TOYEAR NRYEAR (validity) How does number allocation work? The current number of a number range is stored in table NRIV. If a program needs a number for a new document, it reads the current number from NRIV for the respective number range. For that purpose, the program sets a database lock on the corresponding line in NRIV using the SQL statement SELECT FOR UPDATE. Afterwards, the program increases the current number using an UPDATE statement. The number range remains locked on the database until the program completes the DB LUW (by COMMIT or ROLLBACK). If an error occurs in the meantime, i.e. if the document cannot be created, the program uses an ROLLBACK statement which also undoes the change of table NRIV. This procedure assures that the number allocation is without gaps and in chronological order. © SAP AG Parallel Processing

Number Range / Not Buffered (1)
Database Server (NRIV) Allocate Number Application Servers If the numbers are taken from the database without any buffering, the record of for this object type is locked until the creation of the corresponding object is either committed or refused. The request of another number of this number range is blocked during this time. Any delay until committing or refusing the number allocation blocks the creation of other objects of the same type and reduces the benefit of parallel work. no gaps chronological order DB locking system wide prevents parallelism © SAP AG Parallel Processing

Number Range Buffering / Local File (2)
R/3 Instance Allocate Number Database Server (NRIV_LOKAL) R/3 Instance Allocate Number reduce DB locking higher parallelism gaps occurred can be reported (RSSNR0A1) not continuous, not chronological DB locking on each R/3 Instance (solution: see OSS note ) Using this buffering technique, the system takes a number range per R/3 instance and buffers this interval in a further DB table NRIV_LOKAL. In this table, the name of the R/3 instance is part of the primary key. Therefore, DB locks occur only in the area of NRIV_LOKAL which is assigned to the respective R/3 instance. Only processes from the same R/3 instance block each other. Keys of Database table NRIV-LOKAL: CLIENT MANDT INSTANZ NRINSTANZ (R/3 - instance) OBJECT NROBJ (e.g. MATBELEG) SUBOBJECT NRSOBJ (used at several objects) NRRANGENR NRNR (several intervals can be defined for the same object) TOYEAR NRYEAR (validity) Gaps appear always in the interval currently used by an instance. But these gaps are only temporary while re-naming of an instance can create permanent gaps. Note: This buffering technique is only useful if different R/3 instances are used. Numbers are not allocated in chronological order. Gaps can be reported. This buffering technique has been reworked. The Primary Key is extended by a field containing the ID of the work process on the R/3-instance. Using this buffering type, all locking problems with “local file buffering” disappear. See OSS note © SAP AG Parallel Processing

Number Range Buffering / Main Memory (3)
Allocate Number Database Server (NRIV) Allocate Number Main Memory of R/3-Instances Transmit Number Range Allocate Number Any locking problems can be almost completely avoided by allocating several numbers beforehand and storing them in the main memory. Furthermore, this reduces the access time considerably. Using this strategy, numbers can get lost by rolling back the creation of the object or by a shutdown of the application server. Using this buffering technique, the system takes an interval of predefined size into a buffer from which numbers are allocated. If the buffer is empty, the system fills the buffer again and increases the ‘current number’ in NRIV by the predefined size of the interval. Note: Numbers can get lost by rolling back the creation of the object or by a shutdown of the application server. Numbers are not allocated in chronological order. If you are bound by law to assure that numbers are allocated in chronological order and without gaps, do not use buffering of number ranges! parallel processing minimizes data base accesses numbers can get lost no reporting of gaps possible © SAP AG Parallel Processing

Maintaining the Number Allocation
Transaction SNRO 1000 for 2. Local File Main Memory 2 3 1 No buffering 100 for 3. To maintain buffering of number ranges, call transaction SNRO or Tools -> ABAP/4 Workbench -> Development -> Other Tools -> Number Ranges. Enter an object name and press ‚Edit‘. Choose Edit -> Set-up buffering -> No buffering/Main Memory/Local File. If you activate number range buffering, it is necessary to indicate the number of numbers in the buffer. If this number is too low, the buffer must be refilled to often which could cause performance problems. If this number is too high, too many numbers are wasted when restarting the R/3 instance. Please note that changes are overwritten as soon as the respective number range object is transported in the system (e.g. after correction releases) To watch the current status of number ranges choose transaction SNRO. If a number range is buffered, the ‚current number‘ is the next free number which has not yet been transferred to an application server (status in table NRIV). The ‚current number‘ is always greater than the last allocated number. To watch the current status of the buffers, call transaction SM56 on each instance. Choose GoTo -> Items. . The configuration affects the number allocation of this object type in general ! © SAP AG Parallel Processing

Legal Reasons might prohibit Number Range Buffering.
Attention ! Legal Reasons might prohibit Number Range Buffering. Legal problems for number range buffering usually affect FI objects. © SAP AG Parallel Processing

Number Range Objects for Retail Processes (1)
Article Document Number object type: MATBELEG Recommended: (3) Main Memory Billing Document Number object type: RV_BELEG Alternative: (2) Local File Note: Apply code changes of Note: (adding an “ignore buffer” flag) only for such documents where it is necessary © SAP AG Parallel Processing

Number Range Objects for Retail Processes (2)
Financial Accounting Document Number object type: RF_BELEG Recommended: (2) Local File If Possible: (3) Main Memory Legal reasons: (1) No Buffering Purchase Document Number object type: EINKBELEG Recommended: (3) Main Memory © SAP AG Parallel Processing

Deadlocks (1) Processing data in a non-sorted sequence can create deadlocks. Process 1 must wait for Release of the Lock by Process 2 DEADLOCK ! Process 2 must wait for Release of the Lock by Process 1 Database Table 1 9 2 10 Work Process 1 Work Process 2 3 11 4 12 4 1 8 12 3 16 7 11 2 16 9 10 4 5 3 13 5 13 Usually, a database can recognize a deadlock like this and solve the problem by rolling back one of the processes. But if the deadlock is caused by a more complex situation, there is no automatic solution. There is no problem, if a work process accesses a record that is already locked by itself. But if this access is performed by another work process (started e.g. by RFC) within the same transaction, the transaction blocks itself. 6 14 7 15 8 16 © SAP AG Parallel Processing

NO DEADLOCK Deadlocks (2)
Processing data in the same sorted sequence avoids deadlocks. All records are processed  COMMIT WORK NO DEADLOCK Process 2 must wait for Release of the lock by Process 1 The lock is released. Process 2 can continue Database Table 5 3 2 4 6 7 1 8 13 11 10 12 14 15 9 16 Work Process 1 Work Process 2 4 1 3 7 12 8 11 16 4 2 3 5 13 9 10 16 If the data is processed in the same sorted sequence (e.g. ascending primary key) it is still possible, that work processes 2 is blocked by a lock from work process 1. But in this case, all records that are locked by work process 2 so far, do not need to be accessed by work process 1. A deadlock is not possible. The sorted sequence must be kept not only for the records of a database table, but also for tables if several tables are updated. © SAP AG Parallel Processing

Higher requirements to the system
Using many processes in parallel makes higher demands on system components (CPU, memory, I/O system, network, …). Any bottleneck will prevent a further increase of the throughput. Eliminate this problem, as additional processes will not have any positive effects. Have a special look on the CPU load and the configuration of the I/O system on the database. Throughput No of Parallel processes optimal There is a point when using an additional process increases the throughput only marginally due to resource problems (CPU, Memory, I/O system, ENQ-Server, ...). Then you should not use more processes if you can not eliminate this bottleneck, because the throughput can flatten out. The optimal number of used processes can not be predicted in general. Considering only the CPU load, you can start with the configuration described below as a first approach. Then you should check if the usage of further processes increases the total throughput considerably ( increase the number until you find the optimum) or if a smaller number preserves (or even increases) the throughput ( reduce the number to take load from the system). You can use the appropriate monitor transactions (e.g. ST06) to get a hint about free resources or an overload (CPU, Memory, Locks, ...). The proposed starting configuration focuses mainly on the CPU load on the application servers. It is assumed, that there is a sufficient number of database CPUs to handle the load from these CPUs and that there is no other load on the system by other processes. You can monitor the system load with the operating system monitor ST06. If you are using a central system (i.e. one single machine for database and all instances) you should start with one application process per CPU. If your database is on a machine for its own and the used R/3 instances are running other machines, you can start with 1.5 application processes per CPU on each Application-Server. In many cases, the increase of throughput by parallelization is hindered by a bad configuration of the I/O system on the database. Running many processes in parallel leads to an occasional extreme high load on certain tables ( disks) (usually by updating data). Not optimized I/O systems will cause I/O-wait situations for many processes. © SAP AG Parallel Processing

Hints for the Design of your own programs (1)
General Recommendation: Design your program for parallel work even if it is not yet necessary - the day might come. A subsequent redesign takes considerably more time. Be careful with locks keep them as short as possible, especially for objects of central importance in the system (remember: you are not alone on the system) first perform the INSERTS - then the UPDATES (it is less probable that someone else needs access to a new record) think about a useful granularity for exclusive enqueue locks Use the same sorted sequences for the processing of data in the whole system to avoid deadlocks ask your colleagues, look at standard programs Pay attention to release system resources and refresh internal tables to delete old information. Keep the locking time as short as possible especially for central objects of the system. © SAP AG Parallel Processing

Hints for the Design of your own programs (2)
In the initial screen provide fields to configure parallel processing: definition of a Server Group, the maximum package size and maximum number of parallel processes switch on or off parallel processing Take care to balance workload collect (and sort?) the required data in order to define appropriate work packages first (attention: internal tables must not become too large) then start other processes and distribute the packages to them (just wait for a process to finish its work and pass the next item immediately) Use local update (“set update task local”) preserves benefit of short locking time on the database avoids communication overhead to database (tables VBMOD, VBDATA) end of process can be determined (important for follow-on processes) But: increases number of database processes modifying data The user should have the possibility to switch parallel processing on or off. This is very useful in order to perform a functional test or for a performance analysis of the transaction (or if the number of work items is too small). Give the user the possibility to configure the parallel processing, but think about useful default settings. All functions that are called “in update task” perform the operations modifying the database together at the end of the program. This keeps the time of database locks short. Using UPD processes for database updates is useful to reduce the wait time of an online user. As parallel work is usually used for the processing of mass data in background, this is not an important aspect. Here you should use the local update (“SET UPDATE TASK LOCAL”) which keeps the benefit of function modules called in update task, avoids the overhead to transfer data from DIA resp. BTC process to UPD via database tables VBMOD, VBDATA gives the possibility to detect the real end of the transaction (important for process chains). © SAP AG Parallel Processing

Structure of a report for parallel processing
Report Z_MY_PARALLEL_JOBS. .... Select * from table TABLE into INT_TABLE where .... Describe TABLE INT_TABLE lines line_no ..... DO tab_idx = tab_idx + 1. READ TABLE ITAB INDEX tab_idx.. *CALL FUNCTION SPBT_GET_CURR_RESOURCE_INFO CALL FUNCTION Z_MY_FUNCITON' DESTINATION IN GROUP 'A’ PERFORMING COME_BACK ON END OF TASK STARTING NEW TASK ‘ABC’ IMPORTING ... EXCEPTIONS ... NUM_PROC = NUM_PROC + 1. IF NUM_PROC >= MAX_NUM_PROC. WAIT UNTIL NUM_PROC < MAX_NUM_PROC. ENDIF. WHILE tab_idx <= line_no. (END OF PROGRAM) form COME_BACK using taskname NUM_PROC = NUM_PROC - 1. ... endform. Collecting data in internal table Read next record and start work processes activating a form after termination of work. If max. number of processes achieved, wait until end of a process is signaled. Loop until all records are processed. This is the rough structure for a program to distribute work items to several processes. Form signals end of a work process. © SAP AG Parallel Processing

Skeleton for an ABAP Report using parallelization (1)
* Required variables...... " max. Number of parallel processes PARAMETERS MAX_PROC_NUM type i. " Name of server-Group to be used PARAMETERS SERV_GROUP type rfcgr. ..... " number of processes currently started DATA STARTED type i value 0. " number of processes returned so far DATA RETURNED type i value 0. " actual limit for number of parallel processes DATA PROC_NUM_LIMIT type i. " Number of work Items in internal table DATA NUM_LINES type i. " current table index in internal table WORK_ITEMS DATA TAB_IDX type i. " Result of aRFC DATA RESULT like sy-subrc. " internal table for work items DATA WORK_ITEMS type ???? occurs 0. " Work Area for data of current work item DATA WA_PACKET type ????. " Variable for a unique name to identify a process and the processed " work item. Suggestion: use the table index TAB_IDX DATA TASKNAME(20). © SAP AG Parallel Processing

* Initialization IF MAX_PROC_NUM <= 1. * incorrect input; possible reactions: * 1st) detect and use the max. number of available work processes as limit * 2nd) display selection screen again * 3rd) exit program with error message ...... ENDIF. * fill the internal table WORK_ITEMS with the required data * e.g. using: SELECT * FROM .... into TABLE WORK_ITEMS WHERE... * Attention: this table must not be too large. Otherwise you should only * read the key information and process the work items in smaller packages * detect the size of the internal table WORK_ITEMS DESCRIBE TABLE WORK_ITEMS LINES NUM_LINES. IF NUM_LINES = 0. " no work EXIT PROGRAM. * initialize variables TAB_IDX = 1. CLEAR STARTED. CLEAR RETURNED. PROC_NUM_LIMIT = MAX_PROC_NUM. © SAP AG Parallel Processing

* Processing of the data in WORK_ITEMS in a loop WHILE TAB_IDX <= NUM_LINES. IF STARTED - RETURNED >= PROC_NUM_LIMIT. " max. number of processes is active => wait WAIT UNTIL STARTED - RETURNED < PROC_NUM_LIMIT. ENDIF. * Now we can start a new process. We try to use the max. number PROC_NUM_LIMIT = MAX_PROC_NUM. * read data from WORK_ITEMS into work area READ TABLE WORK_ITEMS INDEX TAB_IDX INTO WA_PACKET. * define a unique name for this process, you can use the table index TASKNAME = TAB_IDX. * Before Starting the aRFC call function for optimal usage of resources CALL FUNCTION ‘SPBT_GET_CURR_RESOURCE_INFO’… * Start the function as aRFC. At the end, the form ‘COME_BACK’ is activated CALL FUNCTION ’MY_PROCESSING_FUNCTION' STARTING NEW TASK TASKNAME DESTINATION IN GROUP SERV_GROUP PERFORMING COME_BACK ON END OF TASK EXPORTING TABLES EXCEPTIONS RESOURCE_FAILURE = 1 SYSTEM_FAILURE = 2 COMMUNICATION_FAILURE = 3 OTHERS = 4. RESULT = SY-SUBRC. Skipping the call of function SPBT_GET_CURR_RESOURCE_INFO can cause unexpected delay when distributing the wok items (see OSS note ) © SAP AG Parallel Processing

* Evaluation of sy-subrc CASE RESULT. WHEN 0. " We were successful => next item STARTED = STARTED + 1. TAB_IDX = TAB_IDX + 1. " IMPORTANT: Add trace messages to gain information for tuning WHEN 1. " Resource Problem; this must be only temporary => " Note in LOG-File and try to process the item later, " reduce the limit for the number of active processes temporarily " wait until the next process has finished and re-try then IF STARTED - RETURNED = 0. " there is no more active process => fatal error " there might be an error with the scheduling of jobs " exit program with error message (in LOG-File) ENDIF. PROC_NUM_LIMIT = STARTED - RETURNED. WHEN OTHERS. " fatal error (note in LOG-File); possible reactions: " 1st) exit program with error message " 2nd) use only the local R/3-instance " 3rd) sequential processing in this work process only ..... ENDCASE. ENDWHILE " TAB_IDX * Last work item is being processed now. Wait here until all items are processed (and maybe * write a Log-File). Otherwise the activation of COME_BACK does not find its calling process. WAIT UNTIL STARTED - RETURNED = 0. * All items are processed now => do what you have to do and leave program * END OF REPORT Important: Include possibilities for tracing, especially during test and development but also for tuning the throughput. You can use the progress indicator (not too often !!), note unexpected situations in a Log File or write a list with the results at the end of the report. © SAP AG Parallel Processing

Skeleton for an ABAP Report using parallelization (5) )
* Form COME_BACK * NAME identifies the returned process. The system provides it with the name that * was defined for the process in ...starting new task TASKNAME... FORM COME_BACK USING NAME. * increment RETURNED, as one of the processes has finished its work RETURNED = RETURNED + 1. * Read and evaluate result(if necessary) RECEIVE RESULTS FROM FUNCTION 'MY_PROCESSING_FUNCTION' IMPORTING ... TABLES ... EXCEPTIONS COMMUNICATION_FAILURE = 1 SYSTEM_FAILURE = 2 OTHERS = 3. .... ENDFORM. © SAP AG Parallel Processing

Useful transactions ST05 (Performance Trace)
Optimize the process concerning database operations, enqueues, duration of locks (examination in single user mode !) SM66 (system wide work process overview) Check if load distribution works as expected ST06 (OS Monitor) Watch the system load (CPU load and Memory usage) DB01 (database monitor) Look for exclusive database locks SM12 (Lock entries) Watch the entries of the ENQ Table RZ12 (RFC Server Group Maintenance) Define and configure RFC server groups © SAP AG Parallel Processing

Monitoring Transactions (sm66)
To monitor the processing, you can use transaction sm66 to get an overview to all running work processes in the system. © SAP AG Parallel Processing

Some function Modules SPBT_INITIALIZE SPBT_GET_PP_DESTINATION
Initialization and existence check of server group, determination of currently available resources. (optional) SPBT_GET_PP_DESTINATION Call this module immediately after CALL FUNCTION ... in order to get the name of the server, where the RFC is processed (optional). SPBT_DO_NOT_USE_SERVER Call this module in order to exclude a server from parallel processing (e.g. after an exception like “communication_error” in conjunction with SPBT_GET_PP_DESTINATION (optional). © SAP AG Parallel Processing

ABAP keywords STARTING NEW TASK ‚NAME‘ DESTINATION IN GROUP ‘GROUP’
Starts a new process with name ‘NAME’. If you have to distinguish between the aRFC (e.g. to read results), this name should be unique. DESTINATION IN GROUP ‘GROUP’ Starts the new process on an instance belonging to the aRFC server group ‘GROUP’ PERFORM ‚FORM‘ ON END OF TASK ‘FORM’ is called when the aRFC completes. You can read results form the aRFC with RECEIVE RESULTS WAIT Is used in order to suspend the program and wait for the completion of an aRFC. For further information, please look at the online documentation and SAP Help. © SAP AG Parallel Processing

Aspects for useful parallelization of a process (1)
Which are suitable split criteria (article, site, ...)? This must be considered from a business and a technical point of view. Child processes do not benefit from mutual buffer effects. Which locks are set (ENQ and DB)? How long are these locks kept? How important is the locked object for the system (central or only local meaning)? How can you avoid a parallel processing of work items that compete for the same locking objects (if existing)? Is a previous analysis possible? Which other processes use the same locking objects, i.e. which processes can not run in parallel to mine? Is a useful granularity for ENQ locks used (load on ENQ-Server  parallelization)? © SAP AG Parallel Processing

Aspects for useful parallelization of a process (2)
Which is a useful package size? Too small ( ALE overhead) Too big ( workload balancing, data transfer, memory requirements) Add trace messages to distributor process (e.g. on size of IDOC, used application server, required time, etc.). This provides additional information that can help to find an optimal configuration and to detect problems. What is the ratio between ABAP and database time? Gives you a hint where the first bottleneck can be expected. Aspects for system administration and tuning: Which tables are modified (I/O-Tuning of the DB can be necessary)? A sufficient number of dialog work processes on the R/3 instances is required (for RFCs, administration and other purposes). © SAP AG Parallel Processing

Some Interesting OSS notes
(number range buffering on work process level) 74141 (description of resource management for server groups) 99284 (load balancing with aRFC server groups) (load balancing with aRFC server groups) (load balancing with aRFC server groups) (error with server group ‘default’) (problem with ALE load distribution) (better load balancing during IDOC processing) (reports to test aRFC server groups) (template for a report with a mutual lock avoiding distribution) © SAP AG Parallel Processing

Parallel Processing © SAP AG Parallel Processing.

Similar presentations

Presentation on theme: "Parallel Processing © SAP AG Parallel Processing."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Parallel Processing © SAP AG Parallel Processing.

Similar presentations

Presentation on theme: "Parallel Processing © SAP AG Parallel Processing."— Presentation transcript:

Similar presentations

About project

Feedback