You can use the Entire System monitor to obtain a complete overview of the status of an SAP system. Many of the subtrees of this monitor are also contained in the specialized monitors in the CCMS Monitor Templates monitor set:
Subtree | Specialized Monitor |
Spool | Spool System |
Background | Background Processing |
Gateway_Summary | Communications |
Buffers | Buffers |
Database | Database |
Security | Security |
Server Configuration | System Configuration |
OperatingSystem | Operating System |
Features
Dialog Subtree
Like the Dialog Overview monitor, this subtree contains attributes for the SAP dialog system. However, you can find a significantly more detailed breakdown of the response time and additional attributes for this topic here.
The following table provides information about the monitoring tree elements (MTEs) of this subtree:
MTE Name | Description |
ResponseTime | Corresponds to Dialog Response Time of the Dialog Overview |
FrontendResponseTime | Total of ResponseTime, FrontendNetTime and GuiCallBackTime, and therefore the average time that the user waits at the front end for his or her request to be processed |
QueueTime | Average wait time in the dispatcher queue (with a normal workload, there are always free dialog work processes available; the wait time is then only a few milliseconds) |
Load+GenTime | Average load and generation time for source code, graphical user interfaces, and screen information from the database |
DBRequestTime | Average time for processing logical database requests (calls to the SAP database interface) |
Utilization | Average utilization of the dialog work processes of an application server |
PrivMode Utilization | Percentage of dialog work processes in PRIV mode |
ErrorsInWpDIA | Number of errors in dialog work processes since the monitoring segment was created (that is, since the application server was started) |
ErrorFreqInWpDIA | Number of errors in dialog work processes per minute |
EndedWpDIA | Number of dialog work processes terminated after an error; you can use the process overview (transaction SM50) to determine whether a work process should be restarted after an error |
NumberOfWPDia | Number of dialog work processes; for recommendations about the appropriate number, see SAP Note 39412 |
QueueLength | Average utilization of the dispatcher wait queue; with a normal workload, this value is around 0% (see QueueTime) |
LongRunners | Long-running dialog work processes; allows you to monitor long-running processes below the defined limit for the maximum duration of a process step (profile parameter rdisp/max_wprun_time) |
ProgramErrors | ABAP program terminations in dialog work processes (transaction ST22 is set as the analysis method, with which you can check the cause of the program error) |
DialogSteps | Average number of dialog steps per minute (a high value combined with a high ResponseTime indicates a general overload, a very low value indicates an error) |
GuiCallBackTime | Average length of time that a work process waits for the front end during the communications steps between the application server and the front end during a dialog step (roundtrips) |
FrontendNetTime | Corresponds to Dialog Network Time of the Dialog Overview |
MonitoringTime | Average time for creating the monitoring data during a dialog step (this is normally a tiny proportion of the response time, that is, the response times are only imperceptibly changed by monitoring) |
ResponseTime (StandardTran.) | Corresponds to Standardized Response Time of the Dialog Overview monitor |
LogonLoadQuality | Value for the quality of the dialog system (calculated from Users Logged On and Dialog Response Time, among other things); if you are using load balancing, this value determines which server is used at logon (see Configure Logon Groups) |
LogonLoadMessage | Status attribute with the preferred server of a logon group (the server that is to be used for the next logon, as it has the best LogonLoadQuality) |
UsersLoggedIn | Corresponds to Users Logged On of the Dialog Overview monitor |
EnqueueSubtree
The enqueue service allows applications to lock data so that only they can use it. Locking the data prevents parallel changes to the same data, which would lead to data inconsistency (see 
Functions of the SAP Lock Concept).
MTE Name | Description |
Enqueue Client | There is one instance with an enqueue service for each system ‑ this instance becomes the central instance of the system because it has this service. This monitoring object contains performance attributes for requests from the other instances to this service. |
EnqueueFreq | Enqueue operations (logical data locks) per minutes that are coming from another instance to the central instance |
Enqueue Server | Enqueue server that provides the enqueue service for the system |
QueueLength | Percentage length of the wait queue for the enqueue service in comparison to the maximum possible length of the queue |
EndedWpENQ | Number of ended enqueue work processes |
ErrorsInWpENQ | Attributes whose function is similar to the corresponding MTEs in the dialog system (see Dialog subtree); the corresponding MTEs in the dialog system have the suffix Dia instead of the suffix ENQ. |
ErrorFreqInWpENQ |
For a more precise overview of the enqueue service, use the Enqueue Monitor.
UpdateSubtree
For general information about updates, see Update Management and Update Administration (Transaction SM14).
MTE Name | Description |
PerformanceU1 | Monitoring object that contains the performance attributes of the SAP update process for high (U1) and low (U2) priority |
PerformanceU2 | |
ResponseTime | Attributes whose function is the same as the MTEs with the same names in the dialog system (see Dialog subtree) |
QueueTime | |
Utilization | |
NumberOfWpUD1 | Number of work processes of type Update 1 (high priority) and Update 2 (low priority); there must be at least one work process of type Update 1 system-wide |
NumberOfWpUD2 | |
ErrorsInWpUD1 | Attributes whose function is similar to the corresponding MTEs in the dialog system (see Dialog subtree); the corresponding MTEs in the dialog system have the suffix UD1 or UD2 instead of the suffix ENQ. |
ErrorsInWpUD2 | |
ErrorFreqInWpUD1 | |
ErrorFreqInWpUD2 | |
EndedWPUD1 | Number of ended work processes of type Update 1 (high priority) and Update 2 (low priority) |
EndedWPUP2 | |
AbapErrorInUpdate | Update requests containing errors (Check with transaction SM13; see also |
TraceSwitches Monitoring Object
You can use the trace functions to follow the process of various operations in your SAP system. This allows you to monitor the system and to isolate problems that occur. You should only use the trace information in exceptional circumstances, as it is extremely performance-critical (see also Trace Functions). In the following MTEs, the trace level rather than the trace information itself is displayed.
MTE | Decription |
R3DeveloperTrace | Developer traces are records of the SAP work processes that contain technical information for finding errors. To be able to work effectively with these entries, you must have detailed knowledge of the host system in which your SAP system is running and of the SAP system in general. |
R3SystemTrace | The system trace (transaction ST01) records internal SAP system activities. It provides system monitoring and simplifies error correction (we recommend that you use it primarily as an authorization trace). |
R3Abap Monitoring Object
Errors in the execution of ABAP programs are displayed here in the status attribute Shortdumps. The system has created a dump and reported this to the monitoring architecture. Analyze the error using transaction ST22 (ABAP Runtime Errors). For more information about this topic, see Program Checks.
Activities
To start the monitor, follow the procedure below:
...
1. Start the Alert Monitor using transaction RZ20 or choose CCMS ® Control/Monitoring ® Alert Monitor.
2. On the CCMS Monitor Sets screen, expand the SAP CCMS Monitor Templates set.
3. Start the Entire System monitor from the list by double clicking it.
Procedure if an Alert Is Triggered
DialogSubtree
If an alert occurs in this subtree, you should first check whether the dialog response time (ResponseTime) has also been affected. A long dispatcher wait queue (QueueLength) can be a sign that the application server has too few work processes or too high a CPU workload. Response times that are too long, on the other hand, can be a sign that you have too many work processes that must share the instance’s resources and therefore cause more paging.
There are many potential causes of bad dialog performance. You should first check whether the problem is due to a general overload of the server. To do this, check the statistics for CPU performance and paging (Operating System monitor). Another possible bottleneck is the database: ensure that the performance of your database is sufficient.
A combination of long wait queues (QueueLength), long wait times (QueueTime), and high utilization of the work processes (Utilization) indicates that the dialog system is overloaded or that there are problems with the database. Are there too many users in the system? Are users running long queries or other long-running transactions? Is a job using the server’s parallel background processing dialog work processes?
Possible corrective measures are:
· Distribute users onto another (additional) application server
· Encourage users to schedule long-running reports or other actions as jobs in times outside the peak workload times
· Add work processes (preferably through operation mode switching)
· Move parallel background processing jobs to times outside the peak workload times
An alert for FrontendResponseTime when there are normal values for the ResponseTime means that the problem must be at the front end or with at connection to the application server.
EnqueueSubtree
An alert in the EnqueueFreq attribute is unlikely, since the enqueue service is able to cope with even high operation rates. If an alert does occur here, it suggests that the wait times for the lock operation are having a negative effect on the entire dialog response time. Problems of this kind are normally only temporary and should resolve themselves. They occur only in extremely unusual circumstances, such as with massive parallel execution of RFC calls to a particular server.
If an alert occurs in the QueueLength attribute, analyze the problem by starting transaction SM12 and choosing Extras ®Diagnosis or Extras ® Diagnosis in Update (see also Analyzing and Correcting Errors).
No comments:
Post a Comment