Hi，
确认的情况：
大佬，我根据loadCheckpointMeta能够去分析_metadata引用到的/shared目录下的sst文件，然后发现/shared里没有被引用的sst文件即未删除的旧文件，这些旧文件占比很少，只有5%左右。
配置：
idleStateRetention确实是设置3600秒，保留的ck目录是3个。
目前情况：
每次checkpoint size增量差不多1-2G，所以size不小。5分钟checkpoint一次。
最近单次checkpoint的sst文件数是23个，文件大小大约在65M。
总共目前/checkpoint/shared目录大小是49.4G，然后savepoint结束大小在6.3G。
那我想问一下，那中间是不是有大量的冗余数据存在这还在被应用的sst文件里，有没有什么参数可以调整？还是JM单点删除跟不上相关速度？
JM还能扩展吗？？HA不是也是一个JM在工作吗（这个地方不是很明白）
________________________________________________________________
________________________________________________________________
________________________________________________________________
Hi,
先确定一下，你的 idleStateRetention 是 3600秒？其次，要想看是否所有数据均有用，可以利用
Checkpoints.loadCheckpointMeta [1] 去加载你所保留的checkpoint目录下的 _metadata
文件，然后与当前checkpoint目录下的文件作对比，看是否存在大量的未删除旧文件。
目前仅凭你的描述和一段SQL代码其实很难判断。
可能存在的原因有：
1. 单次checkpoint文件数目过多，JM单点删除跟不上相关速度
2. 整体checkpoint
size不大，RocksDB的compaction频率较低，导致相关包含过期数据的旧文件并没有被及时删除，仍然存在checkpoint目录下（保留多个checkpoint同样会放大该问题）
所以还是最好先分析已有checkpoint的meta文件，再与目前的实际情况做对比。
另外，Flink
JIRA其实不是一个很好的直接问问题的地方，尤其是这种并不明确的问题，更妥善的方式还是先在邮件列表讨论，具体定位到原因后，再创建相关详细的ticket。
[1]
https://github.com/apache/flink/blob/b582991b8b2b8dadb89e71d5002c4a9cc2055e34/flink-runtime/src/main/java/org/apache/flink/runtime/checkpoint/Checkpoints.java#L99
祝好
唐云
________________________________
From: yujianbo <[hidden email]>
Sent: Tuesday, June 1, 2021 10:51
To: [hidden email] <[hidden email]>
Subject: Re: Flink Sql 的/checkpoint/shared/文件夹大小不断增长，源数据没有数据激增，应该如何控制？
没有更好的方式吗
--
Sent from: http://apache-flink.147419.n8.nabble.com/
