SAP Basis Tech Supports

Symptom

The settings for liveCache parameters in Versions 7.5, 7.6 or 7.7 are not optimal.

Other terms

OMS_HEAP_COUNT, OMS_HEAP_LIMIT, MAXCPU, LOAD_BALANCING_CHK, LOG_IO_QUEUE, MP_RGN_LOOP, LOG_QUEUE_COUNT, SHAREDSQL, MAXLOCKS, MaxCPUs, OmsMaxHeapSize, OmsSubHeaps, LoadBalancingCheckLevel, MaxExclusiveLockCollisionLoops, LogQueueSize,LogQueues,MaxSQLLocks,
UseSharedSQL

Reason and Prerequisites

When a new liveCache version is delivered, the recommended value of a parameter has changed or a new parameter has been imported that must be set explicitly.
For the release of a certain liveCache version, see the Product Availability Matrix (PAM).

Solution

This note provides an overview of parameter values that have changed with the new liveCache versions. After you import a new liveCache version, check the parameter values listed in the table below. To determine or change the current parameter value, proceed as follows:
Determine the current value of a parameter:
dbmcli -d -n -u dbm_user, > param_getvalue Chang a parameter value:
dbmcli -d -n -u dbm_user, > param_startsession
> param_put
> param_checkall
> param_commitsession

You can also use transaction LC10 or the Database Manager GUI to change the parameters.
New parameter values only become valid after you restart the OFFLINE version of the liveCache instance.
Using the liveCache version and the operating system in use, determine the parameter values necessary for your liveCache from the following table. Also refer to the specified notes, which contain further information.
The parameter names were renamed with liveCache Version 7.7.03. You can continue to use the old name of a parameter and this is stored in the file cserv.pcf under DEPRECATEDID. In each case, the new parameter name is specified after the name that was previously used and is in brackets. The MaxDB documentation contains a list of the old and new parameter names under http://maxdb.sap.com/doc/7_7/44/bd1ec6a5d51388e10000000a155369/frameset.htm

LOAD_BALANCING_CHK (LoadBalancingCheckLevel)

With the help of load balancing, user tasks can change the UKT (user kernel thread). This allows the liveCache instance to optimize the use of the processors that are available to the liveCache instance in accordance with the parameter MAXCPU. See Note 695721.
Recommended: 0 Generally on Windows 32-bit
lower than 7.7.00 Build 18 (all platforms) or
lower than 7.5.00 Build 18 (all platforms) or
15 lower than 7.5.00 Build 35 and 7.5.00 Build 18 or higher or
lower than 7.6.00 Build 30 (UNIX/Windows 64-bit)

4 7.5.00 Build 35 or higher (UNIX/Windows 64-bit) or
7.6.00 Build 30 or higher (UNIX/Windows 64-bit) or
7.7.00 Build 18 or higher (UNIX/Windows 64-bit)

Caution: Prior to an upgrade of a Version 7.5. 00 Build 35 or higher to a Version 7.6.00 lower than Build 30, you must set the LOAD_BALANCING_CHK parameter back to the value 15 or higher (also see Note 832561).
Remark: If you operate the liveCache in a special configuration in which each user task runs in its own user kernel thread (Note 425051 or MAXCPU=MAXUSERTASKS), there is no point in activating the load balancing.
(In this case, set the value to 0).

LOG_QUEUE_COUNT (LogQueues)

As of Version 7.6. 00 you can configure several log queues, which significantly reduces collisions to LOGQUE* regions in multiprocessor machines (MAXCPU > 1). (See also Note 817887 for more information).
To achieve a minimum of collisions, the number of log queues should be the same as the value of MAXCPU, which is the default for new installations.
This can be achieved as follows:
Recommended: MAXCPU < 7.6.04
< 7.7.03
0 >= 7.6.04
>= 7.7.03
Note:
In liveCache Versions 7.6 below build 04 or 7. 7 below build 03, the parameter LOG_QUEUE_COUNT is not adjusted automatically if MAXCPU is changed (PTS 1147929 or 1143833).

LOG_IO_QUEUE (LogQueueSize)

This sets the size of the main memory area where log entries are buffered before they are written to the log volumes. Unit 8 KB pages
Recommended value: 2000
Note that this value refers to each maximum possible number of log queues (generally this is MAXCPU). The main memory that is allocated when you start the instance and the area that is reserved in the log area is as follows:
MAX_LOG_QUEUE_COUNT (MaxLogQueues) * LOG_IO_QUEUE (LogQueueSize)
(MAX_LOG_QUEUE_COUNT (MaxLogQueues) = 0 corresponds to )

MAXCPU (MaxCPUs)

This sets the maximum number of processors that liveCache uses to process application orders (SQL, LCA routines). Recommendation for a dedicated liveCache server: MAXCPU = Number of liveCache server processors (Note 410002).
If more applications run on the liveCache server (APO/SCM, DB), then limit MAXCPU to the largest number of processors that are available to the liveCache, possibly using a detailed sizing. If insufficient sizing information is available, we recommend that you set MAXCPU as follows: MAXCPU = (liveCache server processors)*2/3.
If blocks occur due to LCS routines running a long time on Windows, you must change the liveCache configuration and therefore MAXCPU in accordance with Note 425051.
For UNIX systems, you must activate load balancing in accordance with Note 695721.

MAXLOCKS (MaxSQLLocks)

This sets the maximum number of SQL locks.
Recommended value: 200000. Note 337773 describes the possible effects if the parameter setting is too small.
The parameter is calculated automatically – it is only necessary to change this parameter if the calculated value is smaller then the recommended value.

MAXUSERTASKS (MaxUserTasks)

This sets the maximum number of liveCache connections. Remark: Each user task requires approximately 1.5 MB of memory.
Minimum Version 7.5:
(Number of SCM work processes)*2 + 4. See Note 205220.
Minimum as of Version 7.6:
(Number of SCM work processes)*3 + 4.

MP_RGN_LOOP (MaxExclusiveLockCollisionLoops)

XP_MP_RGN_LOOP (only 7.5)
Maximum number of attempts to access a region that has already been blocked by another task before the task is entered in a queue (until the region is accessible).
As of Version 7.6, you can change the MP_RGN_LOOP parameter directly; in Version 7.5 you must change the XP_MP_RGN_LOOP parameter. If you set the relevant parameter to the default value (-1 or 0), liveCache will automatically calculate the actual value.
Recommended value: 10000 (if MAXCPU >=
-1 (7.6 + 7.7 if MAXCPU is less than
0 (7.5 if MAXCPU <=

OMS_HEAP_COUNT (OmsSubHeaps)

Segmentation of the liveCache heap to improve the
parellel processing in multi-processor environments. Unit: Number
of segments (minimum 1, maximum 128)
Recommended value:

OMS_HEAP_LIMIT (OmsMaxHeapSize)

This is the upper limit up to which the OMS heap is allowed to grow.
The value you should set depends on the hardware requirements
and the application profile and it results from the sizing of the
liveCache. The value should always be greater than zero. If
you set the value to zero, the limit value is removed and this may
lead to uncontrolled consumption of the memory by the liveCache process.
In rare cases, this may lead to an increased number of
paging activities at OS level with a corresponding
deterioration in performance.
Recommended value: > 0

SHAREDSQL (UseSharedSQL)

The caching of SQL commands in pure liveCache environments has not brought any clear advantages so far.
In contrast,
disadvantages due to collisions in RW regions
(for example, CommandCache:CommandLock) were observed on larger systems.
Recommended value: NO