RE: Problem with dropped mutations
Are you also seeing time-outs on certain Cassandra operations?? If yes, you may have to tweak *request_timeout parameter in order to get rid of dropped mutation messages if application data model is not upto mark! You can also check if network isn't dropping packets (ifconfig -a tool) + storage (dstat tool) isn't reporting too slow disks. Cheers/Asad -Original Message- From: Hannu Kröger [mailto:hkro...@gmail.com] Sent: Tuesday, June 26, 2018 9:49 AM To: user Subject: Problem with dropped mutations Hello, We have a cluster with somewhat heavy load and we are seeing dropped mutations (variable amount and not all nodes have those). Are there some clear trigger which cause those? What would be the best pragmatic approach to start debugging those? We have already added more memory which seemed to help somewhat but not completely. Cheers, Hannu - To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org - To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org
Re: Problem with dropped mutations
Hannu, Dropped mutations are often a sign of load-shedding due to an overloaded node or cluster. Are you seeing resource saturation like high CPU usage (because the write path is usually CPU-bound) on any of the nodes in your cluster? Some potential contributing factors that might be causing you to drop mutations are long garbage collection (GC) pauses or large partitions. Do the drops coincide with an increase in requests, a code change, or compaction activity? On Tue, Jun 26, 2018 at 7:48 AM, Hannu Kröger wrote: > Hello, > > We have a cluster with somewhat heavy load and we are seeing dropped > mutations (variable amount and not all nodes have those). > > Are there some clear trigger which cause those? What would be the best > pragmatic approach to start debugging those? We have already added more > memory which seemed to help somewhat but not completely. > > Cheers, > Hannu > > > > - > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > > -- *Joshua Galbraith *| Senior Software Engineer | New Relic
Problem with dropped mutations
Hello, We have a cluster with somewhat heavy load and we are seeing dropped mutations (variable amount and not all nodes have those). Are there some clear trigger which cause those? What would be the best pragmatic approach to start debugging those? We have already added more memory which seemed to help somewhat but not completely. Cheers, Hannu - To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org
Re: Thrift to CQL migration under new Keyspace or Cluster
For while only in local machine, but we will do it in test environment. Thanks. 2018-06-25 16:15 GMT+08:00 dinesh.jo...@yahoo.com.INVALID < dinesh.jo...@yahoo.com.invalid>: > If you're working in a different keyspace, I don't anticipate any issues. > Have you attempted one in a test cluster? :) > > Dinesh > > > On Friday, June 22, 2018, 1:26:56 AM PDT, Fernando Neves < > fernando1ne...@gmail.com> wrote: > > > Hi guys, > We are running one of our Cassandra cluster under 2.0.17 Thrift version > and we started the 2.0.17 CQL migration plan through > CQLSSTableWriter/sstableloader method. > > Simple question, maybe someone worked in similar scenario, is there any > problem to do the migration under the same Cassandra instances (nodes) but > in different keyspace (ks_thrift to ks_cql) or should we create another > 2.0.17 cluster to do this work? > I know that new keyspace will require more host resources but it will be > more simple for us, because once the table migrated we will drop it on the > old ks_thrift keyspace. > > Thanks, > Fernando. >
