cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Resolved: (CASSANDRA-1675) log which memtable threshold has been hit
Date Tue, 02 Nov 2010 16:42:26 GMT


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:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Robert Coli
>            Assignee: Robert Coli
>            Priority: Minor
>             Fix For: 0.7.0
>         Attachments:,
> 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.

View raw message