> > 1) nodetool is reusing the $MAX_HEAP_SIZE environment variable, thus if we > are running Cassandra with e.g. Xmx31G, nodetool is started with Xmx31G as > well
This was fixed in 3.0.11/3.10 in CASSANDRA-12739 <https://issues.apache.org/jira/browse/CASSANDRA-12739>. Not sure why it didn't make it into 2.1/2.2. > 2) As -XX:ParallelGCThreads is not explicitly set upon startup, this > basically defaults to a value dependent on the number of cores. In our > case, with the machine above, the number of parallel GC threads for the JVM > is set to 43! > 3) Test-wise, we have adapted the nodetool startup script in a way to get > a Java Flight Recording file on JVM exit, thus with each nodetool > invocation we can inspect a JFR file. Here we may have seen System.gc() > calls (without visible knowledge where they come from), GC times for the > entire JVM life-time (e.g. ~1min) showing high cpu. This happened for both > Xmx128M (default as it seems) and Xmx31G > > After explicitly setting -XX:ParallelGCThreads=1 in the nodetool startup > script, CPU usage spikes by nodetool are entirely gone. > > Is this something which has been already adapted/tackled in Cassandra > versions > 2.1 or worth to be considered as some sort of RFC? > Can you create a JIRA for this (and a patch, if you like)? We should be explicitly setting this on nodetool invocations.
