How to run SAP SM50/SM66 to monitor SAP work process
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 andOS06
0 Comments