[jira] [Commented] (FLINK-10066) Keep only archived version of previous executions

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

ASF GitHub Bot commented on FLINK-10066:
----------------------------------------

StefanRRichter opened a new pull request #6500: [FLINK-10066] Keep only archived version of previous executions
URL: https://github.com/apache/flink/pull/6500
 
 
   ## What is the purpose of the change
   
   Currently, the execution vertex stores a limited amount of previous executions in a bounded list. This happens primarily for archiving purposes and to remember previous locations and allocation ids. We remember the whole execution to eventually convert it into an archived execution.
   This seems unnecessary and dangerous as we have observed that this strategy is prone to memory leaks in the job manager. With a very high vertex count or parallelism, remembering complete executions can become very memory intensive. Instead I suggest to eagerly transform the executions into the archived version before adding them to the list, i.e. only the archived version is ever still referenced after the execution becomes obsolete. This gives better control over which information about the execution should really be kept in memory.
   
   
   ## Brief change log
   
   Convert `Execution` directly to `ArchivedExecution` before remembering it in the bounded list. I added the `AttemptID` to `ArchivedExecution` so that we can still support all previous requirements. 
   
   
   ## Verifying this change
   
   This change is a trivial rework / code cleanup without any test coverage.
   
   ## Does this pull request potentially affect one of the following parts:
   
     - Dependencies (does it add or upgrade a dependency): (no)
     - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: (no)
     - The serializers: (no)
     - The runtime per-record code paths (performance sensitive): (no)
     - Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes)
     - The S3 file system connector: (no)
   
   ## Documentation
   
     - Does this pull request introduce a new feature? (no)
     - If yes, how is the feature documented? (not applicable)
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> Keep only archived version of previous executions
> -------------------------------------------------
>
>                 Key: FLINK-10066
>                 URL: https://issues.apache.org/jira/browse/FLINK-10066
>             Project: Flink
>          Issue Type: Improvement
>          Components: JobManager
>    Affects Versions: 1.4.3, 1.5.2, 1.6.0
>            Reporter: Stefan Richter
>            Assignee: Stefan Richter
>            Priority: Major
>              Labels: pull-request-available
>
> Currently, the execution vertex stores a limited amount of previous executions in a bounded list. This happens primarily for archiving purposes and to remember previous locations and allocation ids. We remember the whole execution to eventually convert it into an archived execution.
> This seems unnecessary and dangerous as we have observed that this strategy is prone to memory leaks in the job manager. With a very high vertex count or parallelism, remembering complete executions can become very memory intensive. Instead I suggest to eagerly transform the executions into the archived version before adding them to the list, i.e. only the archived version is ever still referenced after the execution becomes obsolete. This gives better control over which information about the execution should really be kept in memory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)