[
https://issues.apache.org/jira/browse/CASSANDRA-6812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-6812:
Component/s: Local Write-Read Paths
> Iterative Memtable->SSTable Replacement
> ---
>
> Key: CASSANDRA-6812
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6812
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
>Reporter: Benedict
>Priority: Major
> Labels: performance
> Fix For: 4.x
>
>
> In an ideal world we wouldn't flush any memtable until we were almost
> completely out of room. The problem with this approach (and in fact whenever
> we currently *do* run out of room) is that flushing an entire memtable is a
> slow process, and so write latencies spike dramatically during this interval.
> The solution to this is, in principle, quite straight forward: As we write
> chunks of the new sstable and its index, open them up immediately for
> reading, and free the memory associated with the portion of the file that has
> been written so that it can be reused immediately for writing. This way
> whilst latency will increase for the duration of the flush, the max latency
> experienced during this time should be no greater than the time taken to
> flush a few chunks, which should still be on the order of milliseconds, not
> seconds.
> This depends on CASSANDRA-6689 and CASSANDRA-6694, so that we can reclaim
> arbitrary portions of the allocated memory prior to a complete flush.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
