Monitoring Hardware Operating System Overview Analyzing CPU and Paging

ST06 SM51 ST06

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%,

goto SM50 & check all DIA (Dialog) with status waitingif ALL are running then you have wait time (problems ! 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

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 tells you the workprocess sequence. ( Ideally 10-15 process with OLTP and batch process scheduled at peak and off peak times respectively) say 8-17 hrs and 17-8 hrs for Batch Process) 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 )

The number of swaps should be low. EXCEPTION: The program buffer will show swaps. Here the general rule is, that you shou

The important points are the hitratio (should be up to 98%) and the 'load & gen.time' in Transaction ST03 (should be less than 1

Buffers set too small. The required data cannot be stored in the buffers. Instead, objects have to be swapped out of the buffers. This causes expensiv

Buffers set too large Memory is wasted. Paging may occur if too much memory is taken from the operating system and allocated to the SAP buffers a

ST02 is the buffer monitor that offers instance specific information that provides: 1. status of different buffers instance wise 2. information on memory usage instance wise 3. information on table buffering at instance level Swapping takes place for two reasons: 1. not enough 'free space left' in buffer for buffering new objects 2. buffer has run ouf of 'free directory entries' that can be contained in one buffer area * * Directory entries diminish the available size of the buffer, independent of their usage. Swaps are to be avoided, as are all other situations leading to lines shown in red in the ST02 display. An example with a more practical outlook to swapping observed: Use transactions SM50, ST03N and ST02 to identify the problem.

a. Using SM50 you might find high number of work processes accessing tables related to ABAP sources and status as 'Load Program'. This hints to a problem w

b. In transaction ST03N, you find unusually high 'load and generation time' causing even higher wait times. Threshold for load a c. In buffer monitor i.e. ST02, you find many swaps typically more than 10000 swaps happening per day for program buffer . Check on

If program buffer is small, it means that workprocesses require to reload program loads over and over again which causes bad s

Resolution: Increase program buffer size/ check on load and generation times/ hit-ratio increases/ system response time also lo

Object swaps Always aim for zero swaps Exception: program buffer. Here some swapping will almost always happen. As mentioned in an earlier reply, 10000/day is the u Free space in buffer

Monitor the buffers regularly with ST02. If the free space % (or the free dir %) falls below 15-20% (exception is again the progra

Note for export/import buffer Make this buffer much bigger (10 times bigger or more) than the default. If this buffer overflows you will see an explosive increas In BI systems do the same for the Exp/Imp SHM buffer.

wait time (problems !) for other users wanting to process transactions .

ral rule is, that you should not observe much more than 10000 swaps per day. If you do not observe that 10000 swaps per day, the situation

3 (should be less than 10ms).

s. This causes expensive database accesses.

ated to the SAP buffers and database.

am'. This hints to a problem with Program PXA buffer.

es. Threshold for load and generation time is typically 50 ms.

rogram buffer . Check on hit ratio value below 95% is typically poor. This indicates problem. Program buffer could be small!!

gain which causes bad system performance.

m response time also lowers down!! : )

eply, 10000/day is the upper limit.

ption is again the program buffer, which will probably have ~0% free), then increase the profile parameter for the buffer size in RZ10. There is

see an explosive increase in the number of swaps (sometimes hunderds of thousands over a short period of time). Also increase the director

0000 swaps per day, the situation is not critical.

uld be small!!

or the buffer size in RZ10. There is normally no need to restart the system immediately, you can wait until the next planned downtime window

of time). Also increase the directory size to a value equal to 30-50% of the buffer size, e.g. rsdb/obj/buffersize = 40000, rsdb/obj/max_object

the next planned downtime window.

size = 40000, rsdb/obj/max_objects = 15000.

Performance problems may be indicated if: The average idle CPU capacity is less than 20% every hour. More than 20% of the physical main memory is paged every hour. Utilization of individual hard disks is more than 50%. Excessive utilization of the hard disks, particularly on the database server, can cause systemwide performance problems. To check whether the high CPU load or the high paging rate significantly damages response times in the R/3 System or the database, use the Workload Monitor (TransactionST03

Nonoptimal Workload Distribution In a distributed system with multiple computers, if you discover a hardware bottleneck on at least one computer, while other computers have unused resources, the workload is probably not optimally distributed. To improve performance, redistribute the R/3 work processes and the user logons. It is extremely important that the database server has enough resources. A CPU or main memory bottleneck on the database server means that the required data cannot be retrieved quickly from the database, which causes poor response times in the entire R/3 System. Individual Processes That Consume Too Much CPU To identify processes that place a heavy load on the CPU, use the OperatingSystem Monitor (TransactionST06) function Top CPU Processes. From theOperating System Monitor initial screen, choose: Detail analysis menu Top CPU processes R/3 work processes are indicated in the columnC ommand bydisp+w ork (Windows NT) ordw _instance (UNIX). Database processes are normally indicated by brand names such as Oracle or Informix that appear in the columns Commandor User name. To check whether individual processes are placing a heavy load on the CPU for long periods of time, refresh the monitor periodically and observe any changes in the value CPU Util [%]. If R/3 work processes are causing high CPU load, open a new user session and call the Local Work Process Overview (TransactionSM50see Analyzing R/3 Work Processes in the present chapter). Using the Operating System Monitor function Top CPU Processes, you can obtain the process ID (indicated as PID) to identify the R/3 work process causing the load. From the Work Process Overview, note the name of the ABAP program and the user corresponding to the PID. If the user confirms that the program is functioning correctly, it may be necessary to consider an in-depth performance analysis for this program