>
>
> - Heap size is set to 8GB
> - Using G1GC
> - I tried moving the memtable out of the heap. It helped but I still got
> an OOM last night
> - Concurrent compactors is set to 1 but it still happens and also tried
> setting throughput between 16 and 128, no changes.
>
That heap size is way to sm
Yeah, they are pretty much unique but it's only a few requests per day so
hitting all the nodes would be fine for now.
2018-04-05 15:43 GMT+02:00 Evelyn Smith :
> Not sure if it differs for SASI Secondary Indexes but my understanding is
> it’s a bad idea to use high cardinality columns for Second
Not sure if it differs for SASI Secondary Indexes but my understanding is it’s
a bad idea to use high cardinality columns for Secondary Indexes.
Not sure what your data model looks like but I’d assume UUID would have very
high cardinality.
If that’s the case it pretty much guarantees any query
Tried both (although with the biggest table) and the result is the same.
I stumbled upon this jira issue: https://issues.apache.
org/jira/browse/CASSANDRA-12662
Since the sasi indexes I use are only helping in debugging (for now) I
dropped them and it seems the tables get compacted now (at least i
Oh and second, are you attempting a major compact while you have all those
pending compactions?
Try letting the cluster catch up on compactions. Having that many pending is
bad.
If you have replication factor of 3 and quorum you could go node by node and
disable binary, raise concurrent compac
Probably a dumb question but it’s good to clarify.
Are you compacting the whole keyspace or are you compacting tables one at a
time?
> On 5 Apr 2018, at 9:47 pm, Zsolt Pálmai wrote:
>
> Hi!
>
> I have a setup with 4 AWS nodes (m4xlarge - 4 cpu, 16gb ram, 1TB ssd each)
> and when running the
