[
https://issues.apache.org/jira/browse/CASSANDRA-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065135#comment-13065135
]
Stu Hood commented on CASSANDRA-2252:
-------------------------------------
bq. And if they are so large they do not, then your rate of key allocation is
glacial and again it shouldn't matter.
Compaction builds up an IndexSummary slowly enough that I theorized it might be
causing fragmentation... didn't get a chance to prove it though.
bq. There is no logical unit of slabbing for key cache, we shouldn't be doing
that at all.
Agreed. We actually ended up disabling the key cache and saw a nice boost in
time-to-promotion-failure, but I would love to find an actual solution.
bq. Once you promoted a slab in old gen, it stays there, instead of being GC'd
and replaced with a slab in new gen again.
The bookkeeping might be worth it, yes.
> off-heap memtables
> ------------------
>
> Key: CASSANDRA-2252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2252
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 1.0
>
> Attachments: 0001-add-MemtableAllocator.txt,
> 0002-add-off-heap-MemtableAllocator-support.txt, 2252-v3.txt, merged-2252.tgz
>
> Original Estimate: 0.4h
> Remaining Estimate: 0.4h
>
> The memtable design practically actively fights Java's GC design. Todd
> Lipcon gave a good explanation over on HBASE-3455.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
