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 <http://www.datastax.com/dev/blog/advanced-request-tracing-in-cassandra-1-2> > On 7 Nov 2014, at 20:20, Jonathan Haddad <j...@jonhaddad.com> wrote: > > 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 statement > on a slow query, then use tracing to identify exactly what happened. This > way finding your problem is not a matter of chance. > > > > On Fri Nov 07 2014 at 9:41:38 AM Chris Lohfink <clohfin...@gmail.com > <mailto:clohfin...@gmail.com>> wrote: > 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 <y2klyf+w...@gmail.com > <mailto:y2klyf+w...@gmail.com>> 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)? > > More sampling seems better but then doing so may also slow down the system in > some other ways? > > thanks > > >
