[
https://issues.apache.org/jira/browse/CASSANDRA-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13864826#comment-13864826
]
Benedict commented on CASSANDRA-6544:
-------------------------------------
Yep, think it's a great idea. Not totally certain if a "slab" allocator or just
a single BB per source file that is ~10% larger than the largest row we've
visited (with a lower bound of, say, 16K to start with) would do - probably
simpler and makes dealing with columns larger than a slab easier, and if we
don't share we can safely recycle after every row merge. Will require pulling
apart some of the deserializers to support the allocator.
> Reduce GC activity during compaction
> ------------------------------------
>
> Key: CASSANDRA-6544
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6544
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Vijay
> Assignee: Vijay
> Fix For: 2.1
>
>
> We are noticing increase in P99 while the compactions are running at full
> stream. Most of it is because of the increased GC activity (followed by full
> GC).
> The obvious solution/work around is to throttle the compactions, but with
> SSD's we can get more disk bandwidth for reads and compactions.
> It will be nice to move the compaction object allocations off heap. First
> thing to do might be create a Offheap Slab allocator with the size as the
> compaction in memory size and recycle it.
> Also we might want to make it configurable so folks can disable it when they
> don't have off-heap memory to reserve.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
