Hi All,
This is my first blog and thought of writing it on day to day issues which each Basis consultant faces like Slowness/poor performance of SAP system. Generally this issue is reported by End Users.
Performance of SAP system is depended on so many things. Hardware, OS, storage box, storage agent, clustering agent, database, customized (Z) programs and overall the usage intelligence of the users and the configuration/installation done initially.
Here are the few things which can be taken into consideration while fine tuning your SAP system
PERFORMANCE TUNING-:
The response time is usually split into wait plus execution time. The SAP response time is made up of the following components.
Response time = Wait time + Execution time
Where, Execution time = Generation time during the run.
+ Load time for programs, screens and the graphical interface
+ Roll time for rolling in the work data [Rollin and Rollout]
+ ABAP Processing time
+ Database time
+ Enque time for Logical SAP lock processes
+ CPIC/RFC time.
The CPU time is not an additive component of the response time, but the total of the individual components of the utilized CPU time. The CPU time is therefore an additional, independent piece of information about the response time.
SAP GUI time is not a part of the response time.
RESPONSE TIME-:
The time taken by the user request to process the users task right from the dispatcher to database.
OR
Time taken by the Work Process to serve user requests.
- GUI TIME-: The time taken by the user request to reach the dispatcher.
If GUI time > 200ms then consider the following-:
- (a) GUI Issues
- (b) Network Issues [bandwidth]
- (c) Desktop Issues
- (d) Network congestion
- WAIT TIME-: The amount of time user request waits in the queue for allocating a work process.
- Wait time>50ms or 10% of the response time.
- ¨ Work processes are not sufficient [Increase based on application monitor and available resources]
- ¨ Work processes are processing expensive programs or in the PRIV mode [restrict the processes that are going into PRIV mode by using parameter “rdisp/wppriv_max_no and rdisp/max_priv_time”]
- ¨ Configure the memory parameters
2. ROLL-IN TIME-: The time taken by the work process to roll-in the user context into its task handler.
3. ROLL-OUT TIME-: The time taken by the work process to roll-out the user information into user context before sending the response to the user.
Roll-In time/Roll-Out time >50ms
- Reduce the user authorization, commonly used attributes and parameters.
4. CPU TIME-: The amount of time the work process utilizes the CPU resources while processing the request.
CPU Time >40% [response time – wait time = execution time]
Identify the Expensive ABAP programs in ST03n. If required execute SE30/ST30
for runtime analysis of ABAP programs.
5. PROCESSING TIME-: The time taken to process the user request.
Processing time >2 * CPU time [Twice the time of CPU]
Then consider processing of screens, ABAP and SQL is expensive and tune the ABAP programs, SQL Screens and SQL Statements.
- LOAD AND GENERATION TIME-: The time taken to load and generation the response from the buffer or from the process after fetching the content from database.
LOAD AND GENERATION TIME > 200ms
Processing the response from buffers or load and generating the response from
database is expensive MONITOR ST02.
- RFC/CPIC Time-: It should be as minimal as possible, it is always an overload.
If it is periodical then check the interface/gateway/RFC
connections or the target system resources.
- ENQUEUE TIME-: The time taken by the dialog process to communicate with enque process and obtain a lock on that record.
It is also the time taken by the dialog process to communicate with message server and the message with enque server process when the dialog process is coming from other dialog instances.
ENQUEUE TIME > 5ms on CENTRAL INSTANCE
> 100ms for request that is coming from dialog
instances.
Increase the enque work processes if required. Increase the size of enque table if
required, when the enque lock table overflows.
- DATABASE TIME-: The time taken by the process to reach the database and get the response from database.
DATABASE TIME > 40% EXECUTION TIME
- Consider database buffers are not sufficient [increase buffers]
- Consider resources bottle on the database [check memory and CPU utilization]
- DB indexing issues [check missing indexes in DB02]
- DB statistics are outdated [schedule DB stats job in DB13]
- Db has to be re-organized [Reorganize the DB using Brtools]
- Expensive SQL statements [ST05]
WORK LOAD ANALAYSIS
- Execute ST03n in expert mode and select the duration in days/weeks/months.
- Do not arrive to a conclusion based on daily/weekly data on an instance request.
- It displays the Early watch alert session [EWA], the expensive [programs, transactions, users, processes are displayed in ST03N.
- Time profile specifies the peak hours and off peak hours.
- It also displays the memory user statistics.
- Front end statistics displays the data that is I/O from each terminal.
- Similarly the Spool statistics [similar to SPAD]
Spool statistics-: It displays the number of spool requests, amount of data etc.
Response time distribution specifies the response time comparison with dialog steps [in sec] where average response time is in milliseconds.
ST03N
- It provides daily, weekly and monthly work load overview.
- It displays the top loaded transactions to identify the expensive transactions.
- It displays the time profile along with dialog steps, to define peak and off peak hours.
- Memory user transactions[used to display reports, modules programs and memory consumption by the transactions]
USER AND SETTLEMENT STATISTICS
- It is used to display the list of users along with accessed T-Codes and the number of dialog steps on each transaction.
- It is also used for auditing the users which can specify whether the user has accessed that T-Code a specific day/Week/Month.
FRONT END STATISTICS-:
- It specifies the desktop hostnames along with transferred data that is I/O from each terminal.
BUFFERS-:
- These are used to store the frequently accessed and rarely modified data based on parameter settings in RZ10 and table settings in SE13
- Buffers reside in the memory and completely lost when the instance is restored.
- 3. Buffers contains screens, programs, menus, tables, common user attributes, calendar etc.
- These buffers are organized in the memory in the form of directories. Each directory consumes and space, so buffers are organised by directories and space.
BUFFER MECHANISM-:
- User submits the request.
- The request goes to the database and fetches the content into Application Server.
- The content is checked for its eligibility to store in buffer [RZ10/SE13], if it is eligible to store then it occupies directory along with some space.
- If a relative directory is available then uses the same directory with some space.
- If the directories are not sufficient, the directory overflow occurs and directories are swapped out along with content.
- If the sufficient directories are available and if space is not sufficient then the buffer entries are swapped.
SWAPS-:
The content is swapped if there are no free directories or space based on LRU [Least recently used content]
i.e. the content which is idle and not accessible [based on the time stamp] will be swapped out. It is recorded in ST02.
- The buffer hit ration of SAP R/3 buffer should be more than 98%
ST02 Analysis-:
It displays the following information-:
Click on parameters to display the parameters.
ABAP/Buffer size is used to configure the size for ABAP programs which can be configured up to 1500mb [1.5 GB]
Click on Detail Analysis Profile click on buffering criteriaà to display the parameters and Buffered Objects.
Buffer Hit Ratio = Total number of requests – total DB records
------------------------------------------------------ X 100 [Formula to calculate the Buffer Hit Ratio]
Number of requests
OR
Number of Hits
------------------- X 100
Number of requests
TABLE BUFFERING-:
The SAP tables and their content is buffered in R/3 based on settings in SE13.
By default the following options are provided in SE13.
- No Buffering -:
The tables which are large, transactions are not eligible
for buffering e.g. VBAK etc.
2. Buffering Allowed-:
- Full Buffering-: The tables which are small, frequently accessed and very rarely modified are eligible for full buffering. E.g. T000 (client table)àCalendar
- Single Record Buffering-: The tables which are relatively large, frequently accessed, but very rarely modified are buffered based on single key. E.g. USR02
- Generic Record Buffering-: The tables which are large and more frequently accessed and less frequently modified are eligible to buffer based on certain records. E.g. T001 (company codes)
Buffering allowed but switched off-:
The table buffering is allowed for these tables but it is switched off in DEV and QAS for technical reasons which can be enabled by the customer.
Buffering-:
It improves the response time of the instance by caching the frequently accessed content. When more than one application server (instance) is configured, then the buffering between the instances need to be synchronized else it is possible to get different response from the instance.
rdisp/bufreftime=60 seconds which will synchronize the buffers between instances.
rdisp/bufrefmode= send on, exe auto
The default setting send on, exe auto means that the buffer synchronization is activated.
- Send on means that the change to buffered objects are logged in the table DDLOG
- Exe auto means that the local buffer is bought up to the newest status by cyclical processing of the new DDLOG records.
Send off, exe off deactivates the buffer, synchronization.
- Execute SGEN to compile the program.
- Do not consider the initial response time of the system, Ensure that there are at least 20,000 hits before considering the transaction is expensive. This is important so that you don't put your recommendations on the initial behavior of the system.
Note--> Review the system for couple of days, before making any predictions
E.g. A transaction is executed in 10 mins for the first time
- As the first hit to the database, it consumes more time and subsequent hits will be below 1 second [sometimes few millisec]
- The same transaction is executed for 20,000 times with average response time of 300 milliseconds
600000
--------- Milliseconds for 1step = 30ms
20000
RECOMMENDATIONS-:
- Check the buffer swaps, if they are too high then consider increasing the parameters based in recommendations by SAP [for 32/64 bit and OS]
If the swaps are more then we can consider the following-:
- Support packages are applied.
- System is restored.
- Add-on is applied.
- Users increased due to new module implementation.
- Users are routed to this instance due to failure of other instance.
- New developments or customizing and subsequent transports are imported.
- The buffer space is not sufficient for programs and tables.
You can also run T-code ST04, will discuss about this in the next blog.
Regards
Samarjeet Singh
- SAP Managed Tags:
5 Comments
