High numbers of dia-requests in dispatches queue for seconds

[Former Member]

Hi everyone

i have the symptom on our application servers (8 appl-servers), that for some seconds the numbers of dia-requests are going up to 400 and goes down in the next 30 seconds. but the most dia-workprocesses (>80%) are free. we have 60 dia-wp per appl-server and have not a performance issue at the moment. this behaevour, i recognize on all instance during different times.

why go the request in the queue and not directly to the free dialog-workprocesses? there an posibility to see, what or who create /had created the request?

we run crm 7.0 ehp3 on the netweaver 7.4 with many users on the system.

thanks for any technical description for this behaevour.

regards

Thomas

[yakcinar]

Hello Thomas,

You can schedule daily monitoring tool /N/SDF/MON on your system and can see the details of all # of busy wps, # of dia wp queues, etc like the one in below picture. This statistics are given by each instance. By double clicking a row you can see the SM50 screenshot of the wps.

You can see detailed info about the transaction in below Marius Burger's link How To Run /SDF/MON To Collect Snap-Shot

And also http://www.sap-perf.ca/run-sap-sdfmon/

This could give you a hint about running processes.

For load distribution you need to check the programs ability to work in parallel.

Each task (dialog, rfc, http etc) has different behaviours about distributing the load and occupying the wps.

Regards,

Yuksel AKCINAR

[Former Member]

Hi Yüksel

thank you for the hint about TA and Report /SDF/MON. I Forget to write, that i use this report previously.

I run the Report again and made two interessting screenshots. First i see high number ob dia-request in different instances:

So, it is not a instance-specific issue. in different instances, i have peaks in the dia-Queue.

Second, i capture a situation with a very high numbers of dia-request on a specific instance:

In both situations, the instances have much wp's in Status free and are not in use. In the most situations, we have less than 10 wp's per instance in use and over 50 DIA-WP's free.

Did you have any technical Explanation for this behaeviour?

My guess is, that all cpu's are in use for working request, but i dont see much cpu-load. We have 8 CPU's per instance.

Another guess is, that the dispatcher himself are limited in the performance.

Any possibility to find out, which process/applikation/user are generate the dia-requests? also i dont see any load initiated by qrfc or somewhat else.

Regards

Thomas

[yakcinar]

Hello Thomas,

Can you double click one of the lines you mentioned so we can see the SM50 screen at that time?

Also can there be RFC profile parameters that has restrictions.

Is there any sign of this queue in dev_disp?

Can you send screenshots in English, please?

Regards,

Yuksel AKCINAR

[Former Member]

Hi Yüskel

here the two printscreens from the application at 11:10:10 (dia-queue on 612)

Only 2 dia-wp are running. And the queue-overview:

My rfc-gateway parameters are:

gw/listen_queue_len --> 512

gw/max_conn --> 2000

gw/max_conn_per_dest --> 10

gw/max_ni_queue_len --> 128

gw/max_overflow_size --> 25000000

gw/max_overflow_usage --> 50

gw/max_shm_req --> 400

gw/max_sleep --> 20

gw/max_sockets --> 3500

gw/max_sys --> 2000

In the dev_disp, i dont find any messages about problems in the dispatcher. I have a message at 8:35 and the next at 10:48 about a connect reset py peer.

and also the printscreens in english:

and the second:

I have analyze the records in TA STAD between 11:09 and 11:12 from the one instance. Here the result:

The only one peak is from a long running rfc (23sec), All other data looks fine for me. I have many request per second (right y-scale) and no performance-peaks during the minutes.

I have an increase in dia-queue of ~250/500 requests per 10 seconds (11:09:40-11:10:00) and a decrease of ~200 requests per 10 seconds (11:10:00-11:10:50). This performance of 20 request/second you can see in the chart above. Could it be a perfomance limit of the dispatcher?

Thank you for your assistance.

Regards

Thomas

[yakcinar]

Hello Thomas,

I am not sure whether there is a limit for dispatcher queue.

There is rdisp/elem_per_queue parameter given the description below.  

What about wait times at that time?

Is it also so high?

Can you check ST03N DIAlog tasks response times at that time?

Parameter

rdisp/elem_per_queue

Short text

Number of Requests per Work Process Type

Parameter Description

Parameter to determine the size of the internal request queue. The value of this parameter is multiplied by the number of possible process type (DIA, BTC, and so on). Currently there are 7 possible types (including the outbound queue for SAP GUI output in the Dispatcher). That means, that there is a maximum queue size of maximum 14000 savable requests for the standard value 2000.

Application Area

Dispatcher

Parameter Unit

Integer

Default Value

2000

Who is permitted to make changes?

Customer

Operating System Restrictions

None

Database System Restrictions

None

Values allowed

Whole Number > 0

Regards,

Yuksel AKCINAR

[isaias_freitas]

Hello Thomas,

Whenever a request is created, it first goes to the Dispatcher.

Then, the Dispatcher assigns it to a free work process if the request is ready to be processed (maybe the request is waiting for something else).

Does the burst of DIA requests occur around the same time of the day?

Can you identify any job (transaction SM37) that is being executed at the time the burst of DIA requests is created? Many jobs use RFC calls (that would require dialog WPs) in order to perform tasks in parallel.

The /SDF/MON might not capture the relevant information in this case, since you inform this is occurring in a very short period.

Maybe you could create the script mentioned at the SAP note 675778 and adjust the loop interval to 1 second ("sleep 1" instead of "sleep 30"). This could create a huge file, though. So, it would be good to start the script just before the time you expect the burst to occur.

Regards,

Isaías