[
https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908198#comment-13908198
]
Benedict commented on CASSANDRA-6694:
-------------------------------------
Pushed an updated branch
[here|https://github.com/belliottsmith/cassandra/tree/offheap2a]
This is merged with latest changes in 2.1, and patches up a few oversights as
well as squashes the zillions of commits (I've left the prior branch intact in
case a reviewer wants to walk the history, particularly across the refactor).
[~mshuler]: For testing this, we're interested in inducing worst case behaviour
by, e.g., getting to a steady state where the memtables are full (might want to
jack memtable_cleanup_threshold to near to 1, so we can push it further. Also,
that makes me realise we should assert it is < 1 at startup :-) ), but using a
heavily clustered schema; say at least 3 clustering columns, all small, e.g.
ints. Use a small value column as well; maybe a double. Then pack a LOT of CQL
rows into a single partition. Say 1M+. Then we want to see what performance is
like querying from this. I expect it to be worse, but the question is how much
worse, and can we tolerate it? Probably want to run variants of this with a
mixed workload as well, but I expect any difference will be lost in the noise
of the current garbage heavy write layer.
Make sure you run this test connecting through native protocol, and for
comparison test against same version but with memtable_allocator set to
heap_slab. Make sure you tune memtable thresholds so they both retain the same
amount of data :-)
> Slightly More Off-Heap Memtables
> --------------------------------
>
> Key: CASSANDRA-6694
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6694
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Labels: performance
> Fix For: 2.1 beta2
>
>
> The Off Heap memtables introduced in CASSANDRA-6689 don't go far enough, as
> the on-heap overhead is still very large. It should not be tremendously
> difficult to extend these changes so that we allocate entire Cells off-heap,
> instead of multiple BBs per Cell (with all their associated overhead).
> The goal (if possible) is to reach an overhead of 16-bytes per Cell (plus 4-6
> bytes per cell on average for the btree overhead, for a total overhead of
> around 20-22 bytes). This translates to 8-byte object overhead, 4-byte
> address (we will do alignment tricks like the VM to allow us to address a
> reasonably large memory space, although this trick is unlikely to last us
> forever, at which point we will have to bite the bullet and accept a 24-byte
> per cell overhead), and 4-byte object reference for maintaining our internal
> list of allocations, which is unfortunately necessary since we cannot safely
> (and cheaply) walk the object graph we allocate otherwise, which is necessary
> for (allocation-) compaction and pointer rewriting.
> The ugliest thing here is going to be implementing the various CellName
> instances so that they may be backed by native memory OR heap memory.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
