There is a category of SAP performance problem that does not appear in HANA metrics. HANA memory is within range. Database response times are normal. CPU on the database host is unremarkable. And yet, users on one application server instance are reporting intermittent slowness that comes and goes without any obvious correlation to system load.
The cause is usually in the NetWeaver layer, specifically in the ABAP memory management architecture that sits between users and the database. Extended memory exhaustion, oversaturated roll areas, degraded buffer hit ratios, or synchronous RFC calls holding dialog work processes in a wait state while the response travels across a network hop: none of these produce HANA alerts. They produce dialog response time spikes that are hard to attribute without monitoring that covers the application layer specifically.
This article covers the NetWeaver and ABAP-layer metrics that define performance stability in a production SAP environment. It focuses on the signals that are distinct from database monitoring, the ones that explain the performance problems that database metrics cannot.
The NetWeaver performance layer most monitoring misses
ABAP memory management is not the database layer
SAP NetWeaver ABAP has its own memory management architecture that is independent of the underlying database. Understanding it is a prerequisite for understanding the performance metrics that monitor it.
Every user session in an ABAP system maintains a roll area: a memory segment that holds the session context between dialog steps. When a user presses Enter, the work process handling that step saves the session state to the roll area at step end, and restores it from the roll area at the next step start. The roll area itself is allocated from extended memory (EM), a shared memory segment on each application server instance. The size of extended memory is a profile parameter (abap/em_global_area_MB) configured at instance level.
When extended memory is fully allocated across active sessions, new sessions or new dialog steps cannot claim EM space. They fall back to the process-local heap (limited to what the profile allows) and ultimately to the roll file on disk, which is paging in practice. A dialog step that requires disk-based roll storage takes orders of magnitude longer than one served from shared memory. This happens transparently, with no error, and the performance impact appears as an intermittent spike in dialog response time that affects specific users rather than the entire system.
The metric that reveals this condition is extended memory utilization as a percentage of the configured limit. It is available in the ABAP memory monitor (transaction ST02) and in the workload statistics. It is rarely included in standard monitoring configurations, which tend to focus on database and infrastructure metrics rather than ABAP-layer memory.
Why intermittent slowness is often a NetWeaver problem, not a HANA one ?
The pattern that should trigger investigation at the NetWeaver layer rather than the database layer has specific characteristics. Slowness that is session-specific, not system-wide, and that resolves when a user logs out and back in, points to session-level memory state. Slowness that appears at a specific concurrent user count and recedes when sessions end points to extended memory pressure. Slowness that is consistent for one application server instance and absent on others in the same landscape points to instance-level configuration or load distribution.
None of these patterns produce obvious signals in database monitoring. HANA is processing queries with normal latency. The database host has available CPU. The monitoring dashboard shows green. The user is experiencing 8-second dialog steps. The explanation is in the ABAP layer, not in the database.
This gap between what database monitoring shows and what users experience is the reason NetWeaver-specific metrics are worth maintaining as a separate monitoring track. They answer questions that database metrics structurally cannot.
The metrics that define NetWeaver performance health
Dialog response time decomposition: the real picture behind the total
Total dialog response time is a useful trend metric but a poor diagnostic one. A total response time of 3 seconds could mean 2.8 seconds of database time and 0.2 seconds of ABAP processing, or 2.8 seconds of RFC wait time while a synchronous call to an external system completes, or 2.8 seconds of queue time waiting for an available work process. Each of those has a completely different root cause and a completely different remediation.
The workload monitor (transaction SWNC or /SDF/MON in older systems, accessible via SM66 in the performance analysis view) breaks total response time into components: processing time (pure ABAP CPU), database request time (queries to the database), roll and dequeue time (context save and restore at step boundaries), wait time (time in the work process queue before processing began), and RFC time (time spent waiting on synchronous remote function calls to other systems).
Monitoring each component separately, and alerting on anomalies in specific components rather than just the total, is what makes response time monitoring actionable. An increase in RFC time that coincides with the introduction of a new interface points to an integration performance issue. An increase in wait time that correlates with a higher concurrent user count points to a work process capacity issue. An increase in database request time without corresponding changes in HANA metrics points to missing table statistics or a query plan regression. The total time obscures all three of these. The components reveal them.
| In practice: The statistical records view in STAD provides response time breakdowns at the individual transaction level. When a specific user reports a slow transaction, STAD is the tool that shows whether the time was spent in ABAP, in the database, in an RFC call, or waiting for a work process. It produces the evidence needed to direct an investigation rather than starting from guesswork. |
Extended memory utilization: the metric that explains intermittent slowness
Extended memory is configured once at instance profile level and does not resize automatically during operation. The total available EM is shared across all active sessions on an instance. Each session claims a portion at login and releases it at logout. Sessions doing memory-intensive work, running large reports or holding large internal tables in session context, claim more than the average.
The practical threshold for extended memory utilization is 80% of the configured limit. Below that, there is enough headroom that occasional spikes in individual session memory usage do not force any session to roll. Above 80%, a single session consuming more EM than usual due to a larger-than-normal query result set can push total utilization past the limit and force other sessions into roll file territory.
Two values are relevant to monitor: current EM utilization as a percentage of the limit, and the maximum EM utilization observed over the last 24 hours. The maximum captures the peak load periods that current utilization misses. An instance where current EM utilization is 55% but the daily maximum has been touching 88% has a real risk that needs addressing, even though it looks fine at the moment of measurement.
When EM utilization is consistently high, the remediation options are increasing the configured EM limit in the instance profile (requires restart), reducing the number of concurrent sessions on the instance through load balancing changes, or identifying and addressing the programs that are holding excessive session memory, which is typically diagnosed through the memory analysis tools in the ABAP workbench.
Buffer quality: table buffer and program buffer hit ratios
SAP NetWeaver maintains several in-memory buffer layers on each application server instance, separate from HANA’s memory. Two of them have direct performance impact in most production environments: the table buffer and the program buffer.
The table buffer stores frequently read database table contents in shared memory on the application server. Tables configured for buffering (via SE13) are read from this local cache rather than from the database. For customizing tables, configuration tables, and frequently read master data tables, this eliminates database reads that would otherwise occur thousands of times per hour. A table buffer hit ratio below 98% means at least 2% of buffered table reads are going to the database because the buffer is too small to hold the full working set. In a system with high customizing read activity, this creates measurable and unnecessary database load.
The program buffer stores compiled ABAP programs in shared memory so they do not need to be reloaded from the database for each execution. A program buffer that is too small or too fragmented causes frequent program reloads, which are expensive operations that serialize through the program loader and create brief but measurable pauses. Hit ratios below 95% are worth investigating in production systems.
Both buffer hit ratios are visible in ST02 (ABAP buffer monitoring). The diagnostic that matters is not just the current hit ratio but the swap count: how many times buffer objects were evicted to make space for new ones. A buffer with a high swap count is undersized relative to the variety of objects being loaded, even if the hit ratio looks acceptable at a given moment.
| Watch out: Table buffer synchronization across multiple application server instances uses a mechanism called buffer synchronization messages. When a customizing table is changed on one instance, a synchronization message invalidates the cached version on other instances so they reload from the database. In systems under high change activity (active customizing during business hours), the buffer synchronization traffic itself can create brief performance impacts. Monitoring buffer synchronization message rates per instance flags this condition. |
Short dumps, lock entries, and the system log as performance signals
Short dump rate as a stability indicator
A short dump (ABAP runtime error, recorded in transaction ST22) represents a dialog step or background job that terminated abnormally due to an unhandled exception. The exception could be a program error, an authorization failure, a resource limit being exceeded (memory overflow, timeout), or a data inconsistency the ABAP program could not handle.
In a production ABAP system, the short dump rate should be near zero. Not because errors never occur, but because a production system should have had sufficient testing and exception handling that runtime errors in user-facing transactions are exceptional rather than routine. A system averaging 15 short dumps per day has a stability problem: some fraction of user transactions are failing, some background jobs are terminating, and the cause is being absorbed into a growing ST22 list rather than being tracked and resolved.
Short dump monitoring has two distinct signals worth tracking separately. The absolute count per day, which indicates overall stability, and the dump class distribution, which indicates what kind of problems are occurring. MEMORY_NO_MORE_PAGING and TSV_TNEW_PAGE_ALLOC_FAILED are memory-related dump classes that indicate sessions exceeding their configured memory limits. TIME_OUT indicates programs exceeding the maximum dialog step time limit. DBIF_REPO_SQL_ERROR indicates database connectivity or query issues. Each class points to a different layer of the problem.
Lock entry accumulation and its performance consequences
SAP ABAP-level locks are managed by the enqueue work process and are visible in SM12. A clean production system has a SM12 list that changes constantly as transactions acquire and release locks during normal business operations. Entries appear briefly and clear as transactions commit.
The performance condition to watch is lock entry accumulation: a growing count of lock entries on specific objects that are not releasing. This happens when a transaction acquires a lock and does not complete, either because the user started a transaction and left the screen open without finishing, or because a background job holds a lock across a long processing sequence without intermediate commits.
Accumulated locks create a hidden bottleneck. Every subsequent transaction that needs to access the same business object waits until the lock releases. Users experience this as unresponsiveness on specific transactions, without any obvious connection to the locked session elsewhere in the system. Monitoring the count and age of SM12 entries, and alerting on entries that have been held for more than a configured duration during business hours, surfaces this condition before it creates a visible incident.
A related metric is the lock table utilization: the enqueue work process maintains a lock table of fixed size. If the lock table approaches its capacity limit, new lock requests are refused and transactions fail with an enqueue error. In environments with many concurrent users or long-held locks, this capacity limit is reached occasionally. It is a rare condition but one that produces unmistakable symptoms when it occurs, and one that monitoring should catch before users do.
SM21 and the system log as a source of performance pattern data
The SAP system log (transaction SM21) records system-level events: work process restarts, memory shortages, roll file overflows, buffer synchronization events, ICM errors, and connection pool exhaustion. These events are not performance metrics in the traditional sense. They are point-in-time signals that something abnormal happened at the system infrastructure level.
Used as a monitoring source rather than as a manual review tool, SM21 provides context that no other metric layer supplies. A roll file overflow event in SM21 at 10:47 correlates with the dialog response time spike that appeared in the workload monitor at 10:47. A work process restart recorded in SM21 explains the brief interruption in dialog availability that appeared in the availability monitoring. Without SM21 data as a monitoring source, the correlation between infrastructure events and performance signals requires manual investigation each time.
The specific SM21 event classes worth monitoring continuously are work process terminations and restarts, roll area overflow events, extended memory overflow events, and buffer synchronization failures. Any of these in a frequency above one or two per hour in production indicates a systemic condition that deserves investigation, not just incident-by-incident responses.
RFC wait time: when performance is borrowed from somewhere else
Synchronous RFC calls in dialog steps and their hidden cost
A synchronous RFC call within a dialog step holds the dialog work process occupied for the duration of the entire call, including network transit time to the target system, processing time on the target system, and network transit time for the response. The calling work process cannot serve any other user during that time. If the target system is slow, the calling SAP dialog work process is slow by inheritance.
This is a frequently underestimated performance bottleneck because the cause and the symptom are in different systems. A user reports slow transaction performance on system A. The investigation shows that HANA is healthy, work processes are available, the ABAP program is efficient. What the investigation misses is that the program makes a synchronous RFC call to system B to retrieve data, and system B is under heavy load with 4-second response times on RFC calls. System A’s dialog response time includes 4 seconds of waiting for system B’s response, and system B does not appear in any monitoring that focuses on system A.
The RFC time component in the ABAP workload statistics is the metric that reveals this. When RFC time represents a significant fraction of total dialog response time, the performance problem is in the called system or the network between them, not in the SAP application layer being observed. That distinction redirects the investigation immediately and prevents wasted time optimizing the wrong system.
RFC call chains and how wait time multiplies
The situation is worse when RFC calls are chained. Transaction X on system A calls function module Y via RFC on system B, which calls function module Z via RFC on system C to retrieve additional data before returning. The user’s dialog step on system A waits for A-to-B round trip, plus B’s processing time, plus B-to-C round trip, plus C’s processing time, plus C-to-B return, plus B-to-A return. Three network hops and three processing times are serialized into a single dialog step response time.
In complex SAP landscapes with multiple connected systems, these chains are common and often invisible from any single system’s monitoring. The monitoring that catches them is either cross-system RFC performance correlation, where the RFC wait time on system A is correlated with actual response times on systems B and C, or end-to-end transaction tracing that follows the call chain across system boundaries.
The practical starting point without cross-system monitoring is identifying which RFC destinations account for the largest share of RFC wait time in the workload statistics. A single RFC destination accounting for 40% of RFC wait time across the system is a target worth investigating on the receiving side, regardless of where the dialog response time symptoms are being reported.
Operation modes and workload distribution across instances
SM63 and the dialog-to-background ratio across time
SAP operation modes (transaction SM63) allow the dialog-to-background work process ratio to be adjusted automatically based on time of day. A typical configuration runs a dialog-heavy mode during business hours and switches to a background-heavy mode overnight when batch jobs run and interactive users are absent.
Monitoring operation mode transitions as events, rather than just monitoring work process utilization, provides context for interpreting utilization metrics. A work process utilization spike that occurs precisely at the time of an operation mode switch is not a performance incident. It is the expected behavior during a transient rebalancing period. A utilization spike that occurs during a scheduled operation mode change period but extends well beyond when the transition should have completed may indicate that the mode switch did not complete correctly.
The configuration risk in operation modes is the scenario where the batch window needs more background work processes than the current operation mode provides, but the mode switch has not been updated to reflect changes in the batch schedule. The batch workload has grown. The operation mode still allocates the same background work process count it did two years ago. The result is a background work process pool that saturates during the overnight window despite the system appearing well-configured.
Load distribution across instances: where SM66 becomes essential
In a landscape with multiple application server instances, performance problems can be local to one instance while others are healthy. Logon groups, operation modes, and background job server group assignments all influence which users and jobs land on which instance. When that distribution is uneven, one instance carries disproportionate load while others are underutilized.
SM66 provides the cross-instance view of work process occupancy. Monitoring tools that only report per-instance metrics in isolation can miss the pattern where instance A is consistently at 90% dialog work process utilization while instances B and C run at 40%. The aggregate average across all three instances looks moderate. The users on instance A have a worse experience than the average suggests.
The monitoring dimension this requires is per-instance work process utilization tracked separately, not aggregated across the landscape. An alert that fires when any single instance exceeds 85% sustained dialog WP utilization, regardless of what other instances are doing, catches the imbalance. An alert on system-wide average utilization misses it.
Building a NetWeaver performance baseline that is actually useful
A NetWeaver performance baseline serves a different purpose from a HANA performance baseline. HANA metrics have relatively stable normal ranges that apply across environments with similar workload profiles. NetWeaver metrics are highly specific to the instance configuration and the behavior of the ABAP programs running on that instance.
Extended memory utilization normal range depends on how many concurrent sessions the instance typically runs and how memory-intensive those sessions are. Buffer hit ratios depend on which tables are buffered and whether the buffer is sized to hold the working set. RFC wait time depends on which external systems are called and their typical response times. None of these have universal normal values.
A useful NetWeaver baseline is built by collecting four to six weeks of metrics across business days, capturing the variation between Monday peak load and Thursday afternoon, between the start of month-end and a normal mid-month Tuesday. From that data, per-metric normal ranges emerge: not as single values but as time-of-day and day-of-week distributions that reflect real operating patterns.
The practical outcome of that baseline is threshold configuration that is specific enough to be actionable. An extended memory utilization alert at 80% of the instance limit, set based on a baseline that shows the normal peak is 65%, is a meaningful signal. An alert at 80% applied to an instance whose normal peak is 78% will fire every business day and be ignored within a week.
One metric worth building into the baseline specifically because its degradation is slow and cumulative: buffer swap rates. The table buffer and program buffer swap rates under normal conditions are low. If the swap rate trend line is gradually increasing over months, the buffer working set is growing, and the configured buffer size will eventually become insufficient. Catching that trend in the baseline data and adjusting buffer configuration before performance degradation occurs is exactly the kind of proactive maintenance that monitoring is supposed to enable.
The application layer between users and the database
NetWeaver and ABAP metrics occupy a monitoring blind spot in many SAP environments because they fall between two well-understood layers. Infrastructure and OS monitoring covers the server. Database monitoring covers HANA. The NetWeaver layer, with its own memory management, its own buffer infrastructure, its own work process scheduling, and its own lock management, sits between the two and is frequently monitored less rigorously than either.
The gaps that result are predictable: intermittent performance degradation that database metrics do not explain, buffer hit ratio degradation that creates unnecessary database load, synchronous RFC chains that serialize performance problems across multiple systems, and short dump accumulation that signals stability issues nobody has investigated because the total count never looked alarming enough.
None of these require sophisticated tooling to catch. They require collecting the right metrics at the right layer and maintaining baselines that make deviations recognizable. The ABAP workload monitor, ST02, ST22, SM12, and SM21 contain the data. The question is whether it is being read by monitoring infrastructure at a frequency that makes it useful for early detection rather than just for post-incident investigation.
Redpeaks monitors SAP NetWeaver ABAP environments from the application layer down, covering extended memory utilization, buffer hit ratios, response time decomposition by component, RFC wait time by destination, and short dump trends. No agents, no transports. See the NetWeaver monitoring coverage.
