On Dec 27, 2010, at 14:34, Timo Nentwig wrote:
> On Dec 24, 2010, at 14:33, Timo Nentwig wrote:
>> Any advice what to do with it?
>
> So, to continue this monologue: I reduced the memtable size for that CF and
> the by means of the MBeans figured out that the secondary index is a CF as
> well which presumably also holds up to 3 memtables in memory...that would
> explain why it runs OOM.
Hm. I was wrong. In order to somehow stop cassandra to continue to build the
index I deleted system CF and reimported the schema with modified memtable
flush parameters. But apparently the information to build the secondary index
is stored in the CF's metadata, so shortly after it starts indexing again and
the index shows up in mbeans.
However: data is never flushed and grows endlessly because of
(ColumnFamilyStore):
if (DatabaseDescriptor.getCFMetaData(metadata.cfId) == null)
return null; // column family was dropped. no point in flushing.
Did I hit some problem here or is the data just messed up (was build with rc1,
rc2 and I removed system CF). Sigh...
> Anyway, I created an issue (affect rc2 beause there's yet no rc3 to select in
> Jira) for the crash at startup: CASSANDRA-1904.
