SAP ABAP System Performance troubleshooting steps.
In this blog will provide you on in detailed information like , where do you check and what are transation codes which we have to on system performance issues.
SAP ABAP System performance issues identified and will categorized into below three aspects.
System- wide performance . System wide issue can impacted all the business users.
We have to check the below points to analaysis the System wide performance issues.
Work load analysis can check the Tx : ST03/ST03N --> here we can see avareage responstime , load time, cpu time, wait time and also get the all instances data on task wise programmes , jobs , DIALOG type.
The following are important analysis views in transaction ST03:
Possible Causes of Bad Response Times
Average time 10 % of the average response time or 50 MS
If more than the values, we have to check the below areas to identify the issues.
Transaction code SM66 is used to quickly investigate the potential cause of a system performance problem by checking the work process load. You can also use transaction code SM50 to see just work process load for the current application server you are logged into. You can use the global work process overview to:
Using the Global Work Process Overview screen, you can see at a glance:
Work process are long running , we must check the below areas .
Programmer issues
transactions are executing long running
any updates are failed
any buffer issues .
LOAD TIME > 50 ms
If the program buffer, CUA buffer, or screen buffer is too small, there will be an increase in average load time. In SAP memory configuration monitor (ST02/ST02N), if there are swaps in program buffer, CUA buffer, and screen buffer as shown in the following figure, it indicates that the buffer needs to be enlarged. The goal for a smooth-running system is to have no swaps in all Buffers except for the Program Buffer. The Program Buffer, in general, should not have more than 10,000 Swaps per day. It helps to keep in mind when the system was last restarted.
A method to resolve Swaps is to ensure that there is enough space is each Corresponding Buffer. Increase the size of the Buffers in 20% increments until the Swaps have stabilized. Please schedule a restart of the system to see effects.
In the below screenshots to see more than 10,000 swaps.
Roll in or Roll out time.
There are three types of memory under the SAP scope and they are Roll Memory, Extended Memory, and Heap Memory. Dialog work processes will use up memory in this order: Roll Memory, Extended Memory, Heap Memory. Non-Dialog work processes will consume memory in this order: Roll Memory, Heap Memory, Extended Memory.
It is important to have enough extended memory, if there isn't, SAP Work Processes would get memory from Heap Area based on SAP allocation sequence for dialog tasks. Once a Dialog is using Heap Memory, the SAP Dialog Process goes into Private Mode (PRIV mode), which means it that is reserved memory and cannot be shared.
If extended memory or roll buffer is full, the roll-in or roll-out times may increase. The maximum used should be lower than 80% of the configured memory for extended memory.
Single Transation performance issue.
In the work load monitoring we can analysis which transation code taking high response time , based on the values we can check the perticulr transtaion code details.
Data base time > 40 % response time .
CPU Time > 40 % respone time.
Roll wait time > 200 milseonds.
If we could see any transation consume high avarage response time , we have to go STAD records and analssis the issue.
In the STAD records if we could see more values based on user and response time, we have to investiage what could be the issue on perticular transation code or does any sql staement causing the issue , any process consuming more CPU time.
SAP Background job performance issue. If any case multipile jobs are long running in peak hours, that could be cuasing potential bottleneck of the SAP system.
In that case what are jobs are long running and we can identifify the jobs and inform to the Funcational/Technical team to investiaget the programme/Varient issues.
And also check the sufficient background jobs avaliable in the system or not ? if not we can increase the BTC workprocess as per business need and based on hardware configuraiton in the system.
I hope this blog will help you to investiage basic SAP ABAP system performance analysis.
In this blog will provide you on in detailed information like , where do you check and what are transation codes which we have to on system performance issues.
SAP ABAP System performance issues identified and will categorized into below three aspects.
- System- wide performance
- Single Transation code performance
- Background Jobs performance
System- wide performance . System wide issue can impacted all the business users.
We have to check the below points to analaysis the System wide performance issues.
Checking Points | Explanation |
| Workload Statistics, System Response Time | Identify the distribution of system response time,find the bottleneck |
| Work Processes Performance | Analyzing the running status of work processes |
| SAP Memory and Buffers | Checking Memory and buffers usage,configuration |
| RFC Performance | Determine the source of high RFC time |
Work load analysis can check the Tx : ST03/ST03N --> here we can see avareage responstime , load time, cpu time, wait time and also get the all instances data on task wise programmes , jobs , DIALOG type.
The following are important analysis views in transaction ST03:
- System load overview: general response time distribution across different task types
- Time profile: How does the response time react over the day? Are there peak times with bad response times?
- Transaction profile: Can you observe response time problems in general or only in certain transactions?
Possible Causes of Bad Response Times
| Reasons | Possible Causes |
| DB request (Change/Comm.) | Problems with database or index DB02 - Missing indexes ST05 – Trace the particular SQL statement ST04 – DB Buffer cache Quality should be more than 95 % . |
| Load time | ST02/ST02N – check the Program buffer , screen buffer , CUA buffer . Swaps should not more than 10,000 . If more than the value , we must check the size the table and increase the buffer memory values. And check the system last restart, if in case system last restart happened two or three months back we should restart it to improve the system buffers. |
| Wait time | Insufficient work processes Inactive update Incorrect operation mode Locked tasks Long-running transactions |
| CPU Time | Check the OS level if any process consumes more CPU’s and also check ST06 Virtual memory Physical memory CPU File system administration Physical disk. |
Enqueue time | 5 ms |
Average time 10 % of the average response time or 50 MS
If more than the values, we have to check the below areas to identify the issues.
Transaction code SM66 is used to quickly investigate the potential cause of a system performance problem by checking the work process load. You can also use transaction code SM50 to see just work process load for the current application server you are logged into. You can use the global work process overview to:
- Monitor the work process load on all active instances across the system
- Identify locks in the database (lock waits).
SM66
Using the Global Work Process Overview screen, you can see at a glance:
- The status of each application server
• The reason why it is not running
• Whether it has been restarted
• The CPU and request run time
• The user who has logged on and the client that they logged on to
• The report that is running.
Work process are long running , we must check the below areas .
Programmer issues
transactions are executing long running
any updates are failed
any buffer issues .
LOAD TIME > 50 ms
If the program buffer, CUA buffer, or screen buffer is too small, there will be an increase in average load time. In SAP memory configuration monitor (ST02/ST02N), if there are swaps in program buffer, CUA buffer, and screen buffer as shown in the following figure, it indicates that the buffer needs to be enlarged. The goal for a smooth-running system is to have no swaps in all Buffers except for the Program Buffer. The Program Buffer, in general, should not have more than 10,000 Swaps per day. It helps to keep in mind when the system was last restarted.
A method to resolve Swaps is to ensure that there is enough space is each Corresponding Buffer. Increase the size of the Buffers in 20% increments until the Swaps have stabilized. Please schedule a restart of the system to see effects.
In the below screenshots to see more than 10,000 swaps.
Roll in or Roll out time.
There are three types of memory under the SAP scope and they are Roll Memory, Extended Memory, and Heap Memory. Dialog work processes will use up memory in this order: Roll Memory, Extended Memory, Heap Memory. Non-Dialog work processes will consume memory in this order: Roll Memory, Heap Memory, Extended Memory.
It is important to have enough extended memory, if there isn't, SAP Work Processes would get memory from Heap Area based on SAP allocation sequence for dialog tasks. Once a Dialog is using Heap Memory, the SAP Dialog Process goes into Private Mode (PRIV mode), which means it that is reserved memory and cannot be shared.
If extended memory or roll buffer is full, the roll-in or roll-out times may increase. The maximum used should be lower than 80% of the configured memory for extended memory.
Single Transation performance issue.
In the work load monitoring we can analysis which transation code taking high response time , based on the values we can check the perticulr transtaion code details.
Data base time > 40 % response time .
CPU Time > 40 % respone time.
Roll wait time > 200 milseonds.
If we could see any transation consume high avarage response time , we have to go STAD records and analssis the issue.
In the STAD records if we could see more values based on user and response time, we have to investiage what could be the issue on perticular transation code or does any sql staement causing the issue , any process consuming more CPU time.
SAP Background job performance issue. If any case multipile jobs are long running in peak hours, that could be cuasing potential bottleneck of the SAP system.
In that case what are jobs are long running and we can identifify the jobs and inform to the Funcational/Technical team to investiaget the programme/Varient issues.
And also check the sufficient background jobs avaliable in the system or not ? if not we can increase the BTC workprocess as per business need and based on hardware configuraiton in the system.
I hope this blog will help you to investiage basic SAP ABAP system performance analysis.
- SAP Managed Tags:
2 Comments
