Hi [https://issues.apache.org/jira/browse/FLINK-11696] 里面目前的PR是我们的生产代码，你可以用。但是你现在的问题的root cause不是这个，而是创建文件和删除文件的请求太多了。可以统计一下目前你们几百个作业的checkpoint interval，一般而言3~5min的间隔就完全足够了，没必要将interval调整得太小，这是一个影响你们整个集群使用的配置，必要时需要告知用户正确的配置。
如果你们使用FsStateBackend，在目前的Flink场景下，已经是创建文件数目最优的选项了。剩下能做的优化就是降低不必要的并发度还有就是调大 state.backend.fs.memory-threshold 参数（默认值是1KB，最大值是1MB），但是这个参数会有一个副作用，可能需要同时调大jobmanager的heap大小。 祝好 唐云 ________________________________ From: 陈冬林 <874269...@qq.com> Sent: Friday, July 19, 2019 9:45 To: user-zh@flink.apache.org <user-zh@flink.apache.org> Subject: Re: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？ [cid:D24EB2D4-FA6B-41BD-A6B5-265B7E0C259E@360buyAD.local] 您好！ 我觉得您分析的很有道理，集群 createFile和deleteFile 调用请求是最多的。 我们的小集群上跑了近百个flink任务，使用FsStateBackend 存储到hdfs上。checkpoint interval不是我们能决定的。 有没有其他方面可以减少namenode的压力，我看了您github上的代码，是个很不错的优化点，可以考虑实践一下，请问线上验证过吗，我稍后再学习一下您的代码？ 至于使用FsStateBackend能否减少checkpoint文件数量，这是另外一个话题 请问这个话题有没有什么优化点可以启发一下吗？ 在 2019年7月18日，下午9:34，Yun Tang <myas...@live.com<mailto:myas...@live.com>> 写道： hi 首先先要确定是否是大量创造文件导致你的namenode RPC相应堆积多，RPC请求有很多种，例如每个task创建checkpoint目录也是会向namenode发送大量RPC请求的（参见 [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: 陈冬林 <874269...@qq.com<mailto:874269...@qq.com>> Sent: Thursday, July 18, 2019 17:49 To: user-zh@flink.apache.org<mailto:user-zh@flink.apache.org> <user-zh@flink.apache.org<mailto:user-zh@flink.apache.org>> Cc: myas...@live.com<mailto:myas...@live.com> <myas...@live.com<mailto:myas...@live.com>> Subject: Fwd: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？ 唐云老师您好； 基于hdfs的backend 可以优化checkpoint小文件的数量吗？减少namenode压力吗？ 现状是会影响namenode rpc响应设计 gc频繁，内存占用过高。 下面是被转发的邮件： 发件人: 陈冬林 <874269...@qq.com<mailto:874269...@qq.com>> 主题: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？ 日期: 2019年7月18日 GMT+8 下午3:21:12 收件人: user-zh@flink.apache.org<mailto:user-zh@flink.apache.org> [cid:A90251C2-5DED-42D9-AA11-8D9314A2F1B9@360buyAD.local] 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: 可以将这些文件合并在一起吗？
