This post would talk about how to run SAP SM50 and SM66 transaction, understand information from SAP SM50 and SM66 screens and what SAP SM50 and SAP SM66 can help in performance monitoring and analysis.
SAP work process is a limited critical system resource for performance like CPU and memory. Number of work processes and type of work processes on a SAP instance are controlled via SAP basis configuration. Any online transaction or background job is executed using one or multiple SAP work processes in sequence or in parallel dependent on program function and design: Running SAP transaction VA03 online to display sale order would need only one SAP dialog work process while running va01 online to create sales order online would need one dialog process and one update process; One background job would always use at least one background process. One background job which uses parallel processes via RFC call would need one or more dialog process as well.
SAP SM50 and SM66 transaction provides capabilities to monitor overall status of SAP work process and status of individual SAP work process. So you know:
1. Overall system activities/load.
2. System work process status.
3. Individual job or online transaction execution status.
4. Memory/CPU usage of individual job or transaction.
SAP SM50 transaction is used to report information for all configured SAP work processes under one SAP server/instance while SAP SM66 reports all occupied SAP work processes from all servers/instances of a SAP system. If you have several servers/instances in your system, you can use SAP transaction SM51 to switch from one server to another.
SAP SM50 transaction has two screens: Work “Process Overview” and “Details Display” screen. I would walk through SAP transaction SM50 first before I talk about SAP transaction SM66.
1. Launch wok process monitor
To launch work process monitor, you can run SAP transaction SM50 directly or via menu path Tools -> Administration -> Monitor ->System Monitoring -> Process Overview. The initial SAP SM50 transaction screen is a SAP work “Process Overview” screen which shows status of all configured sap work processes on the current server you are in. Double click any work process entry on the overview screen, you would see “Details Display” screen for single selected work process. That is simple.
Following is a part of SAP SM50 Work process overview screen which is showing status of all configured SAP work processes � I manipulated the display to show all typical types of work process in an application instance � Background(BGD), Dialog(DIA), Update(UPD & UP2).
Figure 1-SM50 Process Overview
Following is two parts of Work process details screen which shows further information on a single work process
�
Figure 2 – SAP SM50 Process Details
�
Click button to refresh overview screen or details display screen to see latest status.
�
2. Understand SAP “Process Overview Screen”
2.1 SAP SM50 overview screen column explanation
You can get the on-line SAP explanation of any column presented in transaction SM50 overview screen: place the cursor over the column and press F1 help. I copied them here for the convenience and with comment in blue color from my experiences.
Column
|
Explanation
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
No.
|
SAP work process number is a running number starting at 0.
In old version, the cap for number of work process in an instance is “99″. With more advanced hardware, the new version can allow up to 999. Number of work processes can be configured depend on memory, number of CPU, type of CPU etc.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Type
|
Work process type
DIA – Work process for executing dialog steps in user transactions��
UPD – Update process for executing update requests
ENQ – Process for executing enqueue requests
BTC – Process for executing batch requests
SPO – Process for executing spool requests
UP2 – Process for executing V2 update requests
�
What work process type is available on an instance/server is configurable based on business requirement. But ENQ/SPO process is normally on CI instance.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
PID
|
Process ID of operating system for the SAP work process. With this ID the process can be processed using commands from the operating system (for example, ps or kill in UNIX).
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Status
|
This field indicates the current status of a work process.
Waiting :��Process is waiting for requests
Running :��Process is processing a request
On Hold :��Process is waiting for a message. Column Reason specifies what the work process is waiting for.
Stopped :��Process was terminated because of an error
Shutdown: Process shut down
Reserviert: Process is reserved
�
A process in “Waiting” is an idle/free process. An On-hold process needs to be reviewed with information from the “Reason” column to understand the cause for “on-hold”. “BGD” process would be put in “on-hold” during period of waiting for completion of RFC call or when program is executing “WAIT” or “SLEEP” ABAP statement � “DIA” process would be rolled out under those situations. “DIA” process can be in “on-hold” status during RFC “initiation stage” and data sending/receiving phase which is “normally” brief � means when you refresh the display again, status would be changed to others, if not, it might be indicate a network issue or big size of data. A work process in “Running” status means the program is executing an ABAP/SQL statement.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Reason
|
This field gives the reason why a work process has the status “On hold”.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Start
|
Restart work process after dump?
Indicates whether the terminated work process should be automatically restarted in by the dispatcher. The following values are possible:
Yes : The work process is restarted
No��: The work process is not restarted (for example, if errors occur during the initialization phase).
You can set the work process by choosing Process -> Restart After Error -> Yes or No.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Err
|
Restart work process after dump?
Indicates whether the terminated work process should be automatically restarted in by the dispatcher. The following values are possible:
Yes : The work process is restarted
No��: The work process is not restarted (for example, if errors occur during the initialization phase).
You can set the work process by choosing Process -> Restart After Error -> Yes or No.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sem
|
Semaphore that the work process is waiting for
SAP number of the semaphore which blocks the work process:
If the field is green, the work process is holding the semaphore in question.
If the field is red, the work process waits for the semaphore in question.
The numbers stand for the following semaphores:
��1: PXA semaphore
��2: WP_CA_ADM semaphore ��3: APPC_CA_ADM semaphore ��4: TM_ADM semaphore ��5: COMM_ADM semaphore ��6: ROLL_ADM semaphore ��7: PAGING semaphore ��8: NO_BUFFER semaphore ��9: STAT semaphore 10: GW Request semaphore 11: CALI_BUFFER semaphore 12: TEMSE Char Code semaphore 13: Update-ADM semaphore 14: PRES_BUF semaphore 15: SHM_ADM_AREA semaphore 16: DB_TBUFF semaphore 17: DB_SYNC semaphore 18: DB_TTAB semaphore 19: DB_SNTAB semaphore 20: DB_IREC semaphore 21: DB_FTAB semaphore 22: LOGFILE semaphore 23: REQ_QUEUE semaphore 24: DB_TBUFF_P semaphore 25: ENQ_REQ semaphore 26: ENQ-TABLE semaphore 27: SAPCOMM_1 semaphore 28: SAPCOMM_2 semaphore 29: FIXADR semaphore 30: DB_CUA_BUFFER semaphore 31: Spool-ADM semaphore 32: Extended memory ADM semaphore 33: Extended segments semaphore 34: Server buffer semaphore 35: Object buffer semaphore 36: Extended segments user list semaphore 37: Global mutex semaphore 38: CCMS monitoring semaphore 39: Extended global memory semaphore 40: Semaphore reserved for testing 41: Semaphore reserved for testing 42: Shared statistic semaphore 43: Spool cache semaphore 44: Basis udit Semaphore 45: Application Statistic Buffer semaphore 46: Profile Parameter semaphore 47: Spool asynchronous RFC semaphore 48: ENQID semaphore 49: ABAP Virtual Machine Instruction Trace semaphore 50: Task handler runtime semaphore 51: ATRA semaphore 52: Memory pipes semaphore 53: Coverage Analyzer semaphore 54: ABAP Time Synchronization semaphore 55: Online Text Repository semaphore 56: ESM (Export to Shared Memory)- Semaphore 57: Runtime Monitor 58: JAVA 59: ABAP Shared Objects
60: JControl adminstration semaphore
61: JControl session semaphore
62: ITS plugin – update statistics 63: ITS plugin – service description
64: VM container lite cluster semaphore
65: Extended segments administration semaphore 66: VM Container adminstration semaphore 67: Extended memory adminstration semaphore
68: CCMS monitoring semaphore
69: Session breakpoint administration of ABAP debugger 70: Extended global memory adminstration semaphore
73: ABAP Hotspot Trace
�
I seldom observed a work process waiting for a semaphore.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CPU
|
CPU time
This is an accumulated CPU time consumed by all jobs and transactions executed under this process.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Time
|
Indicates the elapsed clock time used by a work process for the dialog step that is currently processing.
This time is reset with each commit statement or each screen change in online mode(Dialog step/transaction step)
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Report
|
The report name that is currently being executed by the work process.
Exception: If the report name starts with ‘<’ and ends with ‘>’, then the work process does not execute an ABAP program but a kernel action. The following values are possible:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Action
|
Description of the action that the work process is currently executing
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Table
|
Table that was most recently accessed by the kernel
|
�
On the overview screen, there are several buttons to allow you to control the display like sort, filter etc.
2.3 What performance work can be done in SAP SM50 overview screen
2.3.1 CHECK OVERALL STATUS OF SAP WORK PROCESS
2.3.1.1 Check availability of free work process
If all work processes of a specific work process type are occupied, then the instance/system has no ability to handle new request which needs that type of work process � When all dialog work process are occupied, then online request would not be serviced immediately but put into a queue � in worst case, the queue can be full � online user would experience very slow response from the system. When all background processes are occupied, then no new job can be started. If all updating processes are occupied, standard SAP transactions would not able to save any new changes to database anymore. So it is critical to check that there are “free” work processes available or there is no risk to run out of SAP work processes.
If all processes are occupied, this can be several reasons � database locks (DB01) or too few work processes are configured or high degree of parallelism due to improper execution of a transaction or extremely high volume. This could be a workload balance issue as well. If all updating work processes are occupied, then you need to check whether system “update” service was deactivated via SAP transaction SM13. In my experiences, I have seen cases of all updating process were occupied due to deactivated system “updating service” (due to full of table space) or “database lock” etc. You can check system log via SM21 or database monitor ST04 to understand why update service was deactivated.
All dialog or background processes can be occupied due to bad code and high degree of parallelism execution of that “bad” code. When program code is bad, it would take longer to complete. If it is one process, it might be ok. However when this bad code is executed in parallel process with high degree of parallelism and volume, this could be an issue. If a specific type of process is often seen in “contention” and there is no application design issue, it can indicate that more dialog processes are needed. More work process can be added if there is enough system resources. For example, if CPU is already overloaded, there is no point to add more work processes. You need to bring capacity first or reducing the load first � this is a separate topic.
2.3.1.2 Check sign of memory contention
If significant number of dialog processes are “on-hold” status with a reason “Private” or displays “Roll-in” or “Roll-out” under Action column for some time in SM50 overview screen , this can indicated memory contention. Memory contention can be checked via SAP transaction ST02 which shows allocated SAP memory and free memory. Watch out shortage in extended memory space.
2.3.2 VERIFY LONG RUNNING PROCESS
Long running process showed in SM50 overview screen might be stuck, blocked or running normally. Stuck process needed to be cancelled so the work process can be free for other tasks. Blocked process might be due to lock contention which should be investigated further. Long running due to inappropriate design/code can be tuned so it can run faster and using less resource.
As a quick note, a work process is not stuck if there are changes in CPU time and/or Database operation within its’ normal runtime. You can refer to my separate post – “Is my job hang” for more details on how to reach a decision on whether a business process is hanged or not.
I suggested that we pay special attention to long running updating process as well since
- Number of updating process is small comparing dialog or background processes.
- Updating process is normally running short. It is unusual for an updating process to run over 1 minute.
- Lock would only be released after updating is completed. Long update is normally related to “big update” which can split into smaller update units to achieve better concurrency.
2.3.3 DEBUG WORK PROCESS
From SAP SM50, a work process can be debugged which can give you more information especially when program is executing ABAP logic showing nothing under “action” column. Using Debug, you can check internal table size which is not provided by other tools. This can help you to understand why a program is spent a long time on an internal table handling or looping or why program/job is using so much memory.
Debug option is under SM50 overview screen menu option�
To debug the process, you just need to click once on the entry, then go to menu option to launch “Debugging”. If you exit the debug, the process would execute it as normal.
You can use the debug only when program/process is not stuck on a “SQL” statement. Anyway, There is no need to debug a SQL statements. SQL statements can be verified in database session monitor(ST04).
2.3. 4 ADMIN WORK PROCESS
SAP SM50 provides options for you to admin work process like terminating a process or restart a work process etc.
There were times that a stuck process could not be cancelled via SAP transaction SM50 or even could not be terminated at Operating system level due to kernel issue. In rare case, a stuck process would be gone after system reboots.
2.3.5 OTHERS
From SAP SM50 overview screen, you can do other checks like- get user information, filter display based on user-id etc and review work process developer trace log.
Depends on your version or patch level, your SAP SM50 transaction might provide an straightforward overview showing total, what is in used and what is available like below and different layout on menu options
�
�
3 Understand SAP SM50 details display screen
3.1 SAP details display screen explanation
Details Display screen (please refer to above figure-2 for sample screens) is to show details information on one SAP work process at one time. Information in details screen is organized into several sections as showed below:
Section/field
|
Explanation
|
Overview of the work process
|
Same as overview screen- but it is showing exact CPU time here.
|
Report/spool action
|
This could be a report/program called by the main program
|
Main program
|
This could be program/transaction which user enters online or specify in job definition. It is if there is no RFC call initiated in the main program.
|
Database
|
Dynamic data statistics on database operation for current step like snapshot of # of row direct read, sequential read etc, Refresh the display to see new status.
|
Memory
|
Dynamic Memory for current transaction step.
|
Environment
|
Time used by system level operation related to the program.
|
�
3.2 What performance work can be done from SAP SM50 details screen
3.2.1 CHECK STATUS OF INDIVIDUAL BUSINESS PROCESS
You can check whether the process is stuck by checking whether there is a change on CPU time or number of direct read, sequential read, insert etc by refreshing the screen.
3.2.2 CHECK MEMORY/CPU USAGE
You can refresh SAP SM50 details screen again and review memory change situation to get a clear picture on how memory usage is changed over a course of program. Personally, I prefer to use SAP transaction /sdf/mon to monitor memory usage automatically, this avoids sitting in front of computer and refresh screen manually again and again.
SAP transaction STAD is showing memory usage as well however the memory usage showed in STAD is the memory picture at end of program � I have seen the cases that STAD reported a much lower memory usage than what I saw in SM50 during monitoring of a process execution.
SM50 can tell you whether the program or process is spending most of time on application server side or on database server side by monitoring the execution and refreshing the SM50 display screen. However this approach is really manual and inaccurate. The best way to check this is to use STAD to check this after program/process finishes. STAD would has runtime distribution information where � CPU time is the CPU time spent by a transaction on application server CPU side and database time is the time spend on database server side. Please click here for more information on how to run STAD.
4. SAP global work process monitor SM66.
At this step, you should be familiar with SM50 already. With SM50 knowledge, it is easier to understand SAP SM66 � global active process monitor. The main difference between SM66 and SM50 is that SM66 show only those “engaged” work processes but from all instances/servers of a SAP system while SM50 report all work processes but only from one instance/server of a SAP system . In my version of SAP system, Work process “on-hold” status in SM50 is mapped to “STOPPED” status in SM66. In another word, SM66 would show no process under “on-hold” status but instead “Stopped” status. It would not show details information you can see in SM50 for each entry.
However, it would give a clear snap-shot on what is running in the system in one click. SM66 provide a button in display screen to allow you control display via following options:
SM66 display can be sorted according to your need � like runtime, process type, table name etc..
From SM66 display screen, you can admin existing work process and start debugging as well.
5. Further clarification
SAP transactions are always subject to changes. Your SM50/SM66 display, layout might be different from what is showed here but Usage of SM50 and SM66 should be the same.
The process ID showed in SM50 and SM66 is the key for linking to database load session monitor(ST04 ) and CPU load monitor (OS06/OS07/ST06). This is useful when information from SM50/SM66 is not enough and you need further information like what provided by ST04 and OS06.