We're running largely default settings, with the exception of shard
(1) and replica (0-n) counts and EC2-related snitch etc. No row
caching at all. The logs never showed the same kind of entries
pre-OOM, it basically occurred out of the blue.
However, it seems that the problem has now subsided
2013/12/9 Nate McCall n...@thelastpickle.com:
Do you have any secondary indexes defined in the schema? That could lead to
a 'mega row' pretty easily depending on the cardinality of the value.
That's an interesting point - but no, we don't have any secondary
indexes anywhere. From the heap dump,
We're getting fairly reproducible OOMs on a 2-node cluster using
Cassandra 1.2.11, typically in situations with a heavy read load. A
sample of some stack traces is at
https://gist.github.com/KlausBrunner/7820902 - they're all failing
somewhere down from table.getRow(), though I don't know if
