During parallel processing (CALL FUNCTION DESTINATION IN GROUP ... ) more work processes than required are occupied.
In the ALE/WF area, tRFC calls are made which then call several tRFCs. As a result, an exponential growth of the tRFC can occur, which can cripple an application server.
As of SAP Release 3.0F, the available resources of an application server are determined. This information is used by the following RFC types:
- For the parallel RFC (language element ... STARTING NEW TASK
TASKNAME DESTINATION IN GROUP <group>, this information is
evaluated by the receiver. The number of aRFCs sent to the application
server depends on its resources. An application server without resources
is not sent any RFCs. The resources are checked until all RFCs are
processed.
- For the tRFC, this information is evaluated by the sender. If no
resources are available, synchronous RFCs are sent instead of
asynchronous RFCs for internal management of the tRFCs. These functions
are made available in SAP Release 3.0F to 3.1H by Note 95633 and by
applying the 3.1H kernel.
- In the case of the aRFC, this information is evaluated by the receiver as of Release 4.0. If no resources are available, execution of the function module is delayed internally. For more information, also see the online documentation for the asynchronous RFC.
- The number of available resources in the system is a snapshot
that relates to the current load status of the system. In this
situation, no program can assume that these resources are also available
over a long period of time.
- If one of the quota is exceeded, no resources are returned to the caller.
- The determined resources are not reserved for the caller.
Therefore, competing programs may determine resources at the same time
and use more dialog work processes than set in the quota regulation. A
program therefore cannot assume that the determined resources can
actually be used.
- You can use the program RSARFCLD (available as of database Release 4.0) to configure the quotas dynamically.
- You can use the function module TH_ARFC_REQUESTS to determine the current resources on an application server for test purposes.
- The standard values for the quotas are set restrictively since
it is likely that dialog users are also using the system and are treated
preferentially. To receive maximum resources (for batch processes
also), set the quotas with the following values:
rdisp/rfc_max_login = 100
rdisp/rfc_max_own_login = 100
rdisp/rfc_max_own_used_wp = 100
rdisp/rfc_max_comm_entries = 100
This can of course affect the response time of the dialog users!
- According to the recommendation of the RFC, the number of configured dialog work processes should be bigger than the total of non-dialog work processes (update, batch spool and so on).
Technical description of the configurable profile parameters
=============================================================
- rdisp/rfc_use_quotas
Switch to activate or deactivate the resource determination. Default = 1, activated
Valid values : 0 / 1
You should NEVER change the default value. If the parameter has the value 0, then you can no longer work with the parallel RFC because no server can be determined for the next RFC. If the value is changed to 0, the exception condition RESOURCE_FAILURE is always displayed when calling the asynchronous RFC.
- rdisp/rfc_max_queue
Quota for the full utilization of the dispatcher request queue. When the number of pending requests exceeds this quota, no resources are returned to the caller.
Default: 5 (percent)
Valid values : 0 - 100
The size of the dispatcher request queue is set by the profile parameter rdisp/elem_per_queue.
- rdisp/rfc_max_login
Quota for logons to the application server. When the total number of logons exceeds this quota, no further resources are returned to the caller.
Default: 90 (percent)
Valid values : 0 - 100
The maximum number of logons is set by the profile parameter rdisp/tm_max_no.
- rdisp/rfc_max_own_login
Quota for the number of own logons to the application server. When the number of own log-ons exceeds this quota, no further resources are returned to the caller.
Important: This parameter applies only if the check is executed locally. If the check is exected on a remote server, the parameter is ignored and the next more restrictive quota applies.
Default: 25 (percent)
Valid values : 0 - 100
The number of logons is set by the profile parameter rdisp/tm_max_no.
- rdisp/rfc_max_comm_entries
Quota for the number of communication entries used. If the number of entries used exceeds this quota, no resources are
returned to the caller.
Default: 90 (percent)
Valid values : 0 - 100
The number of communication entries is set by the profile parameter rdisp/max_comm_entries.
- rdisp/rfc_max_own_used_wp
Quota for the number of dialog work processes used by the user. If the number of work processes exceeds this quota, no resources are returned to the caller.
Important: This parameter applies only if the check is executed locally. If the check is exected on a remote server, the
parameter is ignored and the next more restrictive quota applies.
The USER NAME is not checked! This means that if a user logs on with the same name several times (that is, is displayed in transaction SM04 several times), each such entry is basically regarded as an individual user even if the user name is the same.
Default: 75 (percent)
Valid values : 0 - 100
The number of dialog work processes is set by the profile parameter rdisp/wp_no_dia.
- rdisp/rfc_min_wait_dia_wp
Quota for the number of dialog work processes that should be kept free for users. When no more dialog work processes are free, no resources are returned to the caller.
Default: 1
Valid values : 1 - (total dialog work processes)
The number of dialog work processes is set by the profile parameter rdisp/wp_no_dia.
If enough dialog work process are configured, you must increase this value.
The dispatcher controls the transfer of RFC requests. The RFC request is transferred to a dialog work process only if the defined number of free dialog work processes is guaranteed. Otherwise, the request is stored in the dispatcher queue for subsequent processing.
You must make sure that the value of the parameter rdisp/rfc_min_wait_dia_wp is always smaller than rdisp/wp_no_dia. Otherwise, no RFC requests can be processed.
- rdisp/rfc_max_wait_time
Maximum number in seconds that a work process is asleep if it does not receive any resources. In some cases, the work process is asleep for a very long time, although resources are available in the meantime. This parameter is available only as of a certain patch level. Waiting time in seconds is set by the profile parameter rdisp/rfc_max_wait_time.
- rdisp/rfc_check
This parameter controls the check as to whether sufficient dialog work processes are free for processing asynchronous RFC calls.
The number of available dialog work processes depends on the number of free dialog work processes and the number of work processes to be kept free for dialog application. (see rdisp/rfc_min_wait_dia_wp)
If no free work process is currently available, the request is put into a queue and processed at a later time.
The check can be set to various levels:
Level 0: no check
Level 1: start of all asynchronous RFCs is monitored
With 4.6D kernel patch level 1473 and 6.20 kernel patch level 711 respectively, the following values were added:
Level 2: In addition to level 1, all RFCs that were started from asynchronous RFC sessions are monitored. This also includes synchronous RFCs. To allow applications with a lot of RFC calls to run on this level, you may have to increase the number of dialog processes that can be used for RFC.
If, in Release 4.6, rdisp/rfc_check is unknown in parameter maintenance, you can change it dynamically using the function module TH_CHANGE_PARAMETER:
- Specify parameter name rdisp/rfc_check as parameter.
- Enter the parameter value.
- Enter the value 0 for CHECK_PARAMETER.
- Execute the function module so that the value is changed when the system is running.
A correction is in process so that the parameter rdisp/rfc_check can also be changed using transaction RZ11 in 4.6 Releases.
In Release 6.20, you can change the parameter dynamically using transaction RZ11. The following applies to both releases: Due to a problem in parameter maintenance, only values of 1 or higher (default) are allowed!
All known errors have been corrected in the following corrections:
31I: patch level 368, load check, number of resources > max resources (for AS/400, first provided with patch level 423)
40B: patch level 488, load check, number of resources > max resources
45B: patch level 196, load check, number of resources > max resources
46D: Patch level 1473, CST Patch Collection 13 2003
620 : Patch level 711, CST Patch Collection 13 2003
For example:
You assume an application server is configured with work processes as follows:
rdisp/wp_no_btc 4
rdisp/wp_no_spo 2
rdisp/wp_no_vb 4
rdisp/wp_no_vb2 2
rdisp/wp_no_dia 12
The rule should ensure that the number of dialog processes is greater than the number of NON dialog processes (BTC,SPO,UPD,UP2). In this case, the rdisp/rfc* parameters should have the following default values:
rdisp/rfc_use_quotas 1
rdisp/rfc_check 1 (see above)
rdisp/rfc_max_comm_entries 90
rdisp/rfc_max_login 90
rdisp/rfc_max_own_login 25
rdisp/rfc_max_own_used_wp 75
rdisp/rfc_max_queue 5
rdisp/rfc_max_wait_time 10
rdisp/rfc_min_wait_dia_wp 4
Documentation
Detailed documentation on the configuration of system resources for parallel RFC, tRFC and qRFC is available in the help portal at
http://help.sap.com
under SAP NetWeaver. Select the release and language.
The documentation for Web AS 6.40 (SAP NetWeaver '04) is available under
SAP NetWeaver
-> SAP NetWeaver Configuration
-> SAP Web Application Server
-> SAP Web Application Server ABAP
-> Configuring System Resources for Parallel RFC, tRFC,qRFC
No comments:
Post a Comment