SAP Performance Tuning

SAP Load Balancing and Work Processes Troubleshoot

The benefit of segregating user groups by line-ofbusiness (using logon groups) is related to the
point that groups of users (like SD users or HR
users, for example) tend to use the same sets of
data. They (generally) work with the same groups
of tables and hit the same indexes using the same
programs (transactions).
So, if you can group all of the users hitting the
same tables, onto (or one set of) App server(s),
then you can tune the App server buffers to a much
greater extent. If the FI users (generally) never
hit against the HR tables then the App servers in
the FI group don't (generally) have to buffer any
HR data. That leaves you free to make memory and
buffer adjustments to a more drastic extent,
because you don't have to worry (as much) about
screwing the HR users (as an example), when you're
adjusting the FI server group.
So, (in opinion only) you should start with a
buffer hit ratio analysis / DB table & index access
analysis (by user group) to see where you would get
the best benefit from this kind of setup. If you
don't have this kind of info, then creating logon
groups by line-of-business may have no benefit (or
worst case, may make performance degrade for the
group with the highest load %). You need some
historical information to base your decision on,
for how to best split the users up.

You may find that 50% of the load is from the SD

users and so you may need one group for them (with
3 App servers in it) and one other group for
everyone else (with the other 3).
The logon group(s) will have to be referenced by
SAP GUI, so SAP GUI (or saplogon.ini + maybe the
services file, only) will have to change to
accomodate any new groups you create in SMLG. Also
consider that there's variables for time-of-day
(load varies by time-of-day) and op-mode switches
(resources vary by op-mode).
All Work process are running? What will be our
action?
Are all the work processes
(dia,btc,enq,upd,up2,spo) running or just all the
dialog work processes?
If all the work processes are running, then you may
want to look at SM12 (or is SM13?) and see if
updates are disabled. If they are, look at the
alert log (if it's an Oracle database) and see if
you have any space related errors (e.g. ORA-01653
or ORA-01654). If you do, add a datafile or raw
device file to the applicable tablespace and then,
re-enable updates in SM12.
If only all the dialog work processes are running,
there are several possible causes. First, look to
see if there's a number in the Semaphore column in
SM50 or dpmon. If there is, click once on one of
the numbers in the Semaphore column to select it
and then, press F1 (help) to get a list of
Semaphores. Then, search OSS notes and, hopefully,
you'll find a note that will tell you how to fix
the problem.

If it's not a semaphore (or sometimes if it is),

use vmstat on UNIX or task manager on Windows to
see if the operating system is running short on
memory which would cause it to swap. In vmstat,
the free column (which is in 4k pages on most UNIX
derivatives) will be consistently 5MB or so and the
pi and/or po columns will have a non- zero value.
The %idle column in the cpu or proc section will be
0 or a very low single digit while the sys column
will be a very high double-digit number because the
operating system is having to swap programs out to
disk and in from disk before it can execute them.
In task manager, look at free memory in the
physical memory section under the performance tab.
If it's 10MB or 15MB (I think), then the operating
system will be swapping.
Usually, when all the dialog work processes are
running, you won't be able to log in via SAPgui and
will need to execute the dpmon utility at the
commandline level. The procedure is basically the
same on UNIX and Windows.
On UNIX:
telnet to server and login as sidadm user.
cd to /sapmnt/SID/profile directory
execute "dpmon pf=SID_hostname_SYSNR" (e.g.
PRD_hercules_DVEGMS00) select option "m" and then,
option "l"
On Windows:
Click on START, then RUN
Type "cmd" and press enter
change to drive where profile directory resides
(e.g. f:)
cd to \sapmnt\SID\profile
execute "dpmon pf=SID_hostname_SYSNR" (e.g.

PRD_zeus_DVEGMS00) select option "m" and then,

option "l"
On both operating systems, you'll see a screen that
looks like what you see in SM50. Depending on what
you see here, will depend on what you do next, but
checking the developer trace files (e.g. dev_disp)
in the work directory (e.g.
/usr/sap/SID/DVEGMS00/work) is never a bad idea.

SAP System Performance Issues

My server becomes slow when more users login.

What could be the reason? Is it because of less
hardware resource?
Server configuration is 104GB HDD, 2GB Ram.
OS:Win 2003 server.
Database:Oracle.
I manage SAP R/3 4.6C systems on Risc 6000
machines, under Oracle 9.2.
The overall performance problem for me is to know
if SAP response time is acceptable ; if not, do
this :
- at AIX level : utilities are topas, to catch
what's wrong : Disk I/O ? CPU bottleneck ? Too much
swap ?
- at Oracle level : tkprof but don't know much
about this.
- at SAP level : you can manage SAP memory, Oracle
and OS too.
If SAP response time is acceptable, then try this :

Try to have a look at OS response time : ST06 :

look at CPU, Memory, Swap, Disk and Lan response
time.
Try to have a look at buffer quality : ST02, if
many fields are red, investigate each fields
dependant parameters.
Try to have a look at DB response time : ST04N,
databuffer quality (SGA zone), how much physical
reads / logical reads Ratio, wait times, number of
user calls, Shared Pool cache hit ratio should be
>96%, Sort usage, Redo logging.
I use this kind of procedure to manage my systems.
It depends how much you allocated for SGA (database
buffers, shared pool buffer, redo log buffers), how
much you allocated for SAP buffers esp. Program
buffers and whether the server have any other
external processes/programs running.
How many Dialog Work Processes you allocatedI
think your problem most likely is you dont have
enough of these Dialog processes. Also maybe users
running inefficient reports/programs which are
holding the Dialog processes, goto SM50 & check all
DIA (Dialog) with status waitingif ALL are
running then you have wait time (problems !) for
other users wanting to process transactions .
To troubleshoot performance, you need these tcode
tools:ST04 Database in here, check especially for
Expensive SQLs (Detail Analysis SQL Request)
ST02 SAP buffers

ST06 OS stats
ST05 SQL trace
SE30 Abap runtime analysis
A few step which you can exercise to sort/identify
performance issues.
* ST03, ST02, ST04 are the tcode for workload,
tuning and DB Performance Monitoring codes.
* ST06 FOR Operation System Monitoring.
** SM51 OR SM50 is process overview which
the workprocess sequence. ( Ideally 10-15
with OLTP and batch process scheduled at
off peak times respectively) say 8-17 hrs
hrs for Batch Process)

tells you
process
peak and
and 17-8

Operation Mode can be configured in RZ04 tcode.

** Check for top CPU in ST06 tcode. CPU should not
exceed more than 60% for long time for any process.
** Based of No. of instances ( Application
Servers ) should have adequately sized.
** Most resources intensive process have to be
scheduled in Batch Process ( in Background in Non
Peak Hours )
** Look for unnecessary Jobs Active During Prime
Time
** Look for Parameters Set To Your Business
Process.
( RZ10, RZ11 ) Check Snote:0124361
** Refer Early Watch Alert Periodically for Overall
System Performance.. ( Tcode SDCC )