on 06-12-2014 7:31 AM
Dear team,
(Not sure if I have opened this message at correct place)
We have A program (forecasting that is related to Production planning). It runs country wise.
We have it running for Country XYZ where there are many plants; the job runs without any glitch to system.
Same program runs for another country at different time. (with different variant). Problem arises here..... All the dialog work process gets clogged with the Sequential read of table swequeue. Also Internal RFC destinations (those pointing towards Application server of ECC and 'NONE') get occupied in SM58.
When this job runs; It is impossible to login to system or even put another tcode. (simply system has no free dialog work process).
What could be reason ? in sm58 I see that all transaction are either running or recorded or error like Comm. table full (that is cause gateway comm. limit)
All I see in SM58 is the Function module IDOCs_OUTPUT_VIA_XML_HTTP is running in parallel.
Please help.
Regards,
Arthur
Hello
You could use instance parameter rdisp/rfc_use_quotas to enforce the RFC quotas and use parameter rdisp/rfc_min_wait_dia_wp to avoid having all dialog workprocess being used by RFC.
74141 - Resource Management for tRFC and aRFC
527481 - tRFC or qRFC calls are not processed
Check also parameters rdisp/max_comm_entries, rdisp/max_arq and rdisp/appc_ca_blk_no that sets the size of communication buffers.
Check also the RFC group definition in transaction RZ12
Regards
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Maybe you do not have other programs that use that much of parallelism...
By default parallel groups defined in RZ12 should include some quota rules to avoid saturating the dialog process...
Have a look at parameter rdisp/rfc_check, I had to set it from default 1 to 2 in a similar scenario.
With the default value (1) only asynchronous RFC calls are restricted, with (2) the quotas are also applied for synchronous RFC calls.
Regard
https://help.sap.com/saphelp_nw70/helpdata/en/76/992c1f8731514c8467e77f115796c7/content.htm
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).
Increase the value if you notice that your application server becomes flooded with RFCs and dialog mode is no longer possible, even though you have set rdisp/rfc_min_wait_dia_wp.
Hi,
Is the program causing this issue a custom "Z-program" or standard SAP? If it is custom, you need to go back to the developer and ask/tell them to sort out their parallel logic. If it is standard SAP I'd be digging around OSS and potentially raising a call.
I would bet some money that this is a custom program...
Cheers,
G.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes it is man....But you see, it runs at 7 pm with variant which has more selection. it runs very much properly; But same job runs at 9:30 pm and causes serial access to table SWEQUEUE
This is quite issue. Today also when some user ran one job that was irrelevant to this job; same thing happened. All of a sudden the processes are hitting the table swequeue and system goes slow as dialog work processes are consumed.
User | Count |
---|---|
80 | |
24 | |
12 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.