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.
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.