You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ariel Weisberg (JIRA)" <ji...@apache.org> on 2016/08/02 18:17:20 UTC

[jira] [Updated] (CASSANDRA-12358) Slow PostFlush execution due to 2i flushing can cause near OOM to OOM

     [ https://issues.apache.org/jira/browse/CASSANDRA-12358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ariel Weisberg updated CASSANDRA-12358:
---------------------------------------
    Status: Patch Available  (was: In Progress)

> Slow PostFlush execution due to 2i flushing can cause near OOM to OOM
> ---------------------------------------------------------------------
>
>                 Key: CASSANDRA-12358
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12358
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Ariel Weisberg
>            Assignee: Ariel Weisberg
>             Fix For: 3.10
>
>
> 2i can be slow to flush for a variety of reasons. Potentially slower than the rate at which Memtables can ingest and flush data. If this occurs the heap fills up with Memtables that are waiting for PostFlush to run.
> This occurs because reclaiming the memory is done before PostFlush runs.
> I will post a branch that has the reclaim memory task run after PostFlush has completed. As far as I can tell this is safe and correct since the memory is committed up until that point.
> It's not clear to me if PostFlush has to bind the Memtables or not. I suspect it does, but I'm not sure if that is a route I should go down.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)