You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jeff Jirsa (JIRA)" <ji...@apache.org> on 2016/06/06 05:55:59 UTC
[jira] [Comment Edited] (CASSANDRA-11955) Impossibly large value
displayed for data "load" and "Space used (*):"
[ https://issues.apache.org/jira/browse/CASSANDRA-11955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15316220#comment-15316220 ]
Jeff Jirsa edited comment on CASSANDRA-11955 at 6/6/16 5:55 AM:
----------------------------------------------------------------
Sounds a lot like CASSANDRA-11209 - any errors during repairs or indications of leaked references?
was (Author: jjirsa):
Sounds a lot like CASSANDRA-11209 (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)