ferent nodes.
>
>
> What tasks were dropped.
>
> The cluster doesn't look completely healthy, but I believe it is possible
> to improve things, before thinking about splitting tables in multiples
> cluster. I would definitely not add more tables though...
>
> C*heers,
running
> (default is 10 sec timeout, so many query are probably failing).
>
> C*heers,
> ---
> Alain Rodriguez - @arodream - al...@thelastpickle.com
> France
>
> The Last Pickle - Apache Cassandra Consulting
> http://www.thelastpickle.com
>
> 20
nfo + related column info)..
>
> > You also might need to increase the node count if you're resource
> constrained.
>
> More nodes won't help and most probably make it worse due to coordination.
>
>
> Zhao Yang
>
>
>
> On Fri, 21 Apr 2017 at 21:10 Bohda
Hi,
Problem is still not solved. Does anybody have any idea what to do with it?
Thanks
2017-04-20 15:05 GMT+03:00 Bohdan Tantsiura :
> Thanks Carlos,
>
> In each keyspace we also have 11 MVs.
>
> It is impossible to reduce number of tables now. Long GC Pauses take about
> o
ter: @cjrolo | Skype: cjr2k3 | Linkedin:
> *linkedin.com/in/carlosjuzarterolo
> <http://linkedin.com/in/carlosjuzarterolo>*
> Mobile: +351 918 918 100 <+351%20918%20918%20100>
> www.pythian.com
>
> On Thu, Apr 20, 2017 at 11:10 AM, Bohdan Tantsiura
> wro
Hi,
We are using cassandra 3.10 in a 10 nodes cluster with replication = 3.
MAX_HEAP_SIZE=64GB on all nodes, G1 GC is used. We have about 60 keyspaces
with about 80 tables in each keyspace. We had to delete three tables and
two materialized views from each keyspace. It began to take more and more
