This blog will give some first aid kit tips on performance issues on ABAP stack reported by end users. The system is up and running, but still user(s) complain about performance. What to do first?
Basically the first analysis always starts with SM50 (or when you have multiple application servers SM66).
Checklist for SM50:
- Are all the DIA dialog processes full or almost full? –> if yes, then performance as total system will be slow. Check to find source for having so much DIA’s active.
- Are all the BTC dialog background processes full? –> if yes, then all other batches will wait.
- Are the UPD processes full? –> if yes, then all the other updates have to wait.
- Are the SPO processes full –> if yes, then all prints have to wait.
Now you have a first impression of the state of the system.
Asking the user the right questions
Go back to the user complaint and start to ask questions:
- Is he the only user complaining? Or are multiple users complaining?
- Is the complaint about online or background job? Users can complain like ‘system performance is slow, since my background job takes a long time to start’
- Is the complaint for updating or querying?
- Is the complaint about printing?
- Is the complaint about about performance in general or a specific transaction?
- Is the complaint running now, or was it in the past?
If possible ask the user to start the poor performing transaction now so you can monitor it in SM50.
Too little dialog processes
If you cannot quickly locate the source of the process that is causing to consume all the dialog processes, you best temporarily increase the amount of DIA processes in the operation modes in RZ04.
Background processes full
Check to find the source of the large amount of background processes. If still too few, you can temporarily increase the amount of DIA processes in the operation modes in RZ04.
Another option is to check if some jobs can be stopped and planned at a later time.
Update processes full
If the update processes are full, check if the update process is running correctly in SM13.
If no prints are coming out of the system, there might be an issue with spool number range. System can look like this:
OSS note 48284 – System cannot generate any more spool requests contains the workprocedure.
Another solution can be to delete old spools.
If there are too many prints and too little spool processes, increase the amount of SPO processes in RZ04.
Use transactions ST02 and AL12 to check for buffering issues. Read more about SAP buffering in this blog.
SAP survival guide for performance issues: SAP note 2442365 – Survival Guide for performance analysis on SAP system contains an excellent PDF attachment for analyzing performance issues.