Question:
I have an app server which gets overwhelemd by
RFC's, I know with smlg thresholds I can control logon load.
Is there a way to control RFC's (not RZ12) but certain setting some thresholds on RFC's (like setting a threshold in SMLG).
Answer:
Have a look at this:
http://help.sap.com/saphelp_nw2004s/helpdata/en/ff/70a7f0b25d8e4b96a3899c886466fb/frameset.htm
Important parameter: rdisp/rfc_max_own_used_wp
http://help.sap.com/saphelp_nw2004s/helpdata/en/ff/70a7f0b25d8e4b96a3899c886466fb/frameset.htm
Answer:
snmsee
How do you control the RFC usage on your servers,
In your environment how to keep RFC's from over loading an app server.
what parameters and values do you set.
Answer:
Do look at the format, it's cut&pasted from MS-Word: (thanks to nlsme3)
I don't have a fix set of values. It depends on the system characteristics, however our procedure is as follows:
rdisp/rfc_check
The parameter can be set to a whole number between 0 and 3. The number specifies the level of the resource check. The values mean the following:
Level 0: No check is run
Level 1: Monitors the start of all asynchronous RFCs
Level 2: Monitors, additionally to level 1, all RFCs started anew from asynchronous RFC sessions. This includes synchronous RFCs.So that applications that transmit a lot of RFCs can run at this level, the number of dialog processes used for RFCs may have to be increased. (rdisp/rfc_min_wait_dia_wp may have to be reduced).
Level 3: monitors all RFCs (synchronous and asynchronous).
By default this parameter is set to 1. Values 2 and 3 are new values since kernel 46D patchlevel 1473. Value 2 is specifically important when an RFC call starts new RFC calls itself. Only the first call is taken into account when rdisp/rfc_check is set to 1. To keep an eye on the total number of parallel RFC calls, this parameter needs to be set to 2. On 4.6C systems, this requires a restart. In WebAS 6.10 and higher, this can be changed dynamically via RZ11.
rdisp/rfc_use_quotas
This parameter is used to activate the use of quotas for resource allocation. If the parameter is set to 0, all other rdisp/rfc*parameter settings are irrelevant. In this situation, you cannot use parallel RFCs. The system acts as if all resources were in use and always returns the same corresponding return value.
Keep this parameter set to the default 1. There is no reason to de-activate the quotas for resource allocation.
rdisp/rfc_max_wait_time
This parameter determines the maximum period of time in seconds that the system waits after a load check. The wait time is calculated based on the amount of available resources. The fewer resources that are available, the longer the wait time.
You can increase the wait time if you suspect that a resource bottleneck is about to occur, and if you cannot resolve the bottleneck and are prepared to accept a longer wait time.
By default this parameter is set to 15 seconds. This means that when it shows that currently there are no free RFC resources, the system will wait 15 seconds before the next check for resources. When the RFC resources are set really low (only a couple of DIA processes can be used for RFC in parallel), it might make sense to increase this parameter. If internal memory does allow an increase in the number of work processes, this might be a better solution.
rdisp/rfc_max_queue
This parameter specifies the contingent for the maximum number of outstanding requests in the dialog queue. RFC is executed on the target server in a dialog work process. Therefore, if there is currently no free dialog work process, the request is placed in the dialog queue of the dispatcher. You should ensure that the queue never becomes full.
This parameter is a percentage of the parameter rdisp/elem_per_queue (maximum number of outstanding request together for RFC as well as DIA). The default is set to 5%. You should keep this value quite small, as the dialog requests are also kept in this queue, and it is important that the queue does not become full. In case this 5% becomes full with RFC requests, it might be better to increase the parameter rdisp/elem_per_queue instead of increasing the percentage.
rdisp/rfc_min_wait_dia_wp
This parameter is used to reserve a number of dialog work processes for dialog mode. It specifies the number of dialog work processes that should be kept free for dialog mode, thereby preventing that all processes are occupied by parallel RFCs. The parameter rdisp/wp_no_dia specifies the absolute number of dialog work processes. The dispatcher controls the forwarding of RFC requests. The RFC request is only passed to a dialog work process if the defined number of free dialog work processes is guaranteed. If it is not, the request is kept in the dispatcher queue for processing later.
This parameter is the most powerful one to prevent the system from being overloaded with RFC requests. For example in a system with 50 DIA processes, this parameter can be set to 30. These 30 processes will then be kept available for endusers. The remaining 20 processes can be used by parallel RFC calls. Ofcourse these 20 DIA processes can also be used by endusers when they are not used in use by RFC requests.
Important note: this parameter is closely related to rdisp/rfc_check. As explained above, rdisp/rfc_check should keep en eye on all requests coming in via RFC. The rdisp/rfc_check must therefore be set to 2. Otherwise the following can happen. In parallel 20 RFC calls are executed towards the system. When these RFC calls themselves initiate other requests, these newly created requests are not being constrained in the 20 DIA processes available. These new DIA requests can start to consume DIA processes from the 30 kept free for endusers. In this case, the system can still be overloaded by RFC calls.
Therefore it only makes sense to set rdisp/rfc_min_wait_dia_wp, when rdisp/rfc_check is set to 2.
rdisp/rfc_max_own_used_wp
This parameter determines the contingent of dialog work processes that an RFC user may occupy simultaneously. The value is specified as a percentage of the configured dialog work processes. You can use this parameter to prevent a user (or an application that is sending RFCs) from occupying all the dialog work processes on the target server.
This parameter sounds promissing. If it is possible to grant a maximum number of DIA processes to a particular user, it would be possible to limit the number of parallel processes coming from the external system (for example a maximum of 10 DIA processes for user ALEREMOTE, 5 for RFCUSER, etc).
However, unfortunately it doesn’t work like this. This is because the user name is not checked. This means, if one user logs on several times with the same name (name appears several times in SM04), each of these entries is valid as an individual user.
This parameter is a percentage of (rdisp/wp_no_dia - rdisp/rfc_min_wait_dia_wp). Default value is 75%. In our example of max 20 DIA processes available for RFC calls, one incoming ALEREMOTE user can consume 15 DIA processes. This can be the case when the first RFC call is kicking off new requests in DIA processes. However, the next incoming ALEREMOTE user can also consume 15 DIA processes again (at this point in time only 5 DIA processes will be available for this second user ofcourse).
If it shows that one RFC application is basically consuming most of the DIA processes for RFC for most of the time (when this particular RFC application is starting new requests in DIA processes from the first RFC call done), this parameter can be lowered in percentage. If for example the parameter is set to 10%, only 2 DIA processes can be used by one RFC user logon. The other 187 remaining can then be used by other applications (including the same application that is using the 2 DIA processes already, only when a new logon is set up).
rdisp/rfc_max_login
This parameter describes the contingent for the number of RFC users logged on to the SAP system. The parameter rdisp/tm_max_no specifies the absolute number of logons to the SAP system. This parameter therefore describes the percentage of possible logons which, once exceeded, causes any further RFC logons to the server to be rejected.
This parameter is a percentage of parameter rdisp/tm_max_no (total number of users being able to logon to a single appserver). Default value is 90%. On MC production systems rdisp/tm_max_no is set to 2000. This means that when the number of normal endusers logged on to a specific appserver exceeds 200 (10% of 2000), it might make sense to lower the value for rdisp/rfc_max_login.
However, having 2000 users actually logged on to one appserver, requires a huge system (CPU/memory). In real life, the appservers are not really sized for 2000 users. Therefore this parameter is not really useful.
rdisp/rfc_max_own_login
With this parameter you can set the cut-off value for the number of own logons in the SAP system. It is different from the parameter rdisp/rfc_max_login in that in this case, it is the logons of one user only that may not exceed the quota. This value is, therefore, a percentage of rdisp/tm_max_no. It restricts the logons of an (RFC) user and thus prevents a program from sending RFCs to such a degree that other (RFC) users cannot log on to that server.
The default value is 25% (of rdisp/tm_max_no), which results in 500 possible logons for one particular RFC user. This number is way too high to actually host on one appserver, so this is not a really useful parameter (not even when we lower the 25%). More restrictive parameter must be used like rdisp/rfc_min_wait_dia_wp.
This parameter is valid only if the check is run locally. If the check is carried out on a remote server, the parameter is ignored and the next more restrictive quota takes effect.
This parameter is not taken into account by RFC calls coming from remote systems. So only when the RFC client is the RFC server itself, the use of this paramater might make sense. Most of the RFC requests however will come from remote systems.
Useful OSS notes are:
74141 Resource Management for tRFC and aRFC
101977 POI: Performance download/TRFC problems
142419 RFC load distribution via Quota settings
400330 Outbound Scheduler/qOUT Scheduler
549981 Determining system resources for parallel RFCs
593058 New RFC load balancing procedure
http://help.sap.com/saphelp_erp2005/helpdata/en/fd/1d75a8f34308449ef6c4cdcda4e137/frameset.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/6e/3f560a3e0f6f4a90fb1e7db1388d4d/frameset.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/14/96623c2d6a1e66e10000000a11402f/frameset.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/0c/275c3c60065627e10000000a114084/frameset.htm
http://help.sap.com/saphelp_erp2005/helpdata/en/43/7f952741f7464589f055bf44888696/frameset.htm
Answer:
That was a very nice posting, snmsee. May I copy-and-paste it elsewhere, giving you credit, of course?
Answer:
There is one change I want to make in the below. To really make sure all RFC calls stay within the assigned number of DIA processes, set rdisp/rfc_check to 3 instead of 2.
snmsee, you have used an older version of the document
Answer:
That was a very nice posting, snmsee. May I copy-and-paste it elsewhere, giving you credit, of course?
Of course Tinuviel, but creadits should go to nlsmse3
snmsee, you have used an older version of the document
yes, a proven document
Answer:
that really was a fine one, snmsee
your permission to use it as a documentation and pass it around?
_________________
rgds
fish
Answer:
Once generally published, it's public. Isn't it.