How to improve DSI performance by configuring eXtreme Memory for data storage ?

On Demand Consulting
Author: Uday Pilai

Overview
This article describes how to configure and use eXtremeMemory to store objects in Decision Server Insights (DSI) .

Intended Audience

Intended audience for this article is Administrators planning to install and configure a DSI environment.

eXtremeMemory vs Java Heap
IBM^® eXtremeMemory enables objects to be stored in native memory instead of the Java™ heap. By moving objects off the Java heap you can avoid garbage collection pauses leading to more constant performance and predicable response times.

The Java virtual machine (JVM) relies on usage heuristics to collect compact and expand process memory. The garbage collector completes these operations. However running garbage collection has an associated cost. The cost of running garbage collection increases as the size of the Java heap and number of objects in the data grid increase. The JVM provides different heuristics for different use cases and goals: optimum throughput optimum pause time generational balanced and real-time garbage collection. No heuristic is perfect. A single heuristic cannot suit all possible configurations.

WebSphere^® eXtreme Scale uses data caching with distributed maps that have entries with a well-known lifecycle. This lifecycle includes the following operations: GET INSERT DELETE and UPDATE. By using these well-known map lifecycles eXtremeMemory can manage memory usage for data grid objects in container servers more efficiently than the standard JVM garbage collector.

The following diagram shows how using eXtremeMemory leads to more consistent relative response times in the environment. As the relative response times reach the higher percentiles the requests that are using eXtremeMemory have lower relative response times. The diagram shows the 95-100 percentiles.

Configuring eXtremeMemory

1. In the server.xml file for each runtime server in your topology set the enableXM parameter to true and specify the maximum eXtremeMemory heap size for the maxXMSize parameter.

For example on a server with 128 GB RAM if you allocate 3 GB for the operating system and 5 GB java heap then you set the maximum maxXMSize to 120000.

<xsServer enableXM="true" maxXMSize="120000"? catalogServer="false" listenerPort="${ia.listenerPort}" transport="XIO" serverName="${ia.serverName}" />

Note: The maxXMSize parameter is set in MB up to a maximum of 128000. For capacity planning you should only plan to use 60% of the memory specified by maxXMSize for actual data storage.

1. Disable the memento caching by editing the server.xml and objectgrid.xml files for each runtime server in your topology:

• In the server.xml file add the following parameter:

<ia_runtime mementoCacheSize="-1"/>

• In the objectgrid.xml file modify the Rulesets map and remove the nearCacheEnabled="true" and nearCacheInvalidationEnabled="true" attributes. The edited Rulesets map is as follows:

<backingMap name="Rulesets.*" template="true" copyMode="COPY_TO_BYTES" lockStrategy="OPTIMISTIC"                pluginCollectionRef="RulesetsPlugins" />

1. Edit the <InstallDir>/runtime/wlp/usr/servers/server_name/jvm.options file for each runtime server in your topology:

• Set the garbage collection policy to generational concurrent and tune the class loading settings as follows:

-Xmx5G
-Xms5G
-Xmn1G
-Xgcpolicy:gencon
-Xgc:classUnloadingKickoffThreshold=400

The value for Xmx is the minimum that is required. Monitor your verbose garbage collection and increase the values if the heap comes under pressure. The Java heap is still used for caching some objects so if you have a large number of entities and events you might have to increase it.
Note: Make sure that there is 4 GB of tenured heap space between Xmx and Xmn

• Delete the -XX:MaxDirectMemorySize=1G line.

Note : You do not need to set MaxDirectMemory when running with eXtremeMemory.