[ https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986642#comment-13986642 ]
Michael Shuler commented on CASSANDRA-6694: ------------------------------------------- Comparing the default 2.1 dtest runs with offheap dtest runs shows the same results: http://cassci.datastax.com/job/cassandra-2.1_dtest/132/ http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/4/ The 2.1 unit tests got a default config with this commit for "memtable_allocation_type: offheap_objects" and they appear pretty stable. (some new unit test errors have come up since CASSANDRA-6855, but no big regression appears to have come from this commit) > 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 > > Attachments: 6694.fix1.txt > > > 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.2#6252)