[jira] [Comment Edited] (CASSANDRA-10425) Autoselect GC settings depending on system memory

["Jonathan Shook (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-10425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095515#comment-15095515 ] 

Jonathan Shook edited comment on CASSANDRA-10425 at 1/13/16 3:05 AM:
---------------------------------------------------------------------

I think we should try to come up with a way of handling settings which one would choose differently for a new install. Settings like this will live forever without a better approach. I agree entirely with the principle of least surprise. However, according to this default, there will be new systems deployed in 2020 with CMS. There has to be a better way.

If we were able to have an install mode which would honor previous settings or take new defaults that are more desirable for current code and systems, perhaps we can avoid  the CMS in 2020 problem. Installers may require a user to specify a mode in order to make this truly unsurprising. If I were installing a new cluster in 2020, I would be quite surprised to find it running CMS.

Also, the point of having the settings be size-specific is to avoid surprising performance deficiencies. This is the kind of change that I would expect to go with a major version upgrade. 

So, to follow the principle of least surprise, perhaps we need to consider making this possible for those who expect to be able to use more than 32GB with G1 to address GC bandwidth and pause issues for heavy workloads, as we've come to expect through field experience. Otherwise, we'll be manually rewiring this from now on for all but historic pizza-boxen.



was (Author: jshook):
I think we should try to come up with a way of handling settings which one would choose differently for a new install. Settings like this will live forever without a better approach. I agree entirely with the principle of least surprise. However, according to this default, there will be new systems deployed in 2020 with CMS. There has to be a better way.

If we were able to have an install mode which would honor previous settings or take new defaults that are more desirable for current code and systems, perhaps we can avoid  the CMS in 2020 problem. Installers may require a user to specify a mode in order to make this truly unsurprising. If I were installing a new cluster in 2020, I would be quite surprised to find it running CMS.

Also, the point of having the settings be size-specific is to avoid surprising performance deficiencies. This is the kind of change that I would expect to go with a major version. 

So, to follow the principle of least surprise, perhaps we need to consider making this possible for those who expect to be able to use more than 32GB with G1 to address GC bandwidth and pause issues for heavy workloads, as we've come to expect through field experience. Otherwise, we'll be manually rewiring this from now on for all but historic pizza-boxen.


> Autoselect GC settings depending on system memory
> -------------------------------------------------
>
>                 Key: CASSANDRA-10425
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10425
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Configuration
>            Reporter: Jonathan Shook
>
> 1) Make GC modular within cassandra-env
> 2) For systems with 32GB or less of ram, use the classic CMS with the established default settings.
> 3) For systems with 48GB or more of ram, use 1/2 or up to 32GB of heap with G1, whichever is lower.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)