[
https://issues.apache.org/jira/browse/CASSANDRA-6544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13865388#comment-13865388
]
Benedict commented on CASSANDRA-6544:
-------------------------------------
Good point. I was looking at the 2.0 branch I briefly had checked out.
That said, it could still be beneficial, and would require an even smaller
buffer so less downside as well. No real need to move the buffer off heap, but
re-using a buffer could help avoid both young-gen churn and also, if the tables
being merged are large and have long intervals where neither overlap, could
help mitigate promotion from eden so help keep pauses low.
That all said, though, for small rows the general object overhead of LCR,
LCR.Reducer, ColumnStats etc are likely to outweigh any BB costs now.
> 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)
