cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Branimir Lambov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-12358) Slow PostFlush execution due to 2i flushing can cause near OOM to OOM
Date Tue, 09 Aug 2016 15:49:20 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-12358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15413756#comment-15413756
] 

Branimir Lambov commented on CASSANDRA-12358:
---------------------------------------------

The dtest didn't actually run correctly (just a fraction of the tests ran). The next run is
fine, though (one fail, same as trunk).

LGTM

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

Mime
View raw message