WebSphere eXtreme Scale Best Practices for Operation and Management

54 WebSphere eXtreme Scale Best Practices for Operation and Management

After we have the value of the numberOfObjects and averageObjectSize, we can complete the

memory size calculations:

1. Calculate the memory required for this map:

primaryObjectMemory = numberOfObjects * averageObjectSize

2. Repeat step 1 for each map in this grid.

3. Add all primaryObjectMemory numbers together to come up with a primaryObjectMemory

for all maps in this grid, which will be used for all subsequent steps.

4. Calculate the maximum size of the data to be stored, which includes primaries and

replicas (it does not matter whether they will be synchronous or asynchronous replicas):

totalObjectMemory = primaryObjectMemory + primaryObjectMemory *

numberOfReplicas

4.1.5 Determining the maximum heap size and physical memory per JVM

Next, we want to know how much object memory will be taken up by our object data

(primaries and replicas) in each of our container JVMs. WebSphere eXtreme Scale places

objects evenly across our C containers (pick an arbitrary C to start with, because we can

validate and fix it up later if necessary).

containerObjectMemory = totalObjectMemory / C (do not round anything yet)

Determining maximum heap size

Use containerObjectMemory to determine the maxHeapSizePerJVM. The calculations will

take the following information into account:

򐂰 The containerObjectMemory value will be less than the maximum heap size of the JVM,

because WebSphere eXtreme Scale itself (and WebSphere Application Server if your

containers are in a managed installation topology) uses heap memory. We will account for

this situation with the following variables:

– WXS-Footprint = WebSphere eXtreme Scale runtime memory consumption in the

JVM. As of WebSphere eXtreme Scale V7.0 or V7.1, WXS-Footprint = 100 MB

(roughly).

– WAS-Footprint = WebSphere Application Server runtime memory consumption in the

JVM. As of WebSphere Application Server V6.1, WAS-Footprint = 300 MB (roughly).

򐂰 You are more likely to avoid Java OutOfMemoryErrors if you run at 60% of the maximum

heap size for your JVM; you might be able to push this limit higher, depending on your

particular situation.

We will use a 1.7 multiplier to represent the 60% heap utilization factor.

So, you can calculate the maximum heap size for the JVMs with the following formula:

maxHeapSizePerJVM = (containerObjectMemory + WXS-Footprint + WAS-Footprint ) * 1.7

Adjusting footprint estimates for the class data sharing feature

As of Java Platform 2, Standard Edition (J2SE) 5.0, for most Java Developer Kit providers, a

Java feature called

class data sharing might be significant here. This feature means that,

within a single node, if the same classes are loaded in more than one JVM, that only one copy

is held in memory and shared among all the JVMs. For us, that means that the WAS-Footprint

(which is mostly classes of executable code) only has to be counted for one JVM in each

node. Continue to count the WXS-Footprint for each JVM, because it is mostly

container-specific data. Confirm that your JSE or Java Platform, Enterprise Edition (JEE)