Skip to Content

Performance tuning is a process to be done over time; it’s not something that you should tackle knee jerk regardless of what you may initially see.

Certainly after a change like an upgrade or enhancement pack implementation, or an influx of new users (or uses) then the system buffers need to be managed in a gradual manner.

The aim of course of buffer tuning is NOT to swap. Swapping for the uninitiated is extremely bad for performance, by seeking data from memory is much more efficient then trying to get data from disk… although over the years I/O with disk access is improving but not as good as physical cached memory.

Tuning is so easy to do, but so easy to get wrong.  There is an English idiom called “Steal from Peter to pay Paul” and with system tuning this is evident. You can increase a memory parameter considerable, which then impacts the overall memory resource. Worse case you may find a system that wasn’t paging now pages…

There are two thoughts (arguments!) with tuning:

1.       Big Bang approach – You review transaction ST02, and where you see excessive swaps i.e. more than 1,000 then you increase the appropriate buffer massively e.g.  Treble it. You do this for ALL of the relevant buffers…

2.       Gradually and over time – You review transaction ST02, and then increase the buffers in small chunks or steps; my analogy is like climbing a large staircase….

My personal choice is 2. A nice gradual change in smaller chunks… of course downtime especially on a Productive environment isn’t always readily available, especially with the amount of HA 24×7 systems, but where possible I believe this should be done…. (I know this is controversial!).

As part of your regular system housekeeping checks then system buffers needs to be checked.  This should be done before and after month / year end; and during the periods before and after a known heavy system usage activity. I’ve seen occasions where after an installation for the first few weeks it doesn’t swap, then the users engage with the system and become familiar – with the system starting to swap when they try to stretch the searching capabilities to the max!

Use the history feature in ST02, and even see what objects are being cached and if you have opportunity speak to the relevant systems users to see what they are doing and if this is a regular or one off activity… its all there so get looking!

Also remember that it takes time to populate buffers, they don’t just cache automatically. So after a system restart it can take a few days in order to really see the issues.

De-tuning a system is always an option – maybe if in ST04 you are seeing excessive swapping (different for UNIX or Windows) but in my experience I haven’t seen much of that.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. John Appleby
    I think on a system that has been setup right in the first place then what you describe is the right way to do things, because small changes are required and those can be quietly tuned during whatever maintenance period is available.

    However what I see oh so often is that the basis team wasn’t bothered to tune the buffers during UAT and therefore didn’t put best practice into the productive environment before Go Live. Therefore after the system is live, performance degrades. In this instance, I believe it is appropriate to increase buffers significantly in order to do what is right for the business and make the system fast. They can always be detuned later. Plus in modern systems, RAM is dirt cheap.

    Also I don’t think that buffer swaps are always bad. For example in BW we don’t care too much about buffer swaps because we’d rather have the RAM being used elsewhere.

    (0) 
    1. Jeff Forshaw Post author
      Hi John, yes I see your point – as we know BW and other non-ECC systems should be tuned different to an ECC system e.g. abap buffersize isn’t much of a consideration in BW, but for ECC systems in my experience tuning is more a consideration otherwise poor performance may occur.
      Regardless something that needs to be monitored regualrly.
      (0) 
      1. John Appleby
        Yes for sure – on any transactional system, buffer performance makes the difference between misery and

        What surprises me is how big an ABAP buffer for example CRM & ERP now require. CRM 7.0 needs a buffer of 1-1.2Gb for normal operation, and ERP 6.0 with ESS/MSS enabled needs nearly 1Gb.

        Gone are the days where you can get away with the SAP default of 300Mb!

        (0) 

Leave a Reply