[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14282609#comment-14282609
]
Jeremy Hanna commented on CASSANDRA-7432:
-
It looks like is in 2.0, but not 2.1 forward.
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
Fix For: 2.0.10, 2.1.1
Attachments: 7432.txt
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14282931#comment-14282931
]
Brandon Williams commented on CASSANDRA-7432:
-
Not what happened, I see my original commit did go into 2.1, but couldn't find
where it got removed. Anyway, I put them back.
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
Fix For: 2.0.10, 2.1.1
Attachments: 7432.txt
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14089294#comment-14089294
]
Joshua McKenzie commented on CASSANDRA-7432:
Created CASSANDRA-7714 to track the Windows side.
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
Fix For: 2.0.10, 2.1.1
Attachments: 7432.txt
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14087979#comment-14087979
]
Brandon Williams commented on CASSANDRA-7432:
-
[~JoshuaMcKenzie] we probably need a windows equivalent here.
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
Fix For: 2.0.10, 2.1.1
Attachments: 7432.txt
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14086869#comment-14086869
]
Brandon Williams commented on CASSANDRA-7432:
-
Sigh, no, this doesn't work either because testing for 1.8 in pure bash won't
work, since 1.8.0 will be lexically greater than 1.8.
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
Fix For: 1.2.19
Attachments: 7432.txt
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14086902#comment-14086902
]
Jonathan Ellis commented on CASSANDRA-7432:
---
More details on what these two patches do:
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/007374.html
(TLDR remark is already parallel but the way it samples the work means that a
single thread can be assigned the bulk of the work. CMSEdenChunksRecordAlways
fixes this.)
+1 from me
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
Fix For: 1.2.19
Attachments: 7432.txt
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14086906#comment-14086906
]
Jonathan Ellis commented on CASSANDRA-7432:
---
bq. CMSScavengeBeforeRemark which is off by default. If turned on, it will
cause a minor collection to occur just before the remark. That's good because
it will reduce the remark pause. That's bad because there is a minor collection
pause followed immediately by the remark pause which looks like 1 big fat pause
(https://blogs.oracle.com/jonthecollector/entry/did_you_know)
I'm a bit leery of this one.
bq. CMSWaitDuration=1
This sounds like a more conservative approach to me, +1 for this.
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
Fix For: 1.2.19
Attachments: 7432.txt
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14084927#comment-14084927
]
Rick Branson commented on CASSANDRA-7432:
-
Very happy with this in production. Enabling -XX:+CMSParallelInitialMarkEnabled
and -XX:+CMSEdenChunksRecordAlways has *drastically* improved the STW portions
of CMS for our nodes with 4GB+ young gen. Not seeing any downsides to enabling
these options either.
We're also running a few more options that have trade-offs which could be
considered:
-XX:+CMSScavengeBeforeRemark which has helped reduce the pause times of STW
portions of CMS remark with large eden spaces, since it's dependent on how much
live garbage is in the eden space. If CMS is ran infrequently (every few
minutes or so) I can't see how this option could hurt people even with small
eden spaces.
-XX:CMSWaitDuration=1. This is how long the CMS will wait for a young gen
collection before running the initial mark. It waits for a collection because
the stop-the-world initial mark time depends on how many live objects are in
eden space. The default is 2000ms, which seems low to me. The trade-off is that
if it waits too long, CMS could run out of time and a promotion failure could
occur. This seems unlikely though at 10 seconds in any even remotely healthy
scenario.
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
Fix For: 1.2.19
Attachments: 7432.txt
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059052#comment-14059052
]
graham sanderson commented on CASSANDRA-7432:
-
presumably those should be = rather than
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
Fix For: 1.2.19
Attachments: 7432.txt
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059057#comment-14059057
]
Brandon Williams commented on CASSANDRA-7432:
-
Nope. Read the comment right above it, it evals as =
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
Fix For: 1.2.19
Attachments: 7432.txt
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059068#comment-14059068
]
Brandon Williams commented on CASSANDRA-7432:
-
If you have a java version like 1.7.0_60-b19 then 1.7.0 is 1.7 and
60-b19 is 60
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
Fix For: 1.2.19
Attachments: 7432.txt
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059073#comment-14059073
]
Brandon Williams commented on CASSANDRA-7432:
-
There is a problem though, our patch logic chops off the -b19 portion.
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
Fix For: 1.2.19
Attachments: 7432.txt
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059091#comment-14059091
]
graham sanderson commented on CASSANDRA-7432:
-
Sorry, yes... that comment was old, and I wasn't sure it applied (I thought the
version was actualy 1.7 rather than 1.7.0, so the opposite of what the actual
problem is!)... sorry about that
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
Fix For: 1.2.19
Attachments: 7432.txt
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059233#comment-14059233
]
Brandon Williams commented on CASSANDRA-7432:
-
bq. that comment was old, and I wasn't sure it applied
Not your fault, it was cruft I accidentally left behind, then got the chance to
reuse :)
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
Assignee: Brandon Williams
Fix For: 1.2.19
Attachments: 7432.txt
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7432) Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
[
https://issues.apache.org/jira/browse/CASSANDRA-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14039890#comment-14039890
]
graham sanderson commented on CASSANDRA-7432:
-
Here are some performance numbers(we have an unusually large heap for C*: 8gig
new, 16g old):
h3. +CMSParallelInitialMarkEnabled
||Initial Mark STW pauses(secs)|Min|Median|Mean|Max|StdDev||
|Without +CMSParallelInitialMarkEnabled|0.000|0.050|0.109|0.880|0.159|
|With +CMSParallelInitialMarkEnabled|0.000|0.010|0.019|0.090|0.019|
h3. +CMSEdenChunksRecordAlways
||Remark STW pauses(secs)|Min|Median|Mean|Max|StdDev||
|Without +CMSEdenChunksRecordAlways|0.010|0.470|1.049|6.580|1.394|
|With +CMSEdenChunksRecordAlways|0.010|0.135|0.148|0.520|0.114|
Note this option addresses the issue loosely described
[here|https://blogs.oracle.com/jonthecollector/entry/did_you_know] in the
*CMSMaxAbortablePrecleanTime* section. The short version of the problem is that
if you are unlucky (and bursty activity in your cluster will make you less
lucky, then even though you have {{-XX:*CMSParallelRemarkEnabled}}, you may get
very low parallelism in your remark STW *and* you may have a very full eden
when you are doing it.
Add new CMS GC flags to cassandra_env.sh for JVM later than 1.7.0_60
Key: CASSANDRA-7432
URL: https://issues.apache.org/jira/browse/CASSANDRA-7432
Project: Cassandra
Issue Type: Improvement
Components: Packaging
Reporter: graham sanderson
The new flags in question are as follows:
{code}
-XX:+CMSParallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
{code}
Given we already have
{code}
JVM_OPTS=$JVM_OPTS -XX:+UseParNewGC
JVM_OPTS=$JVM_OPTS -XX:+UseConcMarkSweepGC
JVM_OPTS=$JVM_OPTS -XX:+CMSParallelRemarkEnabled
JVM_OPTS=$JVM_OPTS -XX:+UseTLAB
if [ $JVM_ARCH = 64-Bit ] ; then
JVM_OPTS=$JVM_OPTS -XX:+UseCondCardMark
fi
{code}
The assumption would be that people are at least running on large number CPU
cores/threads
I would therefore recommend defaulting these flags if available - the only
two possible downsides for {{+CMSEdenChunksRecordAlways}}:
1) There is a new very short (probably un-contended) lock in the slow (non
TLAB) eden allocation path with {{+CMSEdenChunksRecordAlways}}. I haven't
detected this timing wise - this is the slow path after all
2) If you are running with {{-XX:-UseCMSCompactAtFullCollection}} (not the
default) *and* you call {{System.gc()}} then {{+CMSEdenChunksRecordAlways}}
will expose you to a possible seg fault: (see
[http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8021809])
--
This message was sent by Atlassian JIRA
(v6.2#6252)
