Tuning the cache sizing agent for accurate memory consumption estimates

WebSphere® eXtreme Scale supports sizing the memory consumption of BackingMap instances in distributed data grids. Memory consumption sizing is not supported for local data grid instances. The value that is reported by WebSphere eXtreme Scale for a given map is very close to the value that is reported by heap dump analysis. If map object is complex, the sizings might be less accurate. The CWOBJ4543 message is displayed in the log for any cache entry object that cannot be accurately sized because it is overly complex. You can get a more accurate measurement by avoiding unnecessary map complexity.

Procedure

  • Enable the sizing agent.
    If you are using a Java™ 5 or higher Java virtual machine (JVM), use the sizing agent. With the sizing agent, WebSphere eXtreme Scale can obtain additional information from the JVM to improve its estimates. The agent can be loaded by adding the following argument to the JVM command line: 
    -javaagent:WXS lib directory/wxssizeagent.jar

    For an embedded topology, add the argument to the command line of the WebSphere Application Server process.

    For a distributed topology, add the argument to command line of the eXtreme Scale processes (containers) and the WebSphere Application Server process.

    When loaded correctly, the following message is written to the SystemOut.log file.
    CWOBJ4541I: Enhanced BackingMap memory sizing is enabled.
  • Prefer Java data types over custom data types, where possible.
    WebSphere eXtreme Scale can accurately size the memory cost of the following types:
    • java.lang.String and arrays where String is the component class (String[])
    • All primitive wrapper types (Byte, Short, Character, Boolean, Long, Double, Float, Integer) and arrays where primitive wrappers are the component type (for example, Integer[], Character[])
    • java.math.BigDecimal and java.math.BigInteger, and arrays where these two classes are the component type (BigInteger[] and BigDecimal[])
    • Temporal types (java.util.Date, java.sql.Date, java.util.Time, java.sql.Timestamp)
    • java.util.Calendar and java.util.GregorianCalendar
  • Avoid object internment, when possible.
    When an object is inserted into a map, WebSphere eXtreme Scale assumes that it holds the only reference to the object and all the objects to which the object directly refers. If you insert 1000 custom Objects into a map, and each one has a reference to the same string instance, then WebSphere eXtreme Scale sizes that string instance 1000 times, overestimating the actual size of the map on the heap. However, WebSphere eXtreme Scale correctly compensates for the following common internment scenarios:
    • References to Java 5 Enums
    • References to Classes that follow the Typesafe Enum Pattern. Classes following this pattern only have only private constructors defined, have at least one private static final field of its own type, and if they implement Serializable, the class implements the readResolve() method.
    • Java 5 Primitive wrapper internment. For example, using Integer.valueOf(1) instead of new Integer(1)

    If you must use internment, use one of the preceding techniques to get more accurate estimates.

  • Use custom types thoughtfully.

    When using custom types, prefer primitive data types for fields vs Object types.

    Also, prefer the Object types listed in entry 2 over your own custom implementations.

    When using custom types, keep the Object tree to one level. When inserting a custom Object into a map, WebSphere eXtreme Scale will only calculate the cost of the inserted Object, which includes any primitive fields, and all the Objects it directly references. WebSphere eXtreme Scale will not follow references further down into the Object tree. If you insert an Object into the map, and WebSphere eXtreme Scale detects references that were not followed during the sizing process, a message coded CWOBJ4543 that includes the name of the Class that could not be fully sized results. When this error occurs, treat the size statistics on the map as trend data, rather than relying on the size statistics as an accurate total.

  • Use the CopyMode.COPY_TO_BYTES copy mode if possible.

    Use the CopyMode.COPY_TO_BYTES copy mode to remove any uncertainty from sizing the value Objects being inserted into the map, even when an Object tree has too many levels to be sized normally (resulting in the CWOBJ4543 message).