Re: query tracing

2014-11-15 Thread Jimmy Lin
hi Jen, interesting idea, but I thought read repair happen in background, and so won't affect the actual read request calling from real client. ? On Sat, Nov 15, 2014 at 1:04 AM, Jens Rantil wrote: > Maybe you should try to lower your read repair probability? > > — > Sent from Mailbox

Re: query tracing

2014-11-15 Thread Jens Rantil
Maybe you should try to lower your read repair probability? — Sent from Mailbox On Sat, Nov 15, 2014 at 9:40 AM, Jimmy Lin wrote: > Well we are able to do the tracing under normal load, but not yet able to > turn on tracing on demand during heavy load from client side(due to hard to > predict

Re: query tracing

2014-11-15 Thread Jimmy Lin
Well we are able to do the tracing under normal load, but not yet able to turn on tracing on demand during heavy load from client side(due to hard to predict traffic pattern). under normal load we saw most of the time query spent (in one particular row we focus on) between merging data from memtab

Re: query tracing

2014-11-10 Thread DuyHai Doan
As Jonathan said, it's better to activate query tracing client side. It'll give you better flexibility of when to turn on & off tracing and on which table. Server-side tracing is global (all tables) and probabilistic, thus may not give satisfactory level of debugging. Programmatically it's pretty

Re: query tracing

2014-11-10 Thread Johnny Miller
Be cautious enabling query tracing. Great tool for dev/testing/diagnosing etc.. - but it does persist data to the system_traces keyspace with a TTL of 24 hours and will, as a consequence, consume resources. http://www.datastax.com/dev/blog/advanced-request-tracing-in-cassandra-1-2

Re: query tracing

2014-11-07 Thread Jonathan Haddad
Personally I've found that using query timing + log aggregation on the client side is more effective than trying to mess with tracing probability in order to find a single query which has recently become a problem. I recommend wrapping your session with something that can automatically log the sta

Re: query tracing

2014-11-07 Thread Chris Lohfink
It saves a lot of information for each request thats traced so there is significant overhead. If you start at a low probability and move it up based on the load impact it will provide a lot of insight and you can control the cost. --- Chris Lohfink On Fri, Nov 7, 2014 at 11:35 AM, Jimmy Lin wro

Re: query tracing

2014-11-07 Thread Robert Coli
On Fri, Nov 7, 2014 at 9:35 AM, Jimmy Lin wrote: > is there any significant performance penalty if one turn on Cassandra > query tracing, through DataStax java driver (say, per every query request > of some trouble query)? > What does 'significant' mean in your sentence? I'm pretty sure the ans