Mailing-List: contact issues-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.apache.org
Date: Thu, 25 Aug 2016 03:31:20 +0000 (UTC)
From: "ramkrishna.s.vasudevan (JIRA)" <jira@apache.org>
To: issues@flink.apache.org
Message-ID: <JIRA.12935994.1454426794000.405097.1472095880506@Atlassian.JIRA>
In-Reply-To: <JIRA.12935994.1454426794000@Atlassian.JIRA>
References: <JIRA.12935994.1454426794000@Atlassian.JIRA> <JIRA.12935994.1454426794238@arcas>
Subject: [jira] [Commented] (FLINK-3322) MemoryManager creates too much GC
 pressure with iterative jobs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 25 Aug 2016 03:31:22 -0000


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

ramkrishna.s.vasudevan commented on FLINK-3322:
-----------------------------------------------

I can work on this and come up with a design doc to ensure that Iterative jobs are smart enough to ensure they don't go for requesting memory segments every time. [~StephanEwen]?

> MemoryManager creates too much GC pressure with iterative jobs
> --------------------------------------------------------------
>
>                 Key: FLINK-3322
>                 URL: https://issues.apache.org/jira/browse/FLINK-3322
>             Project: Flink
>          Issue Type: Bug
>          Components: Local Runtime
>    Affects Versions: 1.0.0
>            Reporter: Gabor Gevay
>            Priority: Critical
>             Fix For: 1.0.0
>
>
> When taskmanager.memory.preallocate is false (the default), released memory segments are not added to a pool, but the GC is expected to take care of them. This puts too much pressure on the GC with iterative jobs, where the operators reallocate all memory at every superstep.
> See the following discussion on the mailing list:
> http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/Memory-manager-behavior-in-iterative-jobs-tt10066.html
> Reproducing the issue:
> https://github.com/ggevay/flink/tree/MemoryManager-crazy-gc
> The class to start is malom.Solver. If you increase the memory given to the JVM from 1 to 50 GB, performance gradually degrades by more than 10 times. (It will generate some lookuptables to /tmp on first run for a few minutes.) (I think the slowdown might also depend somewhat on taskmanager.memory.fraction, because more unused non-managed memory results in rarer GCs.)


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