Private memory caches

Each CPU virtual processor (VP) or tenant VP can have a private memory cache to speed access time to memory blocks.

All memory allocations that are requested by threads in the database server are fulfilled by memory pools. When a memory pool has insufficient memory blocks to satisfy a memory allocation request, blocks are allocated from the global memory pool. Because all threads use the same global memory pool, contention can occur. Private memory caches allow each virtual processor to retain its own set of memory blocks that can be used to bypass the global memory pool. The initial allocation for private memory caches is from the global memory pool. When the blocks are freed, they are freed to the private memory cache on a specific virtual process. When a memory allocation is requested, the thread first checks whether the allocation can be satisfied by blocks in the private memory cache. Otherwise, the thread requests memory from the global memory pool.

To determine whether private memory caches might improve performance for your database server, run the onstat -g spi command and look for the sh_lock mutex. If onstat -g spi command output shows contention for the sh_lock mutex, try creating private memory caches.

You set the VP_MEMORY_CACHE_KB configuration parameter to enable private memory caches by specifying the initial combined size of all private memory caches. By default, the total size of private memory caches is limited to the size value of the VP_MEMORY_CACHE_KB configuration parameter. You can set the mode to DYNAMIC to allow the size of each private memory cache to increase or decrease automatically based on the workload of the associated VP. In dynamic mode, the total size of private memory caches can exceed the value of the VP_MEMORY_CACHE_KB configuration parameter, but cannot exceed the value of the SHMTOTAL configuration parameter.

You can view statistics about VP private memory caches by running the onstat -g vpcache command. You can view statistics about memory pools by running the onstat -g mem command.