If this is a tombstone problem as suggested by some, and it is ok to turn of replication as suggested by others, it may be an idea to do an optimization in cassandra where
if replication_factor < 1: do not create tombstones Terje On Jul 2, 2013, at 11:11 PM, Dmitry Olshansky <dmitry.olshan...@gridnine.com> wrote: > In our case we have continuous flow of data to be cached. Every second we're > receiving tens of PUT requests. Every request has 500Kb payload in average > and TTL about 20 minutes. > > On the other side we have the similar flow of GET requests. Every GET request > is transformed to "get by key" query for cassandra. > > This is very simple and straightforward solution: > - one CF > - one key that is directly corresponds to cache entry key > - one value of type bytes that corresponds to cache entry payload > > To be honest, I don't see how we can switch this solution to multi-CF scheme > playing with time-based snapshots. > > Today this solution crashed again with overload symptoms: > - almost non-stop compactifications on every node in cluster > - large io-wait in the system > - clients start failing with timeout exceptions > > At the same time we see that cassandra uses only half of java heap. How we > can enforce it to start using all available resources (namely operating > memory)? > > Best regards, > Dmitry Olshansky
