Skip to Content

SCM single server sizing rule of thumb

 

Some organisations choose to run SCM on 1 host, sometimes with additional application servers with the thought I/O and performance will be good, another reason is also that SCM seems to be the poor relative of the typically larger ERP systems.

 

Here are some key things to consider when you have performance issues or want to see that the system is correctly sized.

 

Livecache            – cache_size – you can determine this by running report /SAPAPO/OM_LVC_OBJECTS in a productive system (run in QA first to get an estimate of runtime

SAP                        – the usual, main ones being ztta/roll_extension, abap/heap_area_total, em/initial_size_MB

SAP’s DB              – for eg. Oracle DB_CACHE_SIZE, PGA_AGGREGATE_TARGET, SGA_MAX_SIZE

 

Now add these values up… If you are above what you have physically in the box at some point you will run into trouble. What we normally want to see is these main values (plus LC’s PGA equivalent) adding up to below the physical RAM in the server.

 

An example:

1 Server 100Gb RAM

                /SAPAPO/OM_LVC_OBJECTS outputs 25 Gb      

The SAP DB (e.g. oracle) shows good performance with allocation of 20 Gb

The OS required memory – don’t forget this! – I would give 5 Gb if 2 Gb was minimum recommended and 100Gb was total. (if you have less RAM you can proportion it appropriately)

SAP should taking almost all of the rest of the RAM in this case 50 Gb

 

Disk configuration is equally important and ensuring the redo’s or logs for Livecache and the SAP database are efficiently balanced and if possible don’t all end up trying to go via the same IO channel during intensive ops.

 

Points to note:

Over allocation of RAM in SCM would typically not display due to a typical CIF transfer would run in non-productive hours. Looking at averages would not show problem areas as for the majority of the time an SCM server runs with a relatively low workload with a short spike or peak in activity during transfer or an intensive schedule.

Livecache is a database just like SQL or Oracle. It can be tuned and changed in similar methods and the same considerations should be taken when sizing Livecache. For example redo or logfile: this would see high I/O like a redo log. If the log of Livecache, Database of Livecache, system database and executables are all on the same SAN special car needs to be taken because the SAN controllers will have to deal with a lot of operations at once.

If during your calculations Livecache and the SAP db require a lot or nearly all of the servers memory and SAP ends up with less than 20% RAM you probably need to start to consider application servers.

 

BIG point to remember – don’t size the system and forget about Livecache – it is a living database! Imagine installing ERP on a server and then installing its DB without any memory allotted. Livecache is in a lot of cases the core of SCM.

To report this post you need to login first.

2 Comments

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

    1. Anonymous
      Thanks for the comment Shivaji,

      It’s not meant as a definitive sizing guide. In fact I believe T-Shirt sizing even from SAP is very vague due to Livecache uses being so varied (this is how the report mentioned becomes useful).

      I have seen a few setups where all is on one server node then additional application servers where added (R3 style approach) where in fact for a high powered SCM scenario I would be more inclined to recommend a standalone DB, standalone LC and CI all distributed with even as far to separate ERS (although my preference is to keep ERS and CI together). If you need some guidance on sizing an existing system start with the report and work backwards.

      If you like I am happy to discuss optimal configuration for an SCM instance. (This was more ‘SCM on a budjet’ and how not to make huge mistakes).

      Thanks again
          Mike

      (0) 

Leave a Reply