ST03N (Workload Analysis)

 

Workload Analysis (ST03N) in SAP Basis

ST03N: Workload Monitor

Purpose: ST03N (Workload Monitor) is one of the most powerful and frequently used transaction codes in SAP Basis for performance analysis and monitoring. It provides detailed statistics on the SAP system's workload, resource consumption, and response times, broken down by various dimensions such as transaction, user, program, work process type, time, and more. It helps administrators identify bottlenecks, analyze trends, and optimize system performance.

How ST03N Collects Data:

• Performance Collector (SAP Performance Collector): This is a background process (typically part of the SAP kernel) that collects performance data from the work processes, enqueue server, update server, and other SAP components.
• Data Aggregation: The collected data is aggregated and stored in performance history tables in the database.
• Hourly/Daily/Weekly Aggregation: Data is typically aggregated hourly, then daily, and finally weekly/monthly, allowing for historical analysis without excessive data volume.

Key Information and Views in ST03N:

The left-hand pane of ST03N shows the "Monitor View" which typically includes:

• Collector & Performance Database: Status of the performance collector.
• Total: Aggregate data for the entire system (all instances).
• <Instance Name>: Data specific to a particular application server instance.
• Shared Memory: Memory statistics.

The main display area on the right shows the actual workload data, which can be viewed in various "Analysis Views" selected from the "Analysis View" dropdown or tabs:

1. Workload Overview:

   • Provides a high-level summary of response times, CPU time, database time, load generation, and throughput for dialog, background, update, and spool work processes.
   • Response Time Breakdown: Crucial for identifying where time is being spent (e.g., Dialog Step, Roll In/Out, Load/Gen, DB Time, Enqueue Time, Roll Wait, CPU Time, Network Time).

2. Time-Based Views (e.g., Last Hour, Last Day, Last Week, Last Month, Specific Day/Hour):

   • Allows you to analyze workload trends over different time periods. Essential for understanding peak load times and historical performance.

3. Top N Lists:

   • Transactions Profile: Top N transactions by response time, CPU time, database time, calls.
   • Dialog Step Profile: Top N dialog steps.
   • Report/Program Profile: Top N reports/programs by resource consumption.
   • User Profile: Top N users by response time, CPU time, etc.
   • RFC Profile: Performance of RFC calls (local and external).
   • Web Statistics: For Web-based interactions (ITS, ICM).

4. Resource Consumption Views:

   • Load and Generation Time: Time spent loading programs from disk or generating ABAP bytecode.
   • Memory Use: Memory consumed by work processes.
   • DB Call Profile: Detailed breakdown of database calls by type (reads, writes, deletes, updates).
   • SQL Statement Profile: Top N expensive SQL statements. (Requires certain database configurations and SAP kernel versions).
   • Frontend Network Time: Time spent transferring data between the SAP GUI and the application server.

Important Metrics to Watch:

• Average Response Time: The most common indicator of system performance. Should be low (e.g., < 1-2 seconds for dialog steps).
• Response Time Distribution: Look at the breakdown (DB Time, CPU Time, Enqueue Time, Load/Gen Time, Roll In/Out Time, Roll Wait Time, Network Time) to pinpoint bottlenecks.
  • High DB Time: Indicates a database bottleneck (slow queries, missing indexes, database server issues).
  • High CPU Time: Indicates application server CPU saturation or inefficient ABAP code.
  • High Load/Gen Time: Indicates issues with program buffer, frequent program loading, or network latency for program fetching.
  • High Roll In/Out Time / Roll Wait Time: Indicates memory issues on the application server (e.g., insufficient extended memory).
  • High Network Time: Indicates network latency between the user's GUI and the application server.
• Throughput: Number of dialog steps, updates, background jobs processed per second/minute.
• Load Generated: Number of screens, RFC calls, database calls.
• Errors: Number of aborted transactions, database errors.

Actions and Features in ST03N:

• Aggregations: Switch between hourly, daily, weekly, and monthly aggregations.
• Detail Views: Double-click on entries in the "Top N" lists to get more granular details.
• Comparison: Compare workload data between different time periods or different instances.
• Export: Export data to a spreadsheet.
• Parameter Settings: Configure the performance collector and data retention periods (via menu: Collector/Performance DB -> Performance Database -> Workload Collector -> Parameters).

Important Considerations/Best Practices for ST03N:

• Regular Monitoring: ST03N is fundamental for daily/weekly/monthly performance reviews.
• Baselining: Understand your system's normal workload and response times during peak and off-peak hours. This baseline is crucial for identifying deviations.
• Top-Down Analysis: Start with the Workload Overview to identify high-level issues (e.g., high average response time). Then, drill down into "Top N" lists (transactions, users, programs) and resource consumption profiles (DB Call Profile, Memory Use) to pinpoint the root cause.
• Correlation with Other Tools:
  • SM50/SM66: For real-time work process analysis when a problem is ongoing.
  • ST06: For OS-level bottlenecks (CPU, memory, disk I/O).
  • ST04/DB02: For detailed database performance analysis (SQL statements, buffer quality, table space).
  • SM12: For enqueue lock analysis.
  • SM13: For update process analysis.
