[
https://issues.apache.org/jira/browse/CASSANDRA-10403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14938336#comment-14938336
]
Jonathan Shook edited comment on CASSANDRA-10403 at 9/30/15 7:28 PM:
---------------------------------------------------------------------
[~JoshuaMcKenzie]
I understand and appreciate the need to control scoping effort for 3.0 planning.
bq. Shouldn't the read/write workload distribution also play into that?
Yes, but there is a mostly orthogonal effect to the nuances of the workload mix
which has to do with the vertical scalability of GC when the system is more
fully utilized. This is visible along the sizing spectrum. Run the same
workload and try to scale the heap proportionally over the memory (1/4 or
whatever) and you will likely see CMS suffer no matter what. This is slightly
conjectural, but easily verifiable with some effort.
bq. the idea of having a default that's optimal for everyone is unrealistic
I think we are converging on a common perspective on this.
[~slebresne]
bq. 3.2 will come only 2 months after 3.0
My preference would be to have the CASSANDRA-10425 out of the gate, but this
still would require some testing effort for safety. The reason being that 3.0
represents a reframing of performance expectations, and after that, any changes
to default, even for larger memory systems constitute a bigger chance of
surprise. Do we have a chance to learn about sizing from surveys, etc before
the runway ends for 3.0?
If we could get something like CASSANDRA-10425 in place, it would cover both
bases.
was (Author: jshook):
[~JoshuaMcKenzie]
I understand and appreciate the need to control scoping effort for 3.0 planning.
bq. Shouldn't the read/write workload distribution also play into that?
Yes, but there is a mostly orthogonal effect to the nuances of the workload mix
which has to do with the vertical scalability of GC when the system. This is
visible along the sizing spectrum. Run the same workload and try to scale the
heap proportionally over the memory (1/4 or whatever) and you will likely see
CMS suffer no matter what. This is slightly conjectural, but easily verifiable
with some effort.
bq. the idea of having a default that's optimal for everyone is unrealistic
I think we are converging on a common perspective on this.
[~slebresne]
bq. 3.2 will come only 2 months after 3.0
My preference would be to have the CASSANDRA-10425 out of the gate, but this
still would require some testing effort for safety. The reason being that 3.0
represents a reframing of performance expectations, and after that, any changes
to default, even for larger memory systems constitute a bigger chance of
surprise. Do we have a chance to learn about sizing from surveys, etc before
the runway ends for 3.0?
If we could get something like CASSANDRA-10425 in place, it would cover both
bases.
> Consider reverting to CMS GC on 3.0
> -----------------------------------
>
> Key: CASSANDRA-10403
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10403
> Project: Cassandra
> Issue Type: Improvement
> Components: Config
> Reporter: Joshua McKenzie
> Assignee: Paulo Motta
> Fix For: 3.0.0 rc2
>
>
> Reference discussion on CASSANDRA-7486.
> For smaller heap sizes G1 appears to have some throughput/latency issues when
> compared to CMS. With our default max heap size at 8G on 3.0, there's a
> strong argument to be made for having CMS as the default for the 3.0 release.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
