on 03-15-2010 11:50 PM
We have had a job running for a decent period of time and to date before this issue it was running fine. The job is call SD_BILL_DOC_##_##_## where ## is the time it runs, this background job then fires off parallel dialog jobs called SAPLEDI7 but it now seems to be firing off too many and using all the dialog processes which in turn stops anyone else using the system while this job is running.
The slowdowns appear to have started last Thursday.
The SAP Buffers all appear fine.
Each u201CSAPLEDI7u201D seems to take a sort period of time
All SQL tables that can be traced for this process have a fragmentation of less than 2%
CPU is not spiking.
There were transports last week but these donu2019t seem to touch the tables involved with this processes.
The rest of the system seems to be running fine.
Any ideas how to throttle the amount of dialog processes a background can use when reading/ processing idocs?
Hello,
The job is firing off parallel processes via asynchronous RFC calls. You can control the number of DIA processes taken up in this way by setting the RFC quota:
- Transaction RZ12
- Double-click on any entry that refers to an instance of your system; in a multi-instance system you have to assign quota to all instances
The important quota are:
1) Max. Number of WPs Used (%): this is the percentage of DIA processes that can be used simultaneously for parallel processing.
2) Minimum Number of Free WPs: minimum number of DIA processes that must be kept free for other uses
Don't forget to save the changes you make.
Example: if yor instance has 20 DIA processes and you set Max. Number of WPs Used (%) =60 and Minimum Number of Free WPs = 5, then at most 12 DIA processes (60% of 20) can be used for parallel async RFC, unless so many DIA processes are already busy that the number of free processes would fall below 5.
Hope this helps,
Mark
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Cheers, tried RZ12 thinking it would work but didn't slove the issue.
In the end we found that the part of this job was to create a idoc and the idoc was set process stright away. This would be call but another process has been paused and the directory the profile port was sending the idoc to had over 350K files in it,opps. Clean up the directory and problem sloved.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.