It depends on a number of factors, such as compaction strategy and read
patterns. I recommend sticking to the 100MB per partition limit (and I aim
for significantly less than that).
If you're doing time series with TWCS & TTL'ed data and small enough
windows, and you're only querying for a small
I disagree.
We had several over 150MB in 3.11 and we were able to break cluster doing
r/w from these partitions in a short period of time.
On Thu, Sep 13, 2018, 12:42 Gedeon Kamga wrote:
> Folks,
>
> Based on the information found here
> https://docs.datastax.com/en/dse-planning/doc/planning/pl
Hi Gedeon,
you should check Robert Stupp's 2016 talk about large partitions :
https://www.youtube.com/watch?v=N3mGxgnUiRY
Cheers,
On Thu, Sep 13, 2018 at 6:42 PM Gedeon Kamga wrote:
> Folks,
>
> Based on the information found here
> https://docs.datastax.com/en/dse-plan
Folks,
Based on the information found here
https://docs.datastax.com/en/dse-planning/doc/planning/planningPartitionSize.html
,
the recommended limit for a partition size is 100MB. Even though, DataStax
clearly states that this is a rule of thumb, some team members are claiming
that our Cassandra *
e partition' The message could be different for
> the c* version you're using though. Plus, this doesn't show you all of the
> large partitions.
>
> There is a nice tool that analyzes sstables and can show the large
> partitions:
> https://github.com/tolbertam/s
system.log should show you some warnings about wide rows. Do a grep on
system.log for 'Writing large partition' The message could be different
for the c* version you're using though. Plus, this doesn't show you all of
the large partitions.
There is a nice tool that analy
Hi All,
I ran nodetool cfstats (v2.0.14) on a keyspace and found that there are a
few large partitions. I assume that since "Compacted partition maximum
bytes": 802187438 (~800 MB) and since
"Compacted partition mean bytes": 100465 (~100 KB), it means that most
partitions
What Cassandra version? CMS or G1? What are your timeouts set to?
"GC activity" - Even if there isn't a lot of activity per se maybe there
is a single long pause happening. I have seen large partitions cause lots
of allocation fast.
Looking at SSTable Levels in nodetool cfstats
that I need to redesign the table to avoid such large partitions. What
specifically goes wrong that results in the instability I am seeing? Or put
another way, what issues will compacting really large partitions cause?
Initially I thought that there was high GC activity, but after closer
inspection
