Feng Kaiyu

另外，不知道你是否有一个比较简单的复现方式？

@zeromem > 策略可以尝试优化成：参数 n 表示每轮删除 n 个 entry (可能涉及到多次 kv scan )，然后 startkey 检测到超过一轮，则 sleep 回退。 后面这个我理解；前半句“参数 n 表示每轮删除 n 个 entry”意思是要作为后半句的一个参数？（ startkey 检测超过 n 轮，sleep 回退）。 我个人感觉只要实现后半句的回退机制，就能缓解这个问题。 另一个想法：但是，当 KV...

@smmsmm1988 是，我上面的回复也是这个意思。 > 或者考虑全部扫完一轮以后，才触发（L465-L469）的机制（也就是更激进地回收）。另外，当有新的 KV 进入 Trash 的时候，应该通知 GC 线程重新进行更乐观的扫描。

@nudles > @fky2015 will there be a PR for this issue? may I know the conclusion? thanks! Certainly! After my vacation, which ends on July 1st, I will submit a...

https://github.com/ByConity/ByConity/commit/4b9f1238ff60a70d5c8798e14d0c2d4df776b8d8 would address this issue to a large extent. https://github.com/ByConity/ByConity/pull/1739 will further address this issue.

如果表的 part 数量不大的话，可以直接查看 `system.cnch_trash_items` （part 级别），否则可以看 `system.cnch_trash_items_info` （table 级别）；以判断是否有残留的 trash_items。 如果没有，需要观察对应 part 的 transaction 在 `system.cnch_transactions` 中的情况。如果为 Finished 或者不存在；则怀疑是数据泄漏了。目前在 0.4.2 上确实可能存在这个问题。 在 0.4.2 上一个非常粗略的判断流程如下： ```mermaid flowchart TD A[怀疑数据泄漏] --> B{是否在...

> 你们可以提供一个工具，可以手动执行这个工具清理遗留未清理的小文件，从0.3.2到现在的0.4.2感觉小文件问题一直没停过。 目前编写这样的工具有困难： 1. 我们有处理类似任务的工具，但是不太适配社区的工作流。 2. 有一些 part 无法在代价很小的方式下判断是否应该删除。 3. 涉及到删数据的功能必须经过比较严格的测试，这样会拉低 ROI。 > 到时候这张表我们只能废弃掉旧表，新建表才能解决这种问题。 由于目前 0.4.3 及以下存在 Abort 相关的数据泄露，所以我比较建议： 1. 升级到 v1.0.0 以上。 2. 通过导入到新表解决问题。 （另外）对于实时导入的表，可以根据其 TTL 来直接筛选出过期分区的文件。