Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 6 Jun 2016 05:47:59 +0000 (UTC)
From: "Jeff Jirsa (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12975599.1464982390000.38007.1465192079394@Atlassian.JIRA>
In-Reply-To: <JIRA.12975599.1464982390000@Atlassian.JIRA>
References: <JIRA.12975599.1464982390000@Atlassian.JIRA> <JIRA.12975599.1464982390593@arcas>
Subject: [jira] [Commented] (CASSANDRA-11955) Impossibly large value
 displayed for data "load" and "Space used (*):"
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 06 Jun 2016 05:48:06 -0000


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

Jeff Jirsa commented on CASSANDRA-11955:
----------------------------------------

Sounds a lot like CASSANDRA-11215 (which should have been fixed in 3.0.5) - any errors during repairs or indications of leaked references? 

> Impossibly large value displayed for data "load" and "Space used (*):"
> ----------------------------------------------------------------------
>
>                 Key: CASSANDRA-11955
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11955
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Compaction
>            Reporter: Nate McCall
>
> The data load as reported by nodetool views looks like it is not getting updated correctly (from compaction?):
> {noformat}
> # nodetool status
> Datacenter: dc1
> ==============
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> --  Address         Load       Tokens       Owns (effective)  Host ID                               Rack
> UJ  [redacted]   1.1 GB     256          ?                 0dfd164c-b874-4e90-be2c-3fea8e12d78e  a
> UN  [redacted]   14.96 TB   256          49.0%             02821ddb-a463-4845-b2ca-bed1da141e81  a
> UN  [redacted] 31.94 TB   256          51.2%             30531bfe-fe0e-4360-a22b-36bf200a9679  e
> UN  [redacted]   1.81 TB    256          54.0%             17a93464-41c4-49f8-8042-b2741c5e3256  d
> UN  [redacted]   22.2 TB    256          46.0%             f35b4aeb-33e5-4f53-bc9d-49de3a157e3e  d
> UN  [redacted]    28.53 TB   256          51.0%             74e04517-de70-4754-82fc-2dc867a14ae7  a
> UN  [redacted]  39.25 TB   256          48.8%             3a271443-db02-4487-be52-d6c35b66da40  e
> {noformat}
> NOTE: unknown if the join is related as the "TB" vs. "GB" discrepancy was only noticed after the join started.
> And same for {{nodetool tablestats}} details of the {{30531bfe...}} node: 
> {noformat}
> # nodetool tablestats
> Keyspace: myks
>     Read Count: 1306765640
>     Read Latency: 0.22125289495291597 ms.
>     Write Count: 3375354023
>     Write Latency: 0.017621884565795665 ms.
>     Pending Flushes: 0
>         Table: mytable
>         SSTable count: 110
>         Space used (live): 31374649977187
>         Space used (total): 31374649977187
>         Space used by snapshots (total): 0
> ...
> {noformat}
> Nothing fancy on this table (there is only one active table on this cluster): STCS with defaults, no MVs, no indexes just text and int columns with a single value partition key. 
> NOTE: once restarted, the values then display as correct, creeping up from there (thus my thinking that this is a compaction issue). 


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