Can't think of any.
On Sun, Jul 17, 2011 at 1:27 PM, Andrey Stepachev wrote:
> Looks like problem in code:
> public IndexSummary(long expectedKeys)
> {
> long expectedEntries = expectedKeys /
> DatabaseDescriptor.getIndexInterval();
> if (expectedEntries > Integer.MAX_VALU
Looks like problem in code:
public IndexSummary(long expectedKeys)
{
long expectedEntries = expectedKeys /
DatabaseDescriptor.getIndexInterval();
if (expectedEntries > Integer.MAX_VALUE)
// TODO: that's a _lot_ of keys, or a very low interval
throw n
Looks like key indexes eat all memory:
http://paste.kde.org/97213/
2011/7/15 Andrey Stepachev
> UPDATE:
>
> I found, that
> a) with min10G cassandra survive.
> b) I have ~1000 sstables
> c) CompactionManager uses PrecompactedRows instead of LazilyCompactedRow
>
> So, I have a question:
> a) if
UPDATE:
I found, that
a) with min10G cassandra survive.
b) I have ~1000 sstables
c) CompactionManager uses PrecompactedRows instead of LazilyCompactedRow
So, I have a question:
a) if row is bigger then 64mb before compaction, why it compacted in memory
b) if it smaller, what eats so much memory?
Hi all.
Cassandra constantly OOM on repair or compaction. Increasing memory doesn't
help (6G)
I can give more, but I think that this is not a regular situation. Cluster
has 4 nodes. RF=3.
Cassandra version 0.8.1
Ring looks like this:
Address DC RackStatus State Load
