cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6544) Reduce GC activity during compaction
Date Tue, 07 Jan 2014 22:55:50 GMT


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:
>             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

View raw message