Optional: Changing memory data storage options

The speed and amount of data in memory plays a critical role in the performance of your system. You can set different values for the event horizon and event caching properties, and change Java™ heap memory to eXtremeMemory. eXtremeMemory is supported on x86 64-bit Linux systems and Power Linux Little Endian (LE) only that are using a 64-bit Java runtime environment. For other environments, you must use Java heap.

About this task

Agents keep references to the events that they need. An agent horizon is how long in the past the agent can use events. When a solution is deployed, Decision Server Insights compares all of the agent horizons in that solution and then keeps the events for the longest horizon period.

The maxHorizon property allows an administrator to place an ultimate limit on event retention; events in memory can have a significant impact on capacity. Changing the maxHorizon changes the scope of events for agents. You can increase the horizon in anticipation of future rules that need a longer scope.

The eventCacheDuration property can be used to reduce the overall memory requirements for a solution. When eventCacheDuration is set, events are removed from memory after that time, and are reloaded from the backing database as required. If eventCacheDuration is set to half the length of the longest horizon, it can reduce the overall memory requirements by more than a third. The more events per entity, the more dramatic the memory reduction. If you have many entities, which are used infrequently, you can reduce eventCacheDuration to a small period, for example 1 minute.

Note: The timeToLive parameter of backing map elements in the objectgrid.xml file is used to control how long events are retained when events are reloaded. Because the timeToLive value is not configurable dynamically, set the value more conservatively (higher) than the eventCacheDuration value.

You can configure Decision Server Insights to use system heap memory for data storage instead of Java heap. When you move data out of the Java heap, you avoid garbage collection pauses providing more constant performance and predictable response times. By default, data is stored in Java heap memory. For more information, see IBM® eXtremeMemory.

You must enable eXtremeMemory and configure the system heap memory for each runtime server in your topology.

Procedure

  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.
  2. Disable the memento caching by editing the server.xml and objectgrid.xml files for each runtime server in your topology:
    1. In the server.xml file, add the following parameter:
      <ia_runtime mementoCacheSize="-1"/>
    2. 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" />
  3. Edit the <InstallDir>/runtime/wlp/usr/servers/server_name/jvm.options file for each runtime server in your topology:
    1. 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
    2. Delete the -XX:MaxDirectMemorySize=1G line.

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