Re: How is Cassandra being used?
On Wed, Nov 16, 2011 at 11:32 AM, Jonathan Ellis wrote: > I don't think the cases are parallel. Terracotta added this in (a) a > minor release, (b) without mentioning it in the release notes, and (c) > without a method to disable it. for c) it can be disabled :) Just curious, who owns this Phone home data - ASF? thanks ashish
Re-adding a dead node in Cassandra 3.9
Hi, Our Cassandra cluster uses Cassandra version 3.9. We experienced an issue for which documentation doesn't seem clear and I'm hoping someone experienced the same issue and we could use some help. One of Cassandra node went down and now the host needs to be rebuilt and OS needs to be reinstalled and then it can be brought back again to be part of the cluster. The host will have same IP as before. What steps should be performed for re-adding dead node again? Needless to say, data in the dead host after it's back is lost. Thanks Ashish
C* data validation in new DC
Hi All We are running 2.0.14 and recently added new cassandra datacenter to the existing datacenter. Wondering, if there is a recommended way in cassandra to check data completely sync'ed in new datacenter other than *nodetool cfstats *which just gives estimate of number of keys Thanks in advance Ashish
Cassandra Compactions Speed increase
Hi All, We are using cassandra 3.9 and experiencing read latency issues. We are using LeveledCompactionStrategy after experiencing read latency issue with SizeTieredCompactionStrategy. For our use case, table keys are getting batch updated and batch delete of column values for keys. We almost write to entire set of keys everyday. After switching to leveledcompactionstrategy read latency for the table has improved but we see that compaction takes lot of time (6-8hrs) and if the reads have to happen before compactions are reasonably done, latency is severly impacted. Is there way to increase the speed of compactions as the system resources are available in our use case for compaction to run faster after batch update and delete are run? This article https://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets suggests this is an anti-pattern for cassandra for such use cases, but I would like to try if increase in compaction speed could help. Thanks very much, appreciate responses. Ashish
Re: Cassandra Compactions Speed increase
I haven't throttled cassandra compactions. My assumption is that because we are running lot of batch jobs which can updates or delete partition key, number of compactions are too many to finish in time which i see in nodetool compactionstats pending tasks. Multiple Batch write (and delete) of partition keys. Each batch can have overlap of partition keys. High throughput read after couple of hours multiple batch writes On Fri, Sep 15, 2017 at 9:07 PM, Jeff Jirsa wrote: > Do you have compaction throttled now? > What exactly takes 6-8 hours? > Are you writing all the keys at one time, then reading, then deleting them > all, or is it a constant stream of writes and reads? > > > -- > Jeff Jirsa > > > > On Sep 15, 2017, at 8:40 PM, Ashish Pandey wrote: > > > > Hi All, > > > > We are using cassandra 3.9 and experiencing read latency issues. > > > > We are using LeveledCompactionStrategy after experiencing read latency > > issue with SizeTieredCompactionStrategy. For our use case, table keys are > > getting batch updated and batch delete of column values for keys. We > almost > > write to entire set of keys everyday. > > After switching to leveledcompactionstrategy read latency for the table > > has improved but we see that compaction takes lot of time (6-8hrs) and if > > the reads have to happen before compactions are reasonably done, latency > is > > severly impacted. Is there way to increase the speed of compactions as > the > > system resources are available in our use case for compaction to run > faster > > after batch update and delete are run? > > > > This article > > https://www.datastax.com/dev/blog/cassandra-anti-patterns- > queues-and-queue-like-datasets > > suggests > > this is an anti-pattern for cassandra for such use cases, but I would > like > > to try if increase in compaction speed could help. > > > > Thanks very much, appreciate responses. > > > > Ashish > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Cassandra Compactions Speed increase
Thanks!, I will try out changing concurrent compactors and provide more info for further help after trying. I agree that I haven't provided any info to get help :). Performance is disk bound (I think the reason is L0 use STCS), host stats doesn't show any significant CPU and Load. Read latency is impacted (tp99 > 200ms) in high throughput. Once the compaction settles, read latency improves (free disk increases, disk utlitization drops in reads) On Fri, Sep 15, 2017 at 9:43 PM, Jeff Jirsa wrote: > Check your settings for concurrent compactors (in your yaml) and > throughput (can check and set with nodetool) - both of those can be adjusted > > Beyond that you need to give a bit more info to help us help you - are you > CPU bound, disk bound, is the read load the limiter or is compaction? We > need graphs or thread pool stats or something - there's a hundred or a > thousand things to tune, and you've given almost no info for us to tell you > which to look at first > > > -- > Jeff Jirsa > > > > On Sep 15, 2017, at 9:29 PM, Ashish Pandey wrote: > > > > I haven't throttled cassandra compactions. My assumption is that because > we > > are running lot of batch jobs which can updates or delete partition key, > > number of compactions are too many to finish in time which i see in > > nodetool compactionstats pending tasks. > > > > Multiple Batch write (and delete) of partition keys. Each batch can have > > overlap of partition keys. High throughput read after couple of hours > > multiple batch writes > > > >> On Fri, Sep 15, 2017 at 9:07 PM, Jeff Jirsa wrote: > >> > >> Do you have compaction throttled now? > >> What exactly takes 6-8 hours? > >> Are you writing all the keys at one time, then reading, then deleting > them > >> all, or is it a constant stream of writes and reads? > >> > >> > >> -- > >> Jeff Jirsa > >> > >> > >>> On Sep 15, 2017, at 8:40 PM, Ashish Pandey > wrote: > >>> > >>> Hi All, > >>> > >>> We are using cassandra 3.9 and experiencing read latency issues. > >>> > >>> We are using LeveledCompactionStrategy after experiencing read latency > >>> issue with SizeTieredCompactionStrategy. For our use case, table keys > are > >>> getting batch updated and batch delete of column values for keys. We > >> almost > >>> write to entire set of keys everyday. > >>> After switching to leveledcompactionstrategy read latency for the table > >>> has improved but we see that compaction takes lot of time (6-8hrs) and > if > >>> the reads have to happen before compactions are reasonably done, > latency > >> is > >>> severly impacted. Is there way to increase the speed of compactions as > >> the > >>> system resources are available in our use case for compaction to run > >> faster > >>> after batch update and delete are run? > >>> > >>> This article > >>> https://www.datastax.com/dev/blog/cassandra-anti-patterns- > >> queues-and-queue-like-datasets > >>> suggests > >>> this is an anti-pattern for cassandra for such use cases, but I would > >> like > >>> to try if increase in compaction speed could help. > >>> > >>> Thanks very much, appreciate responses. > >>> > >>> Ashish > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > >> > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Question on commit log
Hi, Does Cassandra always have an additional commit log file created and ready to go while it is actively writing to previous commit log or does it create a commit log file on demand (when it actually needs it)? Thanks Ashish The information contained in this e-mail is considered confidential of SK hynix memory solutions Inc. and intended only for the persons addressed or copied in this e-mail. Any unauthorized use, dissemination of the information, or copying of this message is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email.
