Hi,
Is your OOM on heap or on native memory ? Since 2.1 put a lot of things on
native memory I would say that it is almost always bad to have 6 GB out of
8 for the heap (unless you have a very small data set), since in the 2 GB
remaining you have to keep bloom filters, indexes and more + Page
On Sat, Jun 13, 2015 at 4:39 AM, Oleksandr Petrov
oleksandr.pet...@gmail.com wrote:
We're using Cassandra, recently migrated to 2.1.6, and we're experiencing
constant OOMs in one of our clusters.
Maybe this memory leak?
https://issues.apache.org/jira/browse/CASSANDRA-9549
=Rob
The commitlog size is likely a red herring. In 2.0 we had 1gb commitlogs by
default. In 2.1 we have 8gb commitlogs by default. This is configurable at
the yaml.
Not sure what's causing the OOM. Did it generate an hprof file you can
analyze?
On Jun 13, 2015 7:42 AM, Oleksandr Petrov
Sorry I completely forgot to mention it in an original message: we have
rather large commitlog directory (which is usually rather small), 8G of
commitlogs. Draining and flushing didn't help.
On Sat, Jun 13, 2015 at 1:39 PM, Oleksandr Petrov
oleksandr.pet...@gmail.com wrote:
Hi,
We're using
Hi,
We're using Cassandra, recently migrated to 2.1.6, and we're experiencing
constant OOMs in one of our clusters.
It's a rather small cluster: 3 nodes, EC2 xlarge: 2CPUs, 8GB RAM, set up
with datastax AMI.
Configs (yaml and env.sh) are rather default: we've changed only concurrent
compactions
