flink-user-zh mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 陈冬林 <874269...@qq.com>
Subject Re: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗?
Date Fri, 19 Jul 2019 01:45:57 GMT



您好!
	
	我觉得您分析的很有道理,集群 createFile和deleteFile 调用请求是最多的。

	我们的小集群上跑了近百个flink任务,使用FsStateBackend 存储到hdfs上。checkpoint
interval不是我们能决定的。
	有没有其他方面可以减少namenode的压力,我看了您github上的代码,是个很不错的优化点,可以考虑实践一下,请问线上验证过吗,我稍后再学习一下您的代码?

> 至于使用FsStateBackend能否减少checkpoint文件数量,这是另外一个话题

	请问这个话题有没有什么优化点可以启发一下吗?




> 在 2019年7月18日,下午9:34,Yun Tang <myasuka@live.com> 写道:
> 
> hi
> 
> 首先先要确定是否是大量创造文件导致你的namenode RPC相应堆积多,RPC请求有很多种,例如每个task创建checkpoint目录也是会向namenode发送大量RPC请求的(参见
[https://issues.apache.org/jira/browse/FLINK-11696 <https://issues.apache.org/jira/browse/FLINK-11696>]);也有可能是你的checkpoint
interval太小,导致文件不断被创建和删除(subsume old checkpoint),先找到NN压力大的root
cause吧。
> 
> 至于使用FsStateBackend能否减少checkpoint文件数量,这是另外一个话题。首先,我需要弄清楚你目前使用的是什么state
backend,如果目前是MemoryStateBackend,由于该state backend对应的keyed state backend并不会在checkpoint时候创建任何文件,反而在文件数目上来看是对NN压力最小的(相比于FsStateBackend来说要更好)。还有你作业的并发度是多少,每个checkpoint目录下的文件数目又是多少。降低并发度是一种减少文件数目的办法。当然,我觉得如果你只是使用MemoryStateBackend就足够handle
checkpoint size的话,不应该会触及文件数目太多的问题,除非你的checkpoint间隔实在太小了。
> 
> 祝好
> 唐云
> From: 陈冬林 <874269816@qq.com>
> Sent: Thursday, July 18, 2019 17:49
> To: user-zh@flink.apache.org <user-zh@flink.apache.org>
> Cc: myasuka@live.com <myasuka@live.com>
> Subject: Fwd: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗?
>  
> 
> 唐云老师您好;
> 基于hdfs的backend 可以优化checkpoint小文件的数量吗?减少namenode压力吗?
> 现状是会影响namenode rpc响应设计  gc频繁,内存占用过高。
> 
>> 下面是被转发的邮件:
>> 
>> 发件人: 陈冬林 <874269816@qq.com <mailto:874269816@qq.com>>
>> 主题: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗?
>> 日期: 2019年7月18日 GMT+8 下午3:21:12
>> 收件人: user-zh@flink.apache.org <mailto:user-zh@flink.apache.org>
>> 
>> 
>> 
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/1e95606a-8f70-4876-ad6f-95e5cc38af86
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/2a012214-734a-4c2b-804b-d96f4f3dddf8
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/31871f64-7034-4323-9a2e-5e387e61b7c4
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/54c12a36-c121-4fa0-be76-7996946b4beb
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/63a22932-4bce-4531-bc65-a74d403efb91
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/64b10d96-8333-4a7e-87d1-8afe24c7d2df
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/66290710-e619-4ccf-90b6-5f09f89354f8
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/_metadata
>> 
>> QA1: chk文件下面的文件个数是跟operator个数并行度有关系吗?我只了解到_metadata文件是用来恢复状态的,那么其他文件代表的是什么意思呢?
>> 
>> QA2: 可以将这些文件合并在一起吗?


Mime
View raw message