Administration guide > Tune and performance

Tune the cache sizing agent for accurate memory consumption estimates


WebSphere eXtreme Scale 7.1 begins support for sizing the memory consumption of BackingMaps in distributed data grids.

Memory consumption sizing is not supported for local data grid instances.

The value reported by WXS for a given map is usually 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 cache entry objects that cannot be accurately sized because they are overly complex. Avoid unnecessary map complexity.

Enable the sizing agent

If you are using a Java 5 or higher JVM, take advantage of the sizing agent, which allows WXS to 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 WAS process.

For a distributed topology, add the argument to command line of the eXtreme Scale processes (containers) and the WAS 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

WXS can accurately size the memory cost of the following types:

Avoid object internment

When an object is inserted into a map, WXS 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 WXS sizes that string instance 1000 times, overestimating the actual size of the map on the heap.

However, WXS correctly compensates for the following common internment scenarios:

If 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 the own custom implementations.

When using custom types, keep the Object tree to one level. When inserting a custom Object into a map, WXS will only calculate the cost of the inserted Object, which includes any primitive fields, and all the Objects it directly references. WXS will not follow references further down into the Object tree. If you insert an Object into the map, and WXS detects references that were not followed during the sizing process, we will get a message coded CWOBJ4543 that will include the name of the Class that could not be fully sized. When this 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

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).

Parent topic:

Tune and performance

Related concepts

Cache memory consumption sizing
Operating systems and network tuning
Plan for network ports
ORB properties and file descriptor settings
JVM tuning for WXS
Cache memory consumption sizing

Related tasks

Configure failover detection
Tune the dynamic cache provider

Related reference

Operational checklist