Architecture
- To complete the logon process, the presentation server connects with a dispatcher.
- When the user tries to run a transaction, the user's request comes from the presentation server to the dispatcher and is put into the local wait queue.
- When the dispatcher recognizes that a work process is available, the user's request is taken from the wait queue and sent to the work process
- When a user is dispatched to a work process, "user context" data – the user's logon attributes, authorizations, and other relevant information – is transferred from the roll buffer, extended memory, or the roll file into the work process. This transfer (by copying or mapping, as appropriate) of user context data into work process memory is the mechanism known as a "roll in". Transaction processing then begins.
- If data from the database is required to support transaction processing, a request for data is sent to the database interface, which in turn sends a request through the network to retrieve the information from the database.
- When it receives the request, the database searches its shared memory buffers. If the data is found, it is sent back to the work process. If the data is not found, it is loaded from the disk into the shared memory buffers.
- After being located, the data is taken from the shared memory buffers and sent back across the network to the requesting database interface. Transaction processing resumes.
- Before accessing the database service, the database interface searches for the data in the R/3 buffers. If the data is found, it is relayed back to the work process where processing resumes. If the data is not found, the database interface sends a request over the network to retrieve the information from the database
- If the data loaded from the database is eligible for R/3 buffering, it is placed in the R/3 buffers. Transaction processing resumes.
- When transaction processing is completed, the dispatcher is notified of its completion. The results of the transaction are then sent back to the presentation server.
- After the transaction finishes and the work process is no longer required, the user context data is rolled out of the work process.
- CPU time is the amount of time during which a particular work process has active control of the central processing unit (CPU).
Performance Analysis - Key transaction for Performance monitoring in R/3
Work Process SM50/SM66
Operating system monitoring ST06
Workload analysis, use the Workload Monitor (transaction ST03 or ST03N).
Database monitoring ST04
Setup and buffer ST02
Workload time statistics include:
- Response time in milliseconds: Starts when a user request enters the dispatcher queue; ends when the next screen is returned to the user. The response time does not include the time to transfer from the screen to the front end.
- Wait time in milliseconds: This is the time a user request sits in the dispatcher queue. It starts when user request is entered in the dispatcher queue; and ends when the request starts being processed.
- Roll-in time in milliseconds: The amount of time needed to roll user context information into the work process.
- Load time in milliseconds: The time needed to load from the database and generate objects like ABAP source code, CUA, and screen information.
- Processing time: This is equivalent to response time minus the sum of wait time, database request time, load time, roll time, and enqueue time.
- Database request time: Starts when a database request is put through to the database interface; ends when the database interface has delivered the result.
- CPU time in milliseconds: This is the CPU time used by the R/3 work process
If a problem is detected, the data in the Workload Monitor (Transaction ST03N) can be used as follows to identify the area of the system where the problem is located.
First check for general performance problems affecting all transactions. Good general performance is normally indicated by:
- Wait time < 10% response time
- Main menu (choose Transaction Profile) < 100 ms
- In the Workload Monitor, the following values normally indicate good performance:
- Average roll-in time < 20 ms
- Average roll wait time < 200 ms
- Average load (and generation) time < 10 % of response time (<50 ms)
- Average database request time < 40 % of (response time - wait time)
- Average CPU time < 40 % of (response time - wait time)
- Average CPU time Not much less than processing time
Average response time - Depends on customer requirements – there is no general rule
Large roll wait time - Communication problem with GUI
Large load time – Program buffer, CUA buffer or screen buffer too small
Large DB time – CPU /mem bottleneck on DB server, Expensive SQL statement, missing indexes, small buffer, missing statistics.
IF wait time >10%
High database time >40% (response time – wait time) – Analyze database
Processing time > CPUtime *2 – Analyze hardware
Load time >50 ms – Analyze R/3 memory config ( program buffer too small)
Roll in / roll out time >20 ms - Analyze R/3 mem config (extended mem or roll buffer)
Analysis of SM50 / SM66
- To display a snapshot of the current activities on the instance you are logged on to, use the Work Process Monitor. Call transaction SM50, or, from the R/3 initial screen, choose Tools >> Administration >> Monitor >> System monitoring >> Process overview.
- The information displayed includes:
- Type of work process
- Name of the ABAP program running
- Operating system PID number
- Client being used
- Name of the job executing
- Current action
- Number of detected errors in the work process
- Table being utilized
- Semaphore resource being used
- CPU accumulation
- Time in process accumulation
- User holding the resource
- If all work processes are being blocked by long running transactions, the above information is also available on operating system level by using program dpmon.
- In an R/3 System with more than one instance, you can access a global work process overview using transaction SM66.
Analysis work flow .
Work process in status ‘running’ and Action Direct Read, Sequential read, Insert, Update, Delete, Commit. – Analyze Database
Work process in status ‘running’ and Action load program – Program buffer too small
Work process in status ‘running’ and Action rollin /rollout – Extended memory or roll buffer analysis needed.
Work process in status ‘stopped’ and reason ‘priv’ – Detail analysis for memory, issue with extended memory or roll buffer.
Work process in status ‘stopped’ and reason ‘cpic’- Problem with CPIC connection. The remote system’s all work process may be in use.
Analysis for ST06 (Operating System monitoring)
If the idle CPU is indicated as being less than 20 %, there is a CPU bottleneck. In an optimal configuration, more than 35 % CPU capacity is idle
If there is a CPU bottleneck:
1. If possible, redistribute load to other servers.
2. To find out which processes are using the most CPU, in the Operating System Monitor choose Detail analysis menu >> Top CPU processes. If the processes have high CPU utilization, proceed as follows:
- For R/3 work processes ("disp+work"): Using the process ID indicated in Top CPU processes, identify the corresponding program name and user name in the Work Process Overview (transaction SM50).
- For database processes: Identify corresponding long running SQL statements in the Database Process Monitor. To access this monitor, call transaction ST04 (Database Overview), and choose Detail analysis menu. Then choose, for example, Oracle Session.
- For external processes, find out whether the process can be stopped or redistributed.
Amount of memory indicated beside Physical memory available. Compare this figure with the paging rate. To obtain the paging rate, double-click Pages in/s. The paging rates for the last 24 hours are displayed in the columns Paged in [Kb/h] and Paged out [Kb/h]. If 20% of the total amount of physical memory is greater than the amounts indicated in these columns, you can normally be sure there is no memory bottleneck.
- If there is a memory bottleneck:
1. If possible, redistribute load to other servers.
2. Check the size of the file system cache – See SAP Note 78498 in SAPNet. If necessary, reduce file system cache to < 10% of the total physical memory.
3. To identify users and their programs with a high memory consumption, call the Mode List for the extended memory. To do this, in the Setups/Tune Buffers monitor (transaction ST02), choose Detail analysis menu >> SAP memory >> Mode List.
|
