[jira] [Updated] (CASSANDRA-8371) DateTieredCompactionStrategy is always compacting
[ https://issues.apache.org/jira/browse/CASSANDRA-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-8371: Labels: compaction dtcs performance (was: compaction performance) DateTieredCompactionStrategy is always compacting -- Key: CASSANDRA-8371 URL: https://issues.apache.org/jira/browse/CASSANDRA-8371 Project: Cassandra Issue Type: Bug Components: Core Reporter: mck Assignee: Björn Hegerfors Labels: compaction, dtcs, performance Attachments: java_gc_counts_rate-month.png, read-latency-recommenders-adview.png, read-latency.png, sstables-recommenders-adviews.png, sstables.png, vg2_iad-month.png Running 2.0.11 and having switched a table to [DTCS|https://issues.apache.org/jira/browse/CASSANDRA-6602] we've seen that disk IO and gc count increase, along with the number of reads happening in the compaction hump of cfhistograms. Data, and generally performance, looks good, but compactions are always happening, and pending compactions are building up. The schema for this is {code}CREATE TABLE search ( loginid text, searchid timeuuid, description text, searchkey text, searchurl text, PRIMARY KEY ((loginid), searchid) );{code} We're sitting on about 82G (per replica) across 6 nodes in 4 DCs. CQL executed against this keyspace, and traffic patterns, can be seen in slides 7+8 of https://prezi.com/b9-aj6p2esft/ Attached are sstables-per-read and read-latency graphs from cfhistograms, and screenshots of our munin graphs as we have gone from STCS, to LCS (week ~44), to DTCS (week ~46). These screenshots are also found in the prezi on slides 9-11. [~pmcfadin], [~Bj0rn], Can this be a consequence of occasional deleted rows, as is described under (3) in the description of CASSANDRA-6602 ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8371) DateTieredCompactionStrategy is always compacting
[ https://issues.apache.org/jira/browse/CASSANDRA-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-8371: --- Attachment: sstables-recommenders-adviews.png read-latency-recommenders-adview.png ( jira threaded comments [plugin|https://duckduckgo.com/l/?kh=-1uddg=https%3A%2F%2Fmarketplace.atlassian.com%2Fplugins%2Fcom.atlassian.jira.threadedcomments.threaded-comments] would be so nice :-) Attached is graphs from another keyspace+table. This data has TTL of 20 days, in total ~15Gb per replica. It's part of the data created in preparation for the spark ALS recommendation model generation. It's created from pig jobs that run every minute or two. So 50Mb of data is collected in ~1.6hrs. The schema is {code}CREATE TABLE ad_view ( userid bigint, type text, last_update timestamp, itemid bigint, dummy text, PRIMARY KEY ((userid, type), last_update, itemid) );{code} DateTieredCompactionStrategy is always compacting -- Key: CASSANDRA-8371 URL: https://issues.apache.org/jira/browse/CASSANDRA-8371 Project: Cassandra Issue Type: Bug Components: Core Reporter: mck Assignee: Björn Hegerfors Labels: compaction, performance Attachments: java_gc_counts_rate-month.png, read-latency-recommenders-adview.png, read-latency.png, sstables-recommenders-adviews.png, sstables.png, vg2_iad-month.png Running 2.0.11 and having switched a table to [DTCS|https://issues.apache.org/jira/browse/CASSANDRA-6602] we've seen that disk IO and gc count increase, along with the number of reads happening in the compaction hump of cfhistograms. Data, and generally performance, looks good, but compactions are always happening, and pending compactions are building up. The schema for this is {code}CREATE TABLE search ( loginid text, searchid timeuuid, description text, searchkey text, searchurl text, PRIMARY KEY ((loginid), searchid) );{code} We're sitting on about 82G (per replica) across 6 nodes in 4 DCs. CQL executed against this keyspace, and traffic patterns, can be seen in slides 7+8 of https://prezi.com/b9-aj6p2esft/ Attached are sstables-per-read and read-latency graphs from cfhistograms, and screenshots of our munin graphs as we have gone from STCS, to LCS (week ~44), to DTCS (week ~46). These screenshots are also found in the prezi on slides 9-11. [~pmcfadin], [~Bj0rn], Can this be a consequence of occasional deleted rows, as is described under (3) in the description of CASSANDRA-6602 ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8371) DateTieredCompactionStrategy is always compacting
[ https://issues.apache.org/jira/browse/CASSANDRA-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-8371: --- Description: Running 2.0.11 and having switched a table to [DTCS|https://issues.apache.org/jira/browse/CASSANDRA-6602] we've seen that disk IO and gc count increase, along with the number of reads happening in the compaction hump of cfhistograms. Data, and generally performance, looks good, but compactions are always happening, and pending compactions are building up. The schema for this is {code}CREATE TABLE search ( loginid text, searchid timeuuid, description text, searchkey text, searchurl text, PRIMARY KEY ((loginid), searchid) );{code} We're sitting on about 82G (per replica) across 6 nodes in 4 DCs. CQL executed against this keyspace, and traffic patterns, can be seen in slides 7+8 of https://prezi.com/b9-aj6p2esft/ Attached are sstables-per-read and read-latency graphs from cfhistograms, and screenshots of our munin graphs as we have gone from STCS, to LCS (week ~44), to DTCS (week ~46). These screenshots are also found in the prezi on slides 9-11. [~pmcfadin], [~Bj0rn], Can this be a consequence of occasional deleted rows, as is described under (3) in the description of CASSANDRA-6602 ? was: Running 2.0.11 and having switched a table to [DTCS|https://issues.apache.org/jira/browse/CASSANDRA-6602] we've seen that disk IO and gc count increase, along with the number of reads happening in the compaction hump of cfhistograms. Data, and generally performance, looks good, but compactions are always happening, and pending compactions are building up. The schema for this is {code}CREATE TABLE search ( loginid text, searchid timeuuid, description text, searchkey text, searchurl text, PRIMARY KEY ((loginid), searchid) );{code} We're sitting on about 82G (per replica) across 6 nodes in 4 DCs. CQL executed against this keyspace, and traffic patterns, can be seen in slides 7+8 of https://prezi.com/b9-aj6p2esft Attached are sstables-per-read and read-latency graphs from cfhistograms, and screenshots of our munin graphs as we have gone from STCS, to LCS (week ~44), to DTCS (week ~46). These screenshots are also found in the prezi on slides 9-11. [~pmcfadin], [~Bj0rn], Can this be a consequence of occasional deleted rows, as is described under (3) in the description of CASSANDRA-6602 ? DateTieredCompactionStrategy is always compacting -- Key: CASSANDRA-8371 URL: https://issues.apache.org/jira/browse/CASSANDRA-8371 Project: Cassandra Issue Type: Bug Components: Core Reporter: mck Assignee: Björn Hegerfors Labels: compaction, performance Attachments: java_gc_counts_rate-month.png, read-latency.png, sstables.png, vg2_iad-month.png Running 2.0.11 and having switched a table to [DTCS|https://issues.apache.org/jira/browse/CASSANDRA-6602] we've seen that disk IO and gc count increase, along with the number of reads happening in the compaction hump of cfhistograms. Data, and generally performance, looks good, but compactions are always happening, and pending compactions are building up. The schema for this is {code}CREATE TABLE search ( loginid text, searchid timeuuid, description text, searchkey text, searchurl text, PRIMARY KEY ((loginid), searchid) );{code} We're sitting on about 82G (per replica) across 6 nodes in 4 DCs. CQL executed against this keyspace, and traffic patterns, can be seen in slides 7+8 of https://prezi.com/b9-aj6p2esft/ Attached are sstables-per-read and read-latency graphs from cfhistograms, and screenshots of our munin graphs as we have gone from STCS, to LCS (week ~44), to DTCS (week ~46). These screenshots are also found in the prezi on slides 9-11. [~pmcfadin], [~Bj0rn], Can this be a consequence of occasional deleted rows, as is described under (3) in the description of CASSANDRA-6602 ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)