You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Yun Gao (Jira)" <ji...@apache.org> on 2022/12/08 08:56:00 UTC
[jira] [Comment Edited] (FLINK-30251) Move the IO with DFS during abort checkpoint to an asynchronous thread.
[ https://issues.apache.org/jira/browse/FLINK-30251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17644674#comment-17644674 ]
Yun Gao edited comment on FLINK-30251 at 12/8/22 8:55 AM:
----------------------------------------------------------
Hi [~Ming Li] very thanks for reporting the issue and thanks [~Yanfei Lei] for tracking the issue! I also think this is indeed an issue and moving it to an asynchronous thread should be a reasonable solution. [~Ming Li] Could you first open a formal PR?
There is also one concern:
# The current `asyncOperationsThreadPool` is a cached thread pool, which do not have an upper limit of the number of threads, and it will create a new thread whenever there is not free thread when submitting tasks. Then if we have a large number of file to close, we might end up with a lot of threads, which might further cause a large number of memory consumption (1MB for each thread RSS region).
# Thus we might change it to a thread pool with a limited maximum number of thread and one unbounded Blocking Queue. Also since the thread in this pool might be blocked, we might need to use a separate thread pool.
was (Author: gaoyunhaii):
Hi [~Ming Li] very thanks for reporting the issue and thanks [~Yanfei Lei] for tracking the issue! I also think this is indeed an issue and moving it to an asynchronous thread should be a reasonable solution. [~Ming Li] Could you first open a formal PR?
There is also one concern:
# The current `asyncOperationsThreadPool` is a cached thread pool, which do not have an upper limit of the number of threads, and it will create a new thread whenever there is not free thread when submitting tasks. Then if we have a large number of file to close, we might end up with a lot of threads, which might further cause a large number of memory consumption (1MB for each thread RSS region). We might change it to a thread pool with a limited maximum number of thread and one unbounded Blocking Queue.
> Move the IO with DFS during abort checkpoint to an asynchronous thread.
> -----------------------------------------------------------------------
>
> Key: FLINK-30251
> URL: https://issues.apache.org/jira/browse/FLINK-30251
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Checkpointing
> Affects Versions: 1.16.0, 1.15.2
> Reporter: ming li
> Priority: Major
> Attachments: image-2022-11-30-19-10-51-226.png
>
>
> Currently when the {{checkpoint}} fails, we process the abort message in the Task's {{{}mailbox{}}}. We will close the output stream and delete the file on DFS.
>
> However, when the {{checkpoint}} failure is caused by a DFS system failure (for example, the namenode failure of HDFS), this operation may take a long time or hang, and the task will not be able to process the data at this time.
>
> So I think we can put the operation of deleting files in an asynchronous thread just like uploading checkpoint data asynchronously.
> !image-2022-11-30-19-10-51-226.png|width=731,height=347!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)