Monitoring the Dispatcher Queue

Dispatcher statistics

Occasionally, it may be useful to analyze the work process dispatcher queue. Statistics on dispatcher activities are available via the server overview at the following path:

TOOLS • ADMINISTRATION • MONITOR • SYSTEM MONITORING • SERVER (Transaction SM51)

Then, mark an SAP instance with the cursor and select Go To • SERVER • INFORMATION • QUEUE INFO.

A list appears, showing information for each work process type on the requests currently waiting, the maximum number of user requests since the SAP instance was started, the maximum possible number of user requests for each queue, and the number of requests read and written.

The information about the dispatcher queue is especially important when the system is not responding because the number of requests in the queue is much larger than the number of work processes. In this situation, the SAP system does not have any more work processes available to perform an analysis. To obtain the queue data, call the auxiliary program dpmon (option P).

Monitoring work processes

You can monitor the actions of SAP work processes by using the TIME, STATUS, REASON, ACTION/REASON FOR WAITING, and TABLE fields in the work process overview. Note the following points:

->Are there sufficient idle (status: WAITING) work processes of each type on each SAP instance?
->Are there programs that use a work process for too long (TIME field)?
    If so, the user should check this program and see if it has any errors.
    A detailed program analysis may also be necessary.
-> Check the STATUS, REASON, ACTION/REASON FOR WAITING and TABLE fields to see whether more than 20% of the work processes are performing the same action. The main problems with this can be one of the following:

 ~If more than 20% of the work processes are in PRIV mode or in the roll-in or roll-out phase, this indicates a problem with SAP memory management.
 ~If more than 40% of work processes are performing a database action, such as SEQUENTIAL READ, COMMIT, etc., this indicates a database problem.
 ~If more than 20% of work processes are reading the same table at the same time, there may be a problem with an expensive SQL statement or exclusive lock waits in the database.

You can call the work process overview at the operating system level with the d pmon program. This is particularly necessary if the performance problem is so massive that no work processes can be used for the analysis.

Procedure Road map for Analyzing SAP Work Processes:

SAP Work Process Overview (Transaction Code SMSO/SM66)

  ? Work Processes with StatusRunning?

      ? Corresponding Actions: Direct Read, Sequential Read, Insert, Update, Delete, Commit

          0 Database Lock Monitor (Transaction Code DB01)

              ? ExclusiveLock Waits?

                 Analyze the Process Holding the Lock.

          0 Database Process Monitor (Transaction ST04, Function Oracle Session)

              Analyze Expensive SOL Statements.

          0 SOL Trace (Transaction Code ST05)

              Analyze Expensive SOL Statements.

   ?Corresponding Actions: Load Report, or semaphore1 ?

        Analyze SAP Program Buffer - Buffer Too Small?

    ? Corresponding Action:Roll-in, Roll-out, or semaphore6?

       Analyze SAP Memory Management- Extended Memory or Roll Buffer Too Small?

   ? Work Processes with Status Stopped? 

       ?Corresponding Reason: PRIV.

          Analyze SAP Memory Management- Extended Memory or Roll Buffer Too Small?

        ? Corresponding Reason: CPIC?

            RFC Destinations(Transaction SM59, Test RFC Destination Function)

            Check for Unavailable or Slow RFC Destinations.

            Work Process Overview(Transaction Code SM50/SM66) in Target System

            Check for Bottlenecks, e. g., Due to All Work Processes in The Target System Being Occupied.

   ? Work Processes with Status Complete?

           Save the Work Process Trace File for Analysis, and Restart the Work Process.