Re: compaction throughput

LCS is IO ontensive but CPU is also relevant. On slower disks compaction may not be cpu bound. If you aren't seeing more than one compaction thread at a time, I suspect your system is not compaction bound. all the best, Sebastián On Jan 15, 2016 7:20 PM, "Kai Wang" wrote: > Sebastian, > > Bec

Re: compaction throughput

Sebastian, Because I have this impression that LCS is IO intensive and it's recommended only on SSDs. So I am curious to see how far it can stress those SSDs. But it turns out the most expensive part about LCS is not IO bound but CUP bound, or more precisely single core speed bound. This is a litt

Re: compaction throughput

Correct. Why are you concerned with the raw throughput, are you accumulating pending compactions? Are you seeing high sstables per read statistics? all the best, Sebastián On Jan 15, 2016 6:18 PM, "Kai Wang" wrote: > Jeff & Sebastian, > > Thanks for the reply. There are 12 cores but in my case

Re: compaction throughput

Jeff & Sebastian, Thanks for the reply. There are 12 cores but in my case C* only uses one core most of the time. *nodetool compactionstats* shows there's only one compactor running. I can see C* process only uses one core. So I guess I should've asked the question more clearly: 1. Is ~25 M/s a r

Re: compaction throughput

With SSDs, the typical recommendation is up to 0.8-1 compactor per core (depending on other load). How many CPU cores do you have? From: Kai Wang Reply-To: "user@cassandra.apache.org" Date: Friday, January 15, 2016 at 12:53 PM To: "user@cassandra.apache.org" Subject: compaction throughput

Re: compaction throughput

*nodetool setcompactionthroughput 0* Will only affect future compactions, not the ones that are currently running. All the best, [image: datastax_logo.png] Sebastián Estévez Solutions Architect | 954 905 8615 | sebastian.este...@datastax.com [image: linkedin.png]

Re: compaction throughput

Compaction is generally CPU bound and relatively slow. Exactly why that is I’m uncertain. > On Jan 15, 2016, at 12:53 PM, Kai Wang wrote: > > Hi, > > I am trying to figure out the bottleneck of compaction on my node. The node > is CentOS 7 and has SSDs installed. The table is configured to us

Re: compaction throughput

I forget to mention I am using C* 2.2.4 On Jan 15, 2016 3:53 PM, "Kai Wang" wrote: > Hi, > > I am trying to figure out the bottleneck of compaction on my node. The > node is CentOS 7 and has SSDs installed. The table is configured to use > LCS. Here is my compaction related configs in cassandra.y

compaction throughput

Hi, I am trying to figure out the bottleneck of compaction on my node. The node is CentOS 7 and has SSDs installed. The table is configured to use LCS. Here is my compaction related configs in cassandra.yaml: compaction_throughput_mb_per_sec: 160 concurrent_compactors: 4 I insert about 10G of da

Re: Impact of Changing Compaction Strategy

When you change compaction strategy, nothing happens until the next flush. On the next flush, the new compaction strategy will decide what to do – if you change from STCS to DTCS, it will look at various timestamps of files, and attempt to group them by time windows based on the sstable’s minTim

Re: CQL Composite Key Seen After Table Creation

On 01/06/2016 04:47 PM, Robert Coli wrote: On Wed, Jan 6, 2016 at 12:54 PM, Chris Burroughs wrote: The problem with that approach is that manually editing the local schema tables in live cluster is wildly dangerous. I *think* this would work: * Make triple sure no schema changes are happeni

Impact of Changing Compaction Strategy

Hi, I need to understand whether all existing sstables are recreated/updated when we change compaction strategy from STCS to DTCS? Sstables are immutable by design but do we take an exception for such cases and update same files when an Alter statement is fired to change the compaction strategy

Re: Cassandra 3.1.1 with respect to HeapSpace

Thank you Sebastián! On 15 Jan 2016, at 19:09 , Sebastian Estevez mailto:sebastian.este...@datastax.com>> wrote: The recommended (and default when available) heap size for Cassandra is 8GB and for New size it's 100mb per core. Your milage may vary based on workload, hardware etc. There are al

Re: Cassandra 3.1.1 with respect to HeapSpace

The recommended (and default when available) heap size for Cassandra is 8GB and for New size it's 100mb per core. Your milage may vary based on workload, hardware etc. There are also some alternative JVM tuning schools of thought. See cassandra-8150 (large heap) and CASSANDRA-7486 (G1GC). All

Re: electricity outage problem

our case is not about accepting connection, some nodes receives gossip generation number greater the local one, a looked at the tables peers and local and can't found where local one is stored. 2016-01-15 17:54 GMT+01:00 daemeon reiydelle : > Nodes need about 60-90 second delay before it can star

Re: electricity outage problem

Nodes need about 60-90 second delay before it can start accepting connections as a seed node. Also a seed node needs time to accept a node starting up, and syncing to other nodes (on 10gbit the max new nodes is only 1 or 2, on 1gigabit it can handle at least 3-4 new nodes connecting). In a large cl

Re: electricity outage problem

Hi, we did full restart of the cluster but nodetool status still giving incoerent info from different nodes, some nodes appers UP from a node but appers DOWN from another, and in the log as is said still having the message "received an invalid gossip generation for peer /x.x.x.x" cassandra version

Re: Sorting & pagination in apache cassandra 2.1

Hi Anuja. Yeah, that's what he means. Before Cassandra 3.0 the modelling advice is to have one table per query. This may sound weird from a relational perspective, but the truth is that writes in Cassandra are very cheap, and its better to write multiple times and have quick and easy reads than wr

Re: Cassandra 3.1.1 with respect to HeapSpace

Thank you Sebastián for your useful advice. I managed restarting the nodes, but I needed to delete all the commit logs, not only the last one specified. Nevertheless I’m back in business. Would there be a better memory configuration to select for my nodes in a C* 3 cluster? Currently I use MAX_