Planning to use IBM eXtremeMemory

By configuring eXtremeMemory, you can store objects in native memory instead of on the Java™ heap. When you configure eXtremeMemory, you can either allow the default amount of memory to be used, or you can calculate the amount of memory that you want to dedicate to eXtremeMemory.

Before you begin

  • To learn more about eXtremeMemory, see IBM eXtremeMemory.
  • [Linux][Solaris]eXtremeMemory is supported on x86 64-bit Linux® systems that are using a 64-bit SDK and Solaris on Sparc 64 systems.
  • [Linux] eXtremeMemory is supported on Red Hat Linux operation systems on IBM Power 8 Systems.
  • You must be using map sets that have all the maps configured with COPY_TO_BYTES or COPY_TO_BYTES_RAW copy modes. If any maps within the map set are not using one of these copy modes, objects are stored on the Java heap.
  • [Linux]You must have the shared resource, libstdc++.so.5, installed. Use the package installer of your 64-bit Linux distribution to install the required resource file. For more information, see Troubleshooting IBM eXtremeMemory.
  • You cannot use eXtremeMemory in the following configuration scenarios:
    • When you are using custom evictors. The only evictors that are supported with eXtremeMemory are the built-in TTL, LRU, LFU and dynamic cache evictors.
    • When you are using built-in write-behind loaders.
    • When you are using EntityManager APIs.
  • [Version 8.6.0.2 and later]You must have Version 8.6.0.2 or later installed if you are using dynamic or composite indexes.
  • You must have an existing data grid from which you can determine the total map sizes.
  • You must ensure that all data grids have the same eXtremeMemory setting. All container servers must be started with the setting enableXM=true or enableXM=false. You cannot mix these settings.

About this task

By default, eXtremeMemory uses 25% of the total memory on the system. You can change this default with the maxXMSize property, which specifies the number of megabytes to dedicate for use by eXtremeMemory.

Procedure

Optional: Plan the appropriate maxXMSize property value to use. This value sets the maximum amount of memory, in megabytes, that is used by the server for eXtremeMemory.
  1. In your existing configuration, determine the size per entry.
    Run the xscmd -c showMapSizes command to determine this size.
  2. Calculate the maxXMSize value.
    To get maximum total size of entries (maximum_total_size), multiply the size_per_entry * maximum_number_of_entries. Use no more than 60% of maxXMSize to account for metadata processing. Multiply maximum_total_size* 1.65 to get the maxXMSize value.
  3. For data grids that have a high number of maps or shards, consider the memory usage of empty maps. This usage is about 1 MB per map.
    You can display the number of maps with thexscmd -c showMapSizes command. To compute the maxXMSize, multiply the number_of_maps * 1MB, where the number_of_maps is the number of maps that is shown for a single container in the output of the xscmd -c showMapSizes command. Add the resulting value to the maxXMSize value that you calculated in the previous step.

What to do next

If the maxXMSize value is nearing the total physical memory, consider reducing the number of maps or partitions. You can also consider adding more servers to the deployment to reduce the demand on a single server. [Version 8.6 and later]If memory demand is still a concern, consider enabling disk overflow. For more information, see Enabling disk overflow.