Red Hat Bugzilla – Bug 1471239
Cassandra Java heap parameters can configured incorrectly
Last modified: 2017-08-04 15:36:37 EDT
Description of problem:
We pass the -Xms, -Xmx, and -Xmn flags to the Cassandra JVM. -Xms sets the minimum size for all of the heap. -Xmx set the max size for all of the heap. -Xmn sets the size of the new generation. The heap is basically divided into two sections, the new or young generation and the old generation. We calculate the value for -Xmn based on the number of cpu cores. There are times, like when there are no cpu limits, that we can end up with -Xmn having a value larger than -Xmx. If that happens, the JVM will log a warning at start up like this:
OpenJDK 64-Bit Server VM warning: MaxNewSize (4096000k) is equal to or greater than the entire heap (1048576k). A new max generation size of 1048512k will be used.
We need to fix this. The JVM will dynamically resize the generations as needed, and this can also be controlled with other flags which we do not set. For the type of work loads with which we are dealing, I think we generally want the new generation to be between 1/4 and 1/2 of the total heap.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
We have been setting it this way based on the Cassandra recommendations (although we were not taking into account the total memory available).
How serious is this issue?
I am not sure how serious it is. We know it does not prevent Cassandra from starting, and I only think it is an issue where there is unlimited cpu. Based on some additional research I think we should set the new generation to 1/4 of the total heap. I think that is a reasonable default.