Reading the Workload Monitor Without Guessing

The workload monitor is the first place a BASIS admin should look when performance problems are reported. The tools available — SM50, SM66, ST05, AL08, and SM21 — each answer a different question. Knowing which question each tool answers, and in what sequence to ask them, is what separates systematic performance diagnosis from guesswork.

SM50 vs SM66

SM50 shows the work processes of a single application server instance. SM66 shows all work processes across all instances in the system. For a multi-instance landscape, SM66 is the starting point for system-wide performance diagnosis. SM50 is for drilling into a specific instance once SM66 has identified which one is under load.

Both transactions refresh on demand (F8) or can be set to auto-refresh. In a live incident, run them with a 5-10 second refresh interval to observe the pattern over time — a snapshot is often less informative than watching how work processes transition between states.

Work Process Types

SAP uses specialised work processes for different request types. Understanding what each type does explains what is slow when a work process type is saturated.

Dialog (DIA) processes handle interactive user requests — the transactions users run in the GUI or browser. When all dialog processes are occupied, new requests queue. Users experience this as the GUI appearing to hang.

Background (BGD) processes run scheduled and ad-hoc background jobs. Background job saturation does not directly affect dialog users unless background jobs are consuming CPU or I/O that other processes need.

Update (UPD and UP2) processes handle asynchronous database updates triggered by V1 and V2 update tasks. If update processes are saturated, posting transactions complete from the user's perspective but the actual database changes queue. SM13 shows the update queue.

Enqueue (ENQ) processes manage the SAP lock table. Enqueue contention is visible in SM12 and causes lock wait times in dialog processes.

Spool (SPO) processes handle print and output requests.

When SM66 shows a work process type consistently at or near 100% utilisation, that is the bottleneck. The question then is why.

Response Time Components

Every SAP transaction response time can be decomposed into components. The workload statistics (transaction ST03N or the workload overview in SM66) show the breakdown for sampled requests.

CPU time is the time the application server spent computing. High CPU time relative to total response time indicates application server processing is the bottleneck.

Database time is the time waiting for database responses. High database time (especially as a proportion of total response time) points to slow SQL, missing indexes, or database server load.

RFC+CPIC time is time waiting for remote function calls to complete — calls to other SAP systems, external systems, or BAPIs. High RFC time suggests a downstream system is slow or unavailable.

Wait time is time a request spent waiting for a work process to become available. Consistent wait time means you have insufficient work processes for the load.

Load+generation time is time spent loading ABAP programs from the database. Elevated load times suggest the program buffer needs tuning or programs are not staying resident.

Finding the Bottleneck

The systematic approach to a performance complaint starts in SM66. Look at: total work process count and utilisation by type, response time breakdown in ST03N for the affected time period, and whether the problem is one specific user/transaction or system-wide.

If database time is dominant: go to ST05 or the HANA SQL analyzer and identify the slow statements. If CPU time is dominant: look for expensive reports or background jobs running at the same time. If wait time is dominant: you either need more work processes (profile parameter rdisp/wp_no_dia for dialog) or something is holding work processes for unusually long periods.

For immediate relief during a live incident: use SM04 to identify which user sessions are active and how long they have been running. Long-running dialog processes (more than 5 minutes in a dialog work process is unusual) indicate either a genuine business process that takes long or a stuck session. SM50 shows the current status and current ABAP call stack for each work process — this tells you exactly what code is executing.

ST05 for SQL Analysis

Transaction ST05 is the SQL and RFC performance trace tool. For database-related performance problems, enable the trace, reproduce the problem, disable the trace, and analyse the result.

The ST05 analysis view shows every SQL statement executed during the trace period with: statement type, table accessed, duration, and rows returned. Sort by duration descending to find the slowest statements. Sort by count descending to find the most frequently called statements.

A statement with high duration and low rows returned suggests a missing or ineffective index. A statement with high count (called thousands of times) is likely inside a loop — the SELECT-in-loop anti-pattern. A statement with high rows returned that is not an intentional mass read suggests a missing WHERE condition.

For HANA systems, ST05 can be complemented by the HANA SQL analyzer which provides the actual execution plan and HANA-specific execution statistics.

AL08 and User Sessions

AL08 shows all logged-on users across all application servers with their current transaction, response times, and session state. It is useful for: identifying specific users consuming disproportionate resources, finding stuck or very long-running sessions, and understanding the live user load distribution across instances.

From AL08 you can navigate directly to the work process detail for a selected user, or to SM04 for their session details. If a user's session is consuming a work process for an unusually long time, AL08 is where you find it.

SM21: The System Log

SM21 is the SAP system log. For performance investigations, SM21 is a secondary tool — it records error events, not performance statistics. However, performance-related errors (work process restarts, memory alerts, update queue overflow) appear here. After a performance incident, check SM21 for error entries in the same time window to understand whether the performance problem was accompanied by system-level events.

Filter SM21 by problem class (errors, warnings) and by the time window of the incident. A cluster of work process termination entries, update errors, or enqueue overflow messages alongside the performance reports tells a different story than clean system logs.

> Editorial note: Transaction availability and behaviour varies by SAP release. SM66 is available from SAP Basis 7.0 onwards. ST03N replaced ST03 as the primary workload analysis tool from SAP Basis 7.1. Verify tool availability in your specific release.