Friday, 26 September 2014

WebSphere Application Server - JVM Performance

Pulling together some performance materials relating to IBM BPM, including this IBM Redbook: -


I also referenced a number of related articles: -




looking at aspects of Garbage Collection, including generational GC: -

Tuning generational GC

When the options are added, you will need to save and synchronize the changes before restarting the application server to put the changes in effect.

When tuning for generational garbage collection, the simplest approach is to treat the nursery space as a new Java heap area, in addition to the Java heap area used in the non-generational case. The Java heap for the non-generational case therefore becomes the tenured heap.

This approach is conservative: the expectation is that the occupancy of the tenured heap will drop as a result of introducing the nursery, but it provides a safe starting point, especially in the case of a migration from a non-generational policy. When the occupancy of the tenure heap after global (full) collections can be monitored, the size can then be adjusted as described earlier:

• -Xmn<size> sets the initial and maximum size of the nursery, effectively setting both -Xmns and -Xmnx.
• -Xmns<size> sets the initial size of the nursery to the specified value.
• -Xmnx<size> sets the maximum size of the nursery to the specified value.

The size of the nursery heap should be fixed, and as a result only one of these options, -Xmn is required. Therefore, you only need to understand how to correctly size the nursery heap.

No comments:

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...