[
https://issues.apache.org/jira/browse/CASSANDRA-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926365#action_12926365
]
Jonathan Ellis commented on CASSANDRA-1675:
-------------------------------------------
One solution: drop the new logging lines and just add "X ops out of Y
threshold, W bytes out of Z throughput, M minutes out of T max age" when it
actually gets frozen
> log which memtable threshold has been hit
> -----------------------------------------
>
> Key: CASSANDRA-1675
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1675
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Robert Coli
> Assignee: Robert Coli
> Priority: Minor
> Fix For: 0.7.0
>
> Attachments:
> log.which.memtable.threshold.has.been.hit.against.0.6.at.1027222.patch,
> log.which.memtable.threshold.has.been.hit.against.trunk.1027208.patch
>
>
> There are three different tunable settings available for memtable sizing.
> Tuning these is an important task to operations centric people, because it
> relates to JVM memory management. Currently, the code logs when you have hit
> one of the three thresholds, but it does not tell you which of the three you
> have hit.
> Attached patches against 0.6 and 0.7 branches add a log message for each of
> the thresholds, indicating which one has been reached. If you were to find
> yourself in the somewhat unlikely case of simultaneously hitting more than
> one, the new code would only tell you which one you hit first, because that's
> all the current codepath cares about.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