• Identifying Bottlenecks:
  • High DB Time: Check ST04, consult with DBAs, analyze custom reports (SE30/SAT), consider indexing.
  • High CPU Time: Check ST06 (OS CPU), analyze inefficient ABAP code (SE30/SAT).
  • High Load/Gen Time: Check program buffer (ST02), network latency.
  • High Roll/Page Time: Check memory parameters (ST02, RZ10), physical RAM.
• Performance Optimization: Use ST03N data to justify hardware upgrades, code optimizations, or parameter tuning.

---

Important Configurations to Keep in Mind (Workload Analysis)

These configurations are primarily managed by profile parameters and background jobs.

1. Workload Collector Background Job:

   • SAP_COLLECTOR_FOR_PERFMONITOR: This is a crucial background job (program RSSTAT80) that runs hourly on the SAP Central Instance (CI) or Primary Application Server (PAS). It's responsible for collecting and aggregating the performance statistics into the ST03N history tables.
   • Configuration Note: Ensure this job is scheduled and running successfully at least hourly. If it fails or is not running, your ST03N data will be incomplete or outdated. Check its status in SM37.

2. Data Retention Periods (Profile Parameters via RZ10 or ST03N parameters):

   • stat/max_files: Maximum number of statistical files kept (older files are deleted).
   • stat/max_records: Maximum number of records in the statistical file.
   • stat/as_file: Path to the performance statistics file.
   • stat/level: Level of detail for statistics collection (0=off, 1=basic, 2=detailed). Generally, keep at 1 or 2.
   • stat/resolution: Resolution of data collection (e.g., hourly).
   • Configuration Note: You can configure the retention period for hourly, daily, weekly, and monthly data directly within ST03N (Menu: Collector/Performance DB -> Performance Database -> Workload Collector -> Parameters -> Reorganization). Ensure you have sufficient retention for historical analysis (e.g., several weeks of daily data, several months of weekly/monthly data) but not so much that it consumes excessive database space.

3. Profile Parameters for Performance Counters (via RZ10):

   • stat/level: Controls the level of detail for workload statistics collection (0=off, 1=basic, 2=detailed). Keep it at 1 or 2 for useful data.
   • stat/timestamp_resolution: Determines the precision of timestamps in the statistics.
   • Configuration Note: Avoid setting stat/level to 0 in production systems, as it disables collection.

4. Database Parameters (Indirect Impact):

   • Database buffer sizes, I/O performance, and general health (monitored via ST04/DB02) directly impact the "DB Time" component in ST03N.
   • Configuration Note: Optimize database parameters based on DBA recommendations and SAP best practices.

5. Operating System Parameters (Indirect Impact):

   • OS-level CPU, memory (Extended Memory, Heap Memory), and network configurations directly impact the "CPU Time," "Roll In/Out," and "Network Time" components in ST03N.
   • Configuration Note: Ensure sufficient OS resources and proper parameter tuning (e.g., for em/initial_size_MB discussed in ST06 notes).

---

10 Interview Questions and Answers (One-Liner) for ST03N

1. Q: What is the primary purpose of ST03N?

   • A: To analyze and monitor the SAP system's workload and performance history.

2. Q: Which background job collects data for ST03N?

   • A: SAP_COLLECTOR_FOR_PERFMONITOR (program RSSTAT80).

3. Q: What is the most important metric to check first in the ST03N "Workload Overview"?

   • A: Average Response Time.

4. Q: If "DB Time" is consistently high in ST03N, what does it indicate?

   • A: A database performance bottleneck.

5. Q: If "CPU Time" is high for dialog steps, what is the likely bottleneck?

   • A: Application server CPU saturation or inefficient ABAP code.

6. Q: What does high "Roll In/Out Time" suggest in ST03N?

   • A: Memory issues on the application server (e.g., extended memory exhaustion).

7. Q: How can you find the most resource-consuming transactions in ST03N?

   • A: By checking the "Transaction Profile" in the "Top N" lists.

8. Q: Why is it important to keep the SAP_COLLECTOR_FOR_PERFMONITOR job running?

   • A: To ensure that ST03N data is collected and up-to-date.

9. Q: Can ST03N show you the performance of RFC calls?

   • A: Yes, via the "RFC Profile."

10. Q: What is the benefit of analyzing "Last Month" data in ST03N?

    • A: To identify long-term workload trends and seasonal patterns.

---

5 Scenario-Based Questions and Answers for ST03N

