[jira] [Comment Edited] (CASSANDRA-10013) Default commitlog_total_space_in_mb to 4G
[ https://issues.apache.org/jira/browse/CASSANDRA-10013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14713012#comment-14713012 ] Ryan Svihla edited comment on CASSANDRA-10013 at 8/26/15 12:16 PM: --- Only negative and I've hit this, is the commit log filling up a small partition that previously was large enough. While I can safely say this should NEVER be a problem, it sometimes is and affects 'small deployments' like some of the smaller cloud instances (EC2 m3.medium for example is only 4g). On the positive side: - better default performance (better out of the box experience for most customers) On the negative side: - will block some new users from even using Cassandra ( new to cloud and new to Cassandra I'd think ) - May break some existing 2.1.x deployments who are just relying on default (most) and have a tiny partition for commit log (I'd hope very very few) If we go this route we need to make sure the minimum requirements are updated in the docs and wiki correspondingly. It is also surprising in a point release to change a default. EDIT: I also agree the configuration have a comment different than the default is HYPER surprising and would be the first time I've even seen that in the wild. was (Author: rssvihla): Only negative and I've hit this, is the commit log filling up a small partition that previously was large enough. While I can safely say this should NEVER be a problem, it sometimes is and affects 'small deployments' like some of the smaller cloud instances (EC2 m3.medium for example is only 4g). On the positive side: - better default performance (better out of the box experience for most customers) On the negative side: - will block some new users from even using Cassandra ( new to cloud and new to Cassandra I'd think ) - May break some existing 2.1.x deployments who are just relying on default (most) and have a tiny partition for commit log (I'd hope very very few) If we go this route we need to make sure the minimum requirements are updated in the docs and wiki correspondingly. It is also surprising in a point release to change a default. Default commitlog_total_space_in_mb to 4G - Key: CASSANDRA-10013 URL: https://issues.apache.org/jira/browse/CASSANDRA-10013 Project: Cassandra Issue Type: Improvement Components: Config Reporter: Brandon Williams Fix For: 2.1.x First, it bothers me that we default to 1G but have 4G commented out in the config. More importantly though is more than once I've seen this lead to dropped mutations, because you have ~100 tables (which isn't that hard to do with OpsCenter and CFS and an application that uses a moderately high but still reasonable amount of tables itself) and when the limit is reached CLA flushes the oldest tables to try to free up CL space, but this in turn causes a flush stampede that in some cases never ends and backs up the flush queue which then causes the drops. This leaves you thinking you have a load shedding situation (which I guess you kind of do) but it would go away if you had just uncommented that config line. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10013) Default commitlog_total_space_in_mb to 4G
[ https://issues.apache.org/jira/browse/CASSANDRA-10013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14713012#comment-14713012 ] Ryan Svihla edited comment on CASSANDRA-10013 at 8/26/15 12:16 PM: --- Only negative, and I've hit this, is the commit log filling up a small partition that previously was large enough. While I can safely say this should NEVER be a problem, it sometimes is and affects 'small deployments' like some of the smaller cloud instances (EC2 m3.medium for example is only 4g). On the positive side: - better default performance (better out of the box experience for most customers) On the negative side: - will block some new users from even using Cassandra ( new to cloud and new to Cassandra I'd think ) - May break some existing 2.1.x deployments who are just relying on default (most) and have a tiny partition for commit log (I'd hope very very few) If we go this route we need to make sure the minimum requirements are updated in the docs and wiki correspondingly. It is also surprising in a point release to change a default. EDIT: I also agree the configuration having a comment different than the default is HYPER surprising and would be the first time I've even seen that in the wild. was (Author: rssvihla): Only negative and I've hit this, is the commit log filling up a small partition that previously was large enough. While I can safely say this should NEVER be a problem, it sometimes is and affects 'small deployments' like some of the smaller cloud instances (EC2 m3.medium for example is only 4g). On the positive side: - better default performance (better out of the box experience for most customers) On the negative side: - will block some new users from even using Cassandra ( new to cloud and new to Cassandra I'd think ) - May break some existing 2.1.x deployments who are just relying on default (most) and have a tiny partition for commit log (I'd hope very very few) If we go this route we need to make sure the minimum requirements are updated in the docs and wiki correspondingly. It is also surprising in a point release to change a default. EDIT: I also agree the configuration have a comment different than the default is HYPER surprising and would be the first time I've even seen that in the wild. Default commitlog_total_space_in_mb to 4G - Key: CASSANDRA-10013 URL: https://issues.apache.org/jira/browse/CASSANDRA-10013 Project: Cassandra Issue Type: Improvement Components: Config Reporter: Brandon Williams Fix For: 2.1.x First, it bothers me that we default to 1G but have 4G commented out in the config. More importantly though is more than once I've seen this lead to dropped mutations, because you have ~100 tables (which isn't that hard to do with OpsCenter and CFS and an application that uses a moderately high but still reasonable amount of tables itself) and when the limit is reached CLA flushes the oldest tables to try to free up CL space, but this in turn causes a flush stampede that in some cases never ends and backs up the flush queue which then causes the drops. This leaves you thinking you have a load shedding situation (which I guess you kind of do) but it would go away if you had just uncommented that config line. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
