Performance Optimization

Introduction Where to start??? --> Identify the problem, Check the obvious, Create Recommendation List, Apply Recommendations, and Verify the Tuning Results System Check
Transactional Overview
ST02: Buffer Area ST03:Workload Analysis ST04: Database Performance Analysis ST05: Trace Analysis ST06: OS Monitor ST07: Application Monitor DB01: Exclusive Waits DB02: Database Space Statistics SM12: Shared Lock Entries SM13: Update Records SM21: System Log SM50: Work Process Overview ST22: Dumps Analysis

BASIS System Analysis Report Questions/Comments

Where to Start?
Strategy Identifying Performance Problems
Performance Questionnaire

Check the obvious transactions Create a Recommendation List Apply Recommendations Verify the Tuning Results Start to Create a new Recommendation if problem persists

Identify Performance Problem

Ask Consumer Detailed Questions about the Problem Use the Performance Questionnaire if helpful handout Find out the impact ($$$, not able to ship, no invoices printing, etc) Contact Business Liaison and Web page to check if this is the only recording of the problem

Check the Obvious Transactions - SM12

Lock entries are system objects in charge of protecting the integrity of the data by synchronization, so the users cannot modify the same data at the same time Reasons for locks: abnormal termination of gui, inactive gui, and problems in update processing Fields: Client, User, Time, Shared Table (more then one user locked table), and Lock argument (fields used by the lock entry) Use TEST Transaction carefully for extra menu (logging of updates and error resolution). Diagnosis Menu will allow you to test for enqueue problems

Check the Obvious Transactions - SM13

Able to display the system update records with error status or have not yet been processed If there are update errors, you may activate the updates. (Please consult with user before doing so.) Before doing so, activate the updates in test mode.

Check the Obvious Transactions - SM21

4 types of system logs types: Local logs: displays only the logs on the current application server Remote system log: displays logs on a server other than the one you are on All remote system logs: Displays the logs for all the SAP instances which make up the SAP system. Central Logs: difference from the previous option is that a central place collects the log messages by all application servers which have been configured to send their messages Size of system log is defineable in parameter: /rslg/max_diskspace/local and central and is located in /usr/sap/SID/SYS/global In the user field you can put CPIC or SAPSYS to see: CPIC: can display log events which are initiated by SAP instances at the request of other instances SAPSYS: to display messages generated by the background processing system If user id is blank, this indicates system messages such as startup or shutdown logs To download a list of available system log messages, run the ABAP report

Check the Obvious Transactions - SM50/SM66

Check to make sure :
there are available work processes via SAP or OS no work processes are stopped or being hogged by a single user none of the work processes are in PRIV status Priv mode means that a work process has been reserved for a private use in a particular ABAP requiring a large paging area check for no long running ABAPs CPU time on each individual work processes

SM66 will allow you to see the following if configured

memory usage RFC usage reason for waiting process if configured

Check the Obvious Transactions - ST02

Information is displayed only for the system you are logged onto Hit Ratios should be close to 100% for optimal performance Free space is the available space in the buffer. It is a good indicator for correct sizing Swaps occur when an object has to be taken out of the buffer for making room for another object SAP recommends allocating more memory to the buffers rather than distributing it to the database Use current parameters to determine what parameters to increase

Check the Obvious Transactions - ST03

Average response time should fall below 1500 milliseconds (SLA states 2000 milliseconds for dialog) CPU time is the total CPU time needed for completing the SAP process requests. The ratio between the CPU time and the elapsed time should not fall below 5% Average wait time should fall below 100 milliseconds -- high wait times can indicate in sufficient work processes Time per database request measures the performance of the database. Direct reads should not exceed 10 milliseconds and sequential reads should be below 40 milliseconds STAT is located in this transaction; it will allow you to look at a specific transaction statistical data today Compare recent data to see if anything is different from the day before

Check the Obvious Transactions - ST04

Primary focus on overall buffer quality. Should be in high nineties. Sync Buffer Quality should be in nineties Catalog Cache Quality should be in high nineties Package Cache Quality should be in high nineties To improve the parameters review Liwens documentation Any deadlocks which occur should be reported to business to optimize ABAP Number of IO Cleaners and Servers should not be set to the default value of 6 (calculate by number of disks and CPUs) You can review database parameter changes to evaluate performance optimization

Check the Obvious Transactions - ST05

Important tool for analyzing programs with database access problems Be extremely careful of leaving on and filling /usr/sap/SID Make sure of the following: user logged-on once, on the same server as the user, and no background or updates running for this user Monitors only accesses to the database Look for the longest running step in trace

Check the Obvious Transactions - ST06

CPU Utilization is divided into user, system, and idle. These values indicate: User: being consumed by processes such as R/3 work processes or database processes System: Being consumed by the operating system Idle: Not being consumed at all - should be at least 20% If load is greater then 3, consider tuning ABAP or buying faster CPUs Field count indicates the number of processors Load average is the average number of work processes waiting for a free processor and is indicated for the previous 5, 10 and 15 minutes Swap space should be 2-3 times larger then main memory Disk with constant highest response time should be evaluated and information should possibly be redistributed It is possible to do LAN PINGS through ST06

Check the Obvious Transactions - ST07

Allows you to look at load profiles for application modules Much of the information found here is elsewhere but is grouped together for module evaluation Allows one to look at active users by groups (performed transaction the last 30 seconds) Able to look at pretty pie charts for Dialog steps, response time, db time, and cpu time according to application module

Check the Obvious Transactions - ST22

Short dumps are are kept in a special table called SNAP which must be frequently checked to see if it is full of extents Overview Menu will allow you to view via client, user id, system, etc.. Statistics will allow you to see the size of the SNAP table used To delete old SNAP entries, GOTO -> Reorganize

Check the Obvious Transactions - DB01

Exclusive lock waits occur when a user locks a row in a table (i.e. with an update statement) and another is also trying to lock the same row that user has to wait until the first user releases the row Database locks are necessity and should not be regarded as performance problems. To eliminate database locks:
you can kill an external process (outside R/3) if it is holding the lock (be very cautious) Check with the user to see if the program is still working properly Work with the ABAPers to determine if the programs are running parallel locking the row Check if Batch job is running which could be holding the lock

Check the Obvious Transactions - DB02

Can use this transaction to quickly look at table space statistics instead of control center Detailed tracking of containers and tablespaces History of database growth Determine if there are missing indexes

Create a Recommendation List

Make a list of possible recommendations with:

what change is recommended the chance it could be the silver bullet what risk is associated if system needs to be recycled

Give recommendation to Senior Technical Staff/Management

Apply Recommendation

When applying the recommendation, always have a backout plan in case the recommendation backfires If possible, try to eliminate the risk by implementing the change to all development systems before putting into production If a production fix, work with Sue Leach to create a change ticket -- allow ample time

Verify the Tuning Results

Try to quantify the changes you have made. Dont hesitate to start over if the problem persists. Often times the problem is resolved by a bunch of small fixes instead of the silver bullet