On 2017-07-13 07:49 (-0700), Felipe Esteves <felipe.este...@b2wdigital.com> wrote: > Hi, > > I have a Cassandra 2.1 cluster running on AWS that receives high read > loads, jumping from 100k requests to 400k requests, for example. Then it > normalizes and later cames another high throughput. > > To the application, it appears that Cassandra is slow. However, cpu and > disk use is ok in every instance, row cache is enabled and with almost 100% > hit rate. > > The logs from Cassandra instances doesn't have any errors, nor tombstone > messages or something liked that. It's mostly compactions and G1GC > operations. > > Any hints on where to investigate more? >
What compaction strategy are you using? How many writes/second are you doing? Is compaction keeping up? STCS has a little-known feature called "row lifting", where it can force re-compaction of data to avoid merging results from many sstables - this can occasionally account for a lot of extra disk IO (and gc) in high read clusters. Apart from that, how many sstables are you touching per read, or is it all coming straight out of row cache? If you're really seeing 90% row hit rates (good!), you may want to make sure you're caching enough of the partition that you don't have to read past what's cached - make sure your rows per partition setting is high enough (think it defaults to 100). --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org