1. Scenario: Users report that specific custom reports (Z-reports) are running very slowly. You check ST03N for the "Last Day" and observe that these Z-reports appear in the "Top N Transactions" list with high "Average Response Time" and, specifically, a very high percentage of "DB Time."

   • Q: What is the likely cause of the performance issue, and what would be your next steps?
   • A:
     • Likely Cause: The performance bottleneck is at the database level, likely due to inefficient SQL queries within these custom reports (e.g., missing indexes, full table scans, large data selections).
     • Next Steps:
       1. Analyze SQL: Go to the "SQL Statement Profile" in ST03N (if available and configured) or use ST04/DB02 to analyze the most expensive SQL statements.
       2. ABAP Debugging/Traces: Use transaction SE30 (Runtime Analysis) or SAT (ABAP Trace) for these specific reports to identify the problematic ABAP code and database access patterns.
       3. Consult DBA/Developer: Work with the database administrator (DBA) to check for missing database indexes or statistics. Work with the ABAP developer to optimize the report's logic and database access.

2. Scenario: The overall system performance feels sluggish during peak business hours. When you check ST03N for the "Last Hour," the "Workload Overview" shows a healthy "Average Response Time" (e.g., 500ms), but the "Load Generated" (especially "Dialog Steps") is extremely high, and the "CPU Time" component of the response time is also high. You also see a high "Load Average" in ST06.

   • Q: What is the primary bottleneck, and what potential solutions would you explore?
   • A:
     • Primary Bottleneck: Application server CPU saturation. The response time is good because the system is processing many small steps, but the overall throughput is causing the CPU to be overworked.
     • Potential Solutions:
       1. Identify Resource Hogs: Use the "User Profile" and "Transaction Profile" in ST03N to identify if a few users or specific transactions are generating an exceptionally high number of dialog steps.
       2. Optimize High-Volume Transactions: Consult with developers/functional teams to optimize the most frequently called or resource-intensive transactions.
       3. Load Balancing: If you have multiple application servers, ensure workload is evenly distributed (check SMLG).
       4. Hardware Upgrade: If the workload is legitimately high and optimized code doesn't suffice, consider upgrading the CPU resources of the application server(s) or adding more application servers.

3. Scenario: You log into ST03N, but the data for "Last Day," "Last Week," and "Last Month" is missing or severely incomplete, although the "Last Hour" data is available.

   • Q: What is the most probable reason for this, and how would you fix it?
   • A:
     • Probable Reason: The background job responsible for aggregating and storing historical performance data (SAP_COLLECTOR_FOR_PERFMONITOR / RSSTAT80) is not running or has failed for an extended period.
     • Fix:
       1. Check Job Status: Go to SM37 and check the status of the SAP_COLLECTOR_FOR_PERFMONITOR job for the periods where data is missing.
       2. Analyze Job Log: If the job failed, check its job log for error messages.
       3. Reschedule/Restart: If the job is not scheduled or has stopped, reschedule it to run hourly. If it's failing, troubleshoot the cause (e.g., authorization issues, program errors, database space).
       4. Manual Aggregation (if needed): In some cases, you might be able to manually trigger aggregation for past periods, but fixing the job is the primary solution.

4. Scenario: A user complains that the SAP GUI frequently "freezes" or takes a long time to respond when interacting with the system, even for simple actions. ST03N shows high "Frontend Network Time" in the "Response Time Distribution" for this user's transactions.

   • Q: What is the likely cause, and what areas would you investigate outside of the SAP application server?
   • A:
     • Likely Cause: Network latency or bandwidth issues between the user's SAP GUI client and the application server.
     • Investigation Areas:
       1. User's Location/Network: Check the user's physical location, their local network connection (Wi-Fi vs. wired), and their ISP.
       2. Network Path: Perform network diagnostics (e.g., ping, tracert/traceroute) from the user's machine to the SAP application server to identify latency or packet loss.
       3. Firewalls/Routers: Check if any firewalls, routers, or proxies between the user and the SAP system are causing delays or bottlenecks.
       4. VPN Performance: If the user is on VPN, investigate VPN performance.
       5. SAP GUI Version: Ensure the user has a relatively current SAP GUI version.

5. Scenario: After implementing a new custom development, you notice that "Load and Generation Time" has significantly increased for all users, and ST02 (Buffer Monitor) shows frequent "swaps" or high "free" entries in the program buffer (PXA buffer).

   • Q: What is the connection between these observations, and what parameter would you consider adjusting?
   • A:
     • Connection: The new custom development likely introduced many new or large programs/objects. The increased "Load and Generation Time" in ST03N indicates that the system is spending more time loading and generating these programs. The high "swaps" in the PXA buffer (seen in ST02) mean that programs are frequently being "swapped out" of the buffer due to lack of space and then reloaded when needed, causing the generation time.
     • Parameter to Adjust: abap/buffersize (PXA Buffer size).
     • Action: Increase the value of abap/buffersize in the instance profile (RZ10) and restart the application server. This will provide more memory for the program buffer, reducing swaps and improving load/generation times.

---