cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6694) Slightly More Off-Heap Memtables
Date Thu, 17 Apr 2014 20:53:17 GMT


Aleksey Yeschenko commented on CASSANDRA-6694:

bq. It's purpose is somewhat different, and I think it is better left named CounterUpdateCell,
as that is its purpose (to carry a counter update as far as the memtable, and no further).

FWIW it doesn't even make it to a memtable in 2.1, ever. That said, not calling it BufferCounterUpdateCell
would be bothering my consistency OCD, a lot, and I'm not done with counters until 3.0. Can
you make my OCD a tiny favor and call it consistently with the other implementations? (: Thanks.

bq. There should be no hashCode method in Buffer*Cell - I removed these for a reason. Because
we can have a Cell that is a CellName, and vice-versa, using a Cell as a key for a map is
likely dangerous. Since we don't do it anywhere, it's safe to simply remove the methods.

Maybe we should just throw UnsupportedOperationException then, but leave the methods? I agree
that using Cell-s as keys is very unlikely, but stuff like this has bitten us before.

Haven't read either branch yet, but planning to soon, just wanted to jump at the opportunity
to bikeshed a bit.

> Slightly More Off-Heap Memtables
> --------------------------------
>                 Key: CASSANDRA-6694
>                 URL:
>             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

View raw message