[
https://issues.apache.org/jira/browse/CASSANDRA-6689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911646#comment-13911646
]
Benedict commented on CASSANDRA-6689:
-------------------------------------
As far as performance testing is concerned, I would say we should test
CASSANDRA-6694, as this should be faster in general (excluding its caveats),
and also make sure we're running with cassandra.paranoidgc=off (as this has
negative performance implications). Also, there are some issues with
performance with places in the codebase we've assumed heap based bytebuffers,
and have slow routes otherwise. I didn't see such a reduction in performance in
my tests, though, so I will have to investigate that a bit more thoroughly.
There is an issue with SequentialWriter that it expects a byte[], so with DBB
we are writing one byte at a time. I optimised this single-byte path, though,
and found my performance problems disappeared then.
Some quick off the cuff answers to some of your points:
bq. Should we add QueryProcessor.process(<without RefAction>) methods to avoid
all the RefAction.allocateOnHeap() methods? Or, perhaps it is good to always
force people to think about where they want the data.
I think the latter. It's not too onerous, and it's better to be forced to think
about it IMO.
bq. a rebase on 2.1 would be nice, does not work running in a cluster now.
CASSANDRA-6694 is fully up-to-date, but I guess if you'd prefer to split it up
further, skipping ahead to include more changes might be off the cards :-)
I'll see about merging it with your changes and 2.1, and then remerging 6694 as
well.
bq. Also, just throwing the idea out here, maybe we should make this a separate
library?
bq. Make OpOrder.Group and RefAction implement AutoClosable to be able to do
try-with-resources?
Good ideas.
bq. Would be nice if we didn't have to copy data to heap for thrift queries,
but i guess that is out of scope for now.
Yes, and thrift users can continue with heap allocation if they're worried
about this overhead. But since it's transient they might want to benefit from
the reduced heap size even if it means more frequent ygen collections.
I'll have a look over your changes more closely and respond to the rest later.
> Partially Off Heap Memtables
> ----------------------------
>
> Key: CASSANDRA-6689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6689
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Fix For: 2.1 beta2
>
>
> Move the contents of ByteBuffers off-heap for records written to a memtable.
> (See comments for details)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
