Administration guide > Tune and performance > Tuning the cache sizing agent



Cache memory consumption sizing

Beginning with the 7.1 release, WebSphere eXtreme Scale can accurately estimate the Java™ heap memory usage of a given BackingMap in bytes. Leverage this capability to help correctly size the JVM heap settings and eviction policies. The behavior of this feature varies with the complexity of the Objects being placed in the backing map and how the map is configured. Currently, this feature is supported only for distributed data grids. Local data grid instances do not support used bytes sizing.


Heap consumption considerations

eXtreme Scale stores all of its data inside the heap space of the JVM processes that make up the data grid. For a given map, the heap space it consumes can be broken down into the following components:

The number of used bytes that is reported by the sizing statistics is the sum of these four components. These values are calculated on a per entry basis on the insert, update, and remove map operations, meaning that eXtreme Scale always has a current value for the number of bytes that a given backing map is consuming.

When data grids are partitioned, each partition contains a piece of the backing map. Because the sizing statistics are calculated at the lowest level of the eXtreme Scale code, each partition of a backing map tracks its own size. Use the eXtreme Scale Statistics APIs to track the cumulative size of the map, as well as the size of its individual partitions.

In general, use the sizing data as a measure of the trends of data over time, not as an accurate measurement of the heap space that is being used by the map. For example, if the reported size of a map doubles from 5 MB to 10 MB, then view the memory consumption of the map as having doubled. The actual measurement of 10 MB might be inaccurate for a number of reasons. If you take the reasons into account and follow the best practices, then the accuracy of the size measurements approaches that of post-processing a Java heap dump.

The main issue with accuracy is that the Java Memory Model is not restrictive enough to allow for memory measurements that are certain to be accurate. The fundamental problem is that an object can be live on the heap due to multiple references. For example, if the same 5 KB object instance is inserted into three separate maps, then any of those three maps prevent the object from being garbage collected. In this situation, any of the following measurements would be justifiable:

This ambiguity is why these measurements should be considered trend data, unless you have removed the ambiguity through design choices, best practices, and understanding of the implementation choices that can provide more accurate statistics.

eXtreme Scale assumes that a given map holds the only long-lived reference to the key and value Objects that it contains. If the same 5 KB object is put into three maps, then the size of each map is increased by 5 KB. The increase usually is not a problem, because the feature is supported only for distributed data grids. If you insert the same Object into three different maps on a remote client, each map receives its own copy of the Object. The default transactional COPY MODE settings also usually guarantee that each map has its own copy of a given Object.


Object interning

Object interning can cause a challenge with estimating heap memory usage. When you implement object interning, the application code purposely ensures that all references to a given object value actually point to the same object instance on the heap, and therefore the same location in memory. An example of this might be the following class: 

 public class ShippingOrder implements Serializeable,Cloneable{

     public static final STATE_NEW = “new”;
     public static final STATE_PROCESSING = “processing”;
     public static final STATE_SHIPPED = “shipped”;

     private String state;
     private int orderNumber;
    private int customerNumber;

    public Object clone(){
        ShippingOrder toReturn = new ShippingOrder();
        toReturn.state = this.state;
        toReturn.orderNumber = this.orderNumber;
        toReturn.customerNumber = this.customerNumber;
        return toReturn;
     }
 
     private void readResolve(){
         if (this.state.equalsIgnoreCase(“new”)
             this.state = STATE_NEW;
         else if (this.state.equalsIgnoreCase(“processing”)
             this.state = STATE_PROCESSING;
         else if (this.state.equalsIgnoreCase(“shipped”)
             this.state = STATE_SHIPPED:
     }
 }

Object interning causes overestimation by the sizing statistics because eXtreme Scale assumes that the objects are using different memory locations. If a million ShippingOrder objects exist, the sizing statistics display the cost of a million Strings holding the state information. In reality, only three Strings exist that are static class members. The memory cost for the static class members never should be added to any eXtreme Scale map. However, this situation cannot be detected at runtime. There are dozens of ways that similar object interning can be implemented, which is why it is so hard to detect. It is not practical for eXtreme Scale to protect against all possible implementations. However, eXtreme Scale does protect against the most commonly used types of object interning.

To optimize memory usage with Object interning, implement interning only on custom objects that fall into the following two categories to enhance the accuracy of the memory consumption statistics:


Memory consumption statistics

Use one of the following methods to access the memory consumption statistics.

Statistics API

Use the MapStatsModule.getUsedBytes() method, which provides statistics for a single map, including the number of entries and hit rate.

For details, see Statistics modules.

Managed Beans (MBeans)

Use the MapUsedBytes managed MBean statistic. Use several different types of Java Management Extensions (JMX) MBeans to administer and monitor deployments. Each MBean refers to a specific entity, such as a map, eXtreme Scale, server, replication group, or replication group member.

For details, see Administer programmatically with Managed Beans (MBeans).

Performance monitoring infrastructure (PMI) modules

You can monitor the performance of the applications with the PMI modules. Specifically, use the map PMI module for containers embedded in WebSphere Application Server.

For details, see PMI modules.

[v7.1 and later] WebSphere eXtreme Scale console

With the console, you can view the memory consumption statistics. See Monitor with the web console.

All of these methods access the same underlying measurement of the memory consumption of a given BaseMap instance. The WebSphere eXtreme Scale runtime attempts with a best effort to calculate the number of bytes of heap memory that is consumed by the key and value objects that are stored in the map, as well as the overhead of the map itself. You can see how much heap memory each map is consuming across the whole distributed data grid.

In most cases the value reported by WebSphere eXtreme Scale for a given map is very close to the value reported by heap dump analysis. WebSphere eXtreme Scale accurately sizes its own overhead, but cannot account for every possible object that might be put into a map. Following the best practices described in Tune the cache sizing agent for accurate memory consumption estimates can enhance the accuracy of the size in bytes measurements provided by WebSphere eXtreme Scale.


Parent topic:

Tune the cache sizing agent for accurate memory consumption estimates


Related tasks

Tune the cache sizing agent for accurate memory consumption estimates


+

Search Tips   |   Advanced Search