This blog post in my series of posts related to SAP GUI transaction
ST05 (introduced in
Use ST05 to Analyze the Communication of the ABAP Work Process with External Resources) explains the tool's inner workings and configuration options, and how they affect its behavior. With this knowledge, you can avoid some pitfalls that otherwise would make your performance analyses less convenient or less reliable.
My blog post
ST05: Basic Use describes the straightforward work with this analysis tool so that you can record your applications' communications with external resources across the boundaries of the ABAP work process. This current post does not teach you any new tricks, and you may safely ignore it at first—as long as you remember it exists when you feel that
ST05 misbehaves. Then the tool's technical background as presented here does explain that
ST05 actually works as designed.
Authorizations
Transaction
ST05 is protected by authorization object
S_ADMI_FCD, which checks accesses to various basis functions. It defines a single authorization field, also called
S_ADMI_FCD, for these system administration functions. The relevant values are
ST0M Authorization to activate or deactivate trace recording
ST0R Authorization to analyze traces
There are no further checks. In particular,
every user with the authorization to switch tracing on or off can deactivate a trace recording switched on by any other user. Similarly,
every user with the authorization to analyze traces may see all available trace records, independent of who activated their recording, or who triggered the recorded event.
Trace Recording
ST05 really is just a display transaction. The only changes it can trigger are via buttons
Activate Trace and
Deactivate Trace (and the closely related buttons
Activate Trace with Filter and
Deactivate Trace on All Instances). These actions modify the so-called
SWitches
Block (SWB) in the
Shared
Common
System
Area (SCSA), a small shared memory segment accessed by SAP executables (kernel programs). The SWB content determines whether tracing is on or off, which trace types (i.e., communication interfaces) are to be recorded, and what filter conditions shall be applied. The actual capturing of the communication events according to these settings is done by the ABAP kernel.
Because the SCSA is shared across the entire application server instance,
trace recording does not work concurrently, i.e.,
ST05 cannot capture communication events triggered by distinct users (or by distinct user groups defined with a trailing wildcard
*).
With one SCSA per instance, tracing is instance specific so that at the same time it can be active for one user on one instance, and for another user on another instance (and inactive on other instances). This also demands that the application whose communication requests you want to capture runs on the instance where trace recording was switched on. Simple trace evaluation via the
Display Trace button is also instance specific, i.e., only works with trace records previously captured on the same application server instance. Altogether,
trace recording, application execution, and trace analysis must all be done on the same application server instance.
Trace recording is always cross-client. Active tracing captures communication events related to each and every client in the system.
When trace recording is active, the kernel saves trace records into dedicated (binary) files on the application server instance's file system. The base name of these files (including the path) is fixed by the value of profile parameter
rstr/filename (e.g., /usr/sap/YI3/D34/log/TRACE). New trace records are always stored into a file by exactly this name. When it is filled to its capacity (as defined in megabytes by profile parameter
rstr/max_filesize_MB; default value 16, maximum value 100), the file is renamed by appending a two-digit number between 00 and 99 to the base filename. If a file by that name already exists, it will be discarded. An empty file with the base filename is recreated, and trace recording into this newly created file continues without any gap. The maximum number of trace files (active plus overflow) is defined by profile parameter
rstr/max_files (default value 10, maximum value 99). If this number of files is exceeded, the oldest file is deleted, and recreated to act as the youngest overflow file. As a consequence of this round-robin approach,
old trace records are eventually lost, and
a trace may overwrite its own beginning if recording is active for too long, or if the traced application triggers a large number of recorded events. Depending on the specified filter conditions for trace recording (cf. my blog post
ST05: Activate Trace Recording with Filter), on the traced load on the application server instance, and on the configured number and size of trace files, this may happen within just a few minutes.
To minimize the impact of trace recording on the instance's performance, the records are not appended immediately and individually to the trace file, but first cached in an internal memory buffer within the ABAP work process. This buffer's size (in kilobytes) is given by profile parameter
rstr/buffer_size_kB (default value 500). If the size of a single statement (including its variables’ values) exceeds this limit, it will be truncated.
The method used for trace recording, as described above, implies that on the technical level there are only individual trace records, stored one after the other. The concept of a trace as a set of records that belong together has no technical realization. Of course it is still a useful mental notion when you work with
ST05 to analyze your application's communication events.
Based on benchmark runs, the average size of a trace record is less than 1kB and the overhead for server response time, as well as ABAP CPU time, is less than 3%.
Additional Trace Types
The SWB in the SCSA supports more trace types than are exposed by
ST05. The corresponding interfaces deal with authorization checks done by your applications, or with low-level calls to the kernel's C functions or C modules. You can control and analyze these trace types in transaction
ST01, together with the others, which are more frequently used and therefore accessible in
ST05.
The inability to trace concurrently also extends to these
ST01-only trace types. Thus, in rare cases your attempt to record a trace with
ST05 may fail although the
Trace State area on its start screen is empty. A popup will then explain the situation with an information message:
At least one trace type was already activated for user <NN>. (This may be an ST01 trace.) The trace is not activated. You may want to discuss the situation with the given user.
Stack Trace
As I have described in my blog post
ST05: Basic Use, in the
Configure Trace area on
ST05's start screen you can request that relevant communication activities shall be recorded together with their triggering ABAP call hierarchy (
Stack Trace =
On). With the setting
Stack Trace =
Off , which is the default in customer systems, only the immediate caller will be recorded.
The recording of the stack trace uses a delta strategy. Each trace record stores only those parts of the corresponding event's ABAP call stack that have not yet been captured in previous records. The correct and complete ABAP call stack is assembled only at display time, i.e., on demand. This approach minimizes the recording overhead for including the stack trace, and—equally important—the size of the trace records does not grow too much so that precious space in the trace files is saved and available for further trace records. This technique comes with a disadvantage: If you apply a filter to the trace records at display time, parts of the call hierarchy may not pass the filter. Then the ABAP call stack cannot be reassembled.
ST05 detects this situation and indicates it with a warning popup:
Cannot fully display ABAP call hierarchy for statement of selected trace record. To avoid this type of problem, do not filter records when you display a trace taken with
Stack Trace =
On. Prefer to set a filter already while tracing, which saves even more space in the trace files.
Capturing call stack information takes ~30µs per trace record, and increases the record size on average by ~50%. Thus trace recording with
Stack Trace =
On increases the danger that a trace overwrites its own beginning.
Profile Parameters
Table 1 summarizes the profile parameters that govern how the trace recording works.
Table 1: Profile parameters to control trace recording.
Name |
Explanation |
Default Value |
Maximum Value |
rstr/accept_remote_trace |
Accept trace switches from remote client? |
FALSE |
N/A |
rstr/auth_delim_tab |
Use tabulator (instead of '&') as separator in authorization trace |
TRUE |
N/A |
rstr/buffer_size_kB |
Size of trace buffers
(one buffer per work process) |
500 |
|
rstr/filename |
Base name of the trace files |
|
N/A |
rstr/max_files |
Maximum number of trace files |
10 |
99 |
rstr/max_filesize_MB |
Maximum size of one trace file |
20 |
100 |
rstr/send_global_trace |
Send global trace switches (together with user-specific settings) to remote server? |
FALSE |
N/A |
References
SAP note 12715 (Collective note: problems with SCSA) covers potential issues with the SCSA.
