[jira] Resolved: (CASSANDRA-1675) log which memtable threshold has been hit

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

     [ https://issues.apache.org/jira/browse/CASSANDRA-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Ellis resolved CASSANDRA-1675.
---------------------------------------

    Resolution: Not A Problem

we already log

{code}Enqueuing flush of Memtable-Standard1@1015483951(15792915 bytes, 309665 operations){code}

which seems quite adequate to me to tell that we're hitting the .3M ops threshold rather than the 64MB throughput one. 

will revert the change.

> 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.