cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2252) off-heap memtables
Date Thu, 14 Jul 2011 09:23:01 GMT


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:
>             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:


View raw message